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. A security defect must be viewed as a functional defect in the code. Defects have a remediation cost of developer time. A recent National Healthcare Information Sharing and Analysis Center (NH-ISAC) webinar provided some very telling statistics and presented the results achieved by one organization’s software security program. The program places an emphasis on detecting and addressing the vast majority of security defects in the “Code” phase, as opposed to the “Test” phase. The reported net productivity gain in security defect remediation was 73%, which translated to approximately 285,000 developer hours recovered for other tasks.
So how do you get this kind of productivity gain for your organization? It starts with a commitment to security in the development lifecycle, continues to educating the developers about security, and includes looking at technologies that promote secure development.
Committing to a secure development life cycle (SDLC) is by far the hardest step, as this is a fundamental change to the way the organization behaves, particularly in development. This requires a change in mindset at the highest levels to succeed. Security must be aligned with development and with operations to create the cultural changes required to create a security mindset. Many of the more mature organizations for software security use the Building Security In Maturity Model (BSIMM) as a method to measure their current state, identify areas of challenge, and choose areas to target for improvement. The BSIMM also provides the organization with a tool for demonstrating continuous improvement to management.
The case for education begins with a simple problem statement: you cannot expect developers to have a security mindset when they lack security training. There are many ways to tackle educating developers on security, so availability of the material is not the hurdle. The key is to develop an education program and incentivize developers to participate. You have to put on your sales hat and promote the idea to the developers, making sure they know that it helps develop them professionally. Developers are a competitive bunch, so building programs where they earn levels of proficiency (belts, for example), and measure themselves against their peers has proven highly successful.
There are tools emerging that promote secure development, and in some case provide an interesting model for education. Some of these tools integrate directly into development environment to analyze code for security vulnerabilities as it is being developed. The tool alerts the developer to the problem, educates them on the vulnerability, and suggests code changes to eliminate it. The defect is addressed on the spot, eliminating the traditional find and fix process that robs productivity.
These tools are also informative; during the process, the developer is educated, helping them to potentially adapt, eliminating similar vulnerabilities in the future. Just as I learned how to correctly spell “separate” after multiple prompts from MS Word, developers learn how to code more securely after they’re told what went wrong. They build security in.
An organizational commitment to building security into the development process can create real, measurable growth in developer productivity. Adopting an SDLC, educating developers on sound security practices and leveraging tools that promote secure development are the key elements in realizing these productivity gains while effectively reducing organizational risk by deploying secure software.
The myth that security inhibits developer productivity is as old and obsolete as those punch cards.