A journalist asked me an interesting question this week: “Why doesn’t the Agile Manifesto address security?” After some thought, I think I have a good answer.
It does.
Recently, I’ve been carefully reviewing “The Manifesto for Agile Software Development,” the seminal document for agile development principles. The document, better known as the Agile Manifesto, was created in 2001 to provide guiding principles for the emergence of agile development. The Manifesto includes “Twelve Principles of Agile Software” that support the key concepts. In examining the Manifesto and the Key Principles, I believe the team that wrote the document was careful to use broad language and minimal words in framing the principles, to purposefully enable them to be applicable as the world of development evolved.
Think about it. The document was written before widespread adoption of the cloud, mobile applications, or the continuous implementation cycles we see today. Even with these foundational changes, the principles hold up well, which is a testimony to the authors’ brevity and careful word selection. I am not ascribing “James Madison framing the Constitution” levels of admiration here, but I do think they left the document open for interpretation as technology naturally evolves.
So back to the original question. The very first principle in the manifesto speaks to the “delivery of valuable software.” I believe the answer lies in the interpretation of “valuable.” There is a wide variety of business drivers that may qualify as “valuable,” such as return on investment, time to market, and usability. In my opinion, security is also a “valuable” business driver, and has become a growing point of emphasis up to the board level.
I attended a CISO forum in London that featured a lively panel discussion between various IT security providers and CISOs. They represented over 15 organizations, ranging from large banks to a news outlet. One CISO encouraged the providers to understand what the “crown jewels” — the valuables — of the organization really are. To illustrate his point, he noted that most would assume money would be his crown jewel. But it wasn’t. Instead, protecting his crown jewels was about preventing the loss of customer trust in a very competitive environment. Security mattered to him because a security breach would rupture that trust. So for that CISO, secure software translated to valuable software.
Of course, this is not limited to banks. Most organizations realize the importance of security to some extent. To an organization under unrelenting attack, security is viewed as not just valuable, but necessary. To organizations under regulatory control, security is an essential requirement to continued operations, which qualifies as valuable. Given that the attack point for most breaches has moved from the network and endpoint to the software, the emphasis on building secure software has increased in the past 15 years, since the Agile Manifesto was penned.
So by using the broad term “valuable,” I believe the framers of the Manifesto did include security, albeit not explicitly. When you consider the security bugs that create vulnerabilities as a flaw, then the manifesto does address security, because agile development is about reducing flaws and building valuable software. Secure is an essential component of valuable.
This is the point in the conversation where the mythology kicks in regarding security being an inhibitor of agility. I addressed this topic in a previous byline called, “Mythbusting: How Good Security Practices Complement Developer Productivity,” but will provide an abbreviated version for your convenience.
A security bug introduced in development must be viewed as a functional defect in the code. Defects have a remediation cost of developer time. Developers who receive security training eliminate a bug at the source, removing the time needed later to find and remediate that bug. Identifying security bugs in the development environment and providing remediation guidance take a fraction of the time that is consumed by having a security team test code and go back to the developer for remediation.
If you emphasize critical security responsibilities in the development process, the bugs that create vulnerabilities are eliminated at the source. This in turn significantly reduces remediation time, and developer productivity—agility—is actually improved. At Cigital we have clients who report saving hundreds of thousands of developer hours by reducing time to remediation. This translates to a 15% productivity gain, which flies directly in the face of the productivity myth.
So back to the first principle of the Agile Manifesto:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Building security into the development process and educating developers on sound security practices increases developer productivity, which translates to “early.” Software that protects the crown jewels of the organization and reduces risk translates to “valuable.” Security seems to fit neatly and reasonably into the first principle, which is explicitly identified as the highest priority.
I rest my case. I obviously was not there in 2001, nor do I have access to the authors to validate my answer, but I believe my arguments to be sound and free of wild extrapolation. At the very least, I hope you found my arguments to be, well, valuable.