Security vulnerabilities in code are often seen as failures of the application development process since bugs that increase risk can make code undeployable. In contrast, security checks that slow application development directly oppose deployment velocity. There definitely is a quandary that exists between application security and speed of application development and deployment.
However, in DevSecOps the move to push security processes as far left as possible creates the opportunity to increase application security without impacting speed. To achieve DevSecOps requires agencies begin with defining an application security policy that centers on integration and automation, vulnerability identification, results correlation, vulnerability remediation, and secure coding performance and training. Doing so can turn risk into advantage for our agencies.
In November, Stephen Gates, a Security Evangelist and Senior Solution Specialist with Checkmarx participated in a roundtable discussion of industry experts focused on cyber strategy. Stephen highlighted the need for effective policy that drives secure software development as far left as possible and instructs how to automate security within each step of the application development lifecycle.
How far left?
What are reasonable expectations for where to begin implementing application security reviews and measurements? “The code repository that holds source code management tools is currently the farthest left we can start the process,” Stephen shared. Then, at key milestones or iterations, security testing should be assured. Ubiquitous security doesn’t need to be cumbersome or too costly in terms of time. Embedded security measures in the development tools, and the check-in, build, test, and QA phases of the lifecycle make security a part of the wallpaper and not a hurdle to overcome.
Similarly, if one were building a house without proper permits and without periodic inspections to ensure that work met local ordinances and building codes along the way, not many homes would be built without structural or major system flaws. Or, there would be many more plumbing, electrical, and HVAC systems in the world that simply failed to function as desired.
A good builder will build to local codes, and then inspect each system as work progressed to ensure that it met regulations. At key points during the building process, various inspections are actually a good thing. For example, a roofing inspection is required before the interior buildout begins and a plumbing, electrical, and HVAC inspection is required before the drywall is hung. They’d also ensure they were working with qualified professionals whose work could pass inspection to ensure the homes they’re building meets the occupancy permit requirements.
By including security measures through effective policy and even strategy enforcement, we can mitigate many vulnerabilities before they become a risk. Just like building codes ensure safety, our security policies can dictate when and where testing is performed and specify acceptable and unacceptable risks for our agencies.
As is true with DevSecOps principles in general, detailed security policy enables more secure applications to be developed more quickly, and with the fewest and least damaging vulnerabilities. Stephen explained, “…every piece of software is going to have vulnerabilities. The policies act as a pseudo-contract between application security and developers that declares responsibilities for each role and defines what should be remediated first, and by whom.”
With security baked in along the way, and ensured by our policies and procedures, the correlation of all risk assessment is possible – allowing a view of all vulnerabilities across all the security testing tools and phases. Stephen illustrated the benefits which give, “…the ability to filter through the noise and identify what must be fixed first…Fixing the right problem in the right place drastically reduces and organization’s risk because one fix can address numerous downstream problems.” These efforts to define policy in regard to security and risks allow better decision making and empowers more effective remediation.
To further demonstrate how far security can alter the risk landscape in our agencies and projects, training can also be embedded into the remediation process itself. Each discovered vulnerability should include the opportunity for the developer to learn about the risk, what caused it, how to mitigate it, and ultimately fix the issue. Stephen laid out how this could look, “The developer should be able to click on a button, jump to an interactive module that provides training about that vulnerability, and [that] teaches the developer how to quickly provide remediations.”
By including applications security measures along each step in the development process also allows more information to be gathered along the way. Our agencies can include within our strategies and security policy documents the key performance indicators needed to track vulnerability causes and where improvement is needed within our application lifecycles. Measurement and good actionable information allow for improvement in our processes and better applications overall.
To learn more about policy-driven strategy and security, read the Checkmarx white paper HERE!!!
