Originally posted on SecurityWeek
I coded my first program in the late 70’s on tape and wrote a macro-assembler on punch cards with extra credit for completing the task with a single box of cards. Since those bygone days, development has gone through an endless series of massive, convulsive change. But one thing has remained constant: there lacks a sufficient emphasis on security in the development process.
The historical bias is that security is an inhibitor to developer productivity. The growing adoption of agile and its emphasis on velocity has exacerbated this misconception. It is an unfortunate mindset, as good security practices can increase developer productivity.
One of the principles of the Agile Manifesto says: “Continuous attention to technical excellence and good design enhances agility.” Given the emphasis on security and the growing use of software vulnerabilities as an attack point, it is hard to argue that security is not part of “technical excellence.”
Yet developers are not trained in security and security is not yet an adequately integrated component of the development process. We are not applying good, or even minimal, security practices. Code that leaves development is tested by the IT security group and, unsurprisingly, serious vulnerabilities are discovered. These issues are taken back to development, which has already moved on to the next sprint. Developers are forced to stop their work, review the test results, identify the vulnerability in the code, and apply the required change. Because they are no longer working on their next project, there is a delay and productivity is affected negatively.
If developers are trained in sound security skills and basic security practices are applied, then the scenario above can be minimized, or, in more enlightened organizations, eliminated. Put into the context of the Agile Manifesto, continuous attention to the technical excellence of security enhances agility, and therefore developer productivity.
Can this be quantified? You bet it can.