This week, while I was at the Hosting & Cloud Transformation Summit , I ran into an old friend of mine, David Etue (@djetue). I’ve known him for over a decade, first crossing paths when he led the infosec program at GE in 1999 and I was the CTO of Tripwire, back when the company was less than two years old.
David and I were talking about Gauntlet, an open source security testing tool designed to be operated within the continuous testing and deployment pipeline. He said excitedly, “Cool!”
Frankly, I was immediately a little suspicious of his response, because this isn’t the reaction from most infosec practitioners. When I asked, “Why?” he said something astonishing.
“It’s a perfect cultural fit,” he said. “When you’re not doing security testing [in the deployment pipeline], all sorts of bad things happen. First, the developers don’t understand the security requirements and have to rely on a security expert to do the code review. So at the end of a release, they need to wait in line to get their testing completed, just when the deadline pressures are highest. So when the inevitable bunch of security vulnerabilities are found, there’s never enough time to fix them so late in the deployment process, etc…”
He agreed vehemently that the status quo almost preordains, if not complete failure, certainly suboptimal outcomes.
He then told James Wickett (@wickett) and me a story from his GE days. This was during the “bubble,” when organizations were rushing to be fast to the Internet to react to the “fast” “nimble” start ups. GE took security for Internet facing apps very seriously (hence the Tripwire conversation), and also required a code review of any publicly accessible code. As Jack Welch forced the GE businesses to adopt “.com” strategies, deploying quickly in secure environments with code reviewed applications became a highly visible and painful bottleneck.
David was in the middle of the bullseye, because security was seen as the obstacle that prevented the business from going where it needed to. So David did something incredibly clever. For each Internet facing application development project, he required that another developer do a security review of the application based on a simple checklist that he created.
Get that? David created a security review checklist that a DEVELOPER could use to conduct a security review, as opposed to a security expert. This was when offshore development was skyrocketing, and many businesses were leveraging it for Internet application development. So, many businesses addressed the problem by having a different outsourcing firm do the code review.
When security code reviews started being done by other developers (often at other outsourcing firms), they seemed to suddenly care much more about security. Why?
He said, “First, security was now a developer problem. The requirements were clear and understood, and could be integrated into the development process. Writing secure code was their responsibility, as opposed to some arbitrary security person “blessing” their application. Was the list of requirements perfect? Probably not, but given the state of code security today, many applications written now still likely fail those simple tests.
“But the second reason is even more interesting. Since the testing was done by other developers, no one wanted another developer (a peer!) to call out their coding failures. This was particularly interesting when the person reviewing your code could be a competitor – one offshore developer reviewing another offshore developer’s code.”
He concluded, “Fast forward today to DevOps. What things like Gauntlet are doing is getting security testing in the deployment in the pipeline, so infosec is actually integrated into daily operations of Development.”
He said with certainty, “This is a very good thing. “DevOps cares about operations and availability, and the integrity of the deployment pipeline. This is the perfect cultural fit for infosec.”