From “Trust but Verify” to “Never Trust” – The Importance of AST in Application Development
In our last article on the GovDevSecOpsHub, we sat down with Peter Archibald, the Regional Sales Manager for DoD and FSI sales at Checkmarx, and Jeff Ingram, a DoD Regional Sales Manager at Checkmarx, to discuss the inclusion of the company’s application security testing (AST) solution in Platform One’s Iron Bank.
In the second part of our two-part conversation with Peter and Jeff, we dove deeper into the evolution and adoption of DevSecOps in the military and government. We explored the role that AST plays in making DevSecOps possible, and we talked about the real benefits that application development teams can realize by embedding security early into the application development process.
Here is what they had to say:
GovDevSecOpsHub (GDSOH): We’re seeing a massive movement across the government towards a DevSecOps approach to application development. How do application security testing (AST) solutions enable DevSecOps?
Jeff Ingram: AST solutions enable security to become an intrinsic part of development, instead of security being implemented after development is completed. AST allows organizations and their developers to start scanning source code earlier in the development lifecycle – from the earliest stages – as soon as the code is being written.
It’s about making security part of the process – baking it into development – instead of it being a step later in the process. That is the key to attaining continuous Authority to Operate (cATO), which Platform One and the DevSecOps pipeline around the DoD are looking to achieve.
GDSOH: What benefits are we seeing from moving security and testing to earlier in the processes? Why is this approach better than leaving security and testing to the end of development?
Jeff Ingram: It’s more efficient to release secure software and not have a bunch of security problems to address after release. Security vulnerabilities are cheaper and easier to fix early in the lifecycle – ideally, as they’re being coded.
Checkmarx’s AST scans source code as its being developed and trains developers on security vulnerabilities that are specific to the language and vulnerability type. This training helps to shift security even further left by training developers so that they don’t write vulnerabilities into the code in the first place. It’s all about eliminating technical debt and security debt as early as possible in the development lifecycle.
Peter Archibald: Software security has historically been addressed too late in the development cycle. Source code scans should not be left to the last second, as it used to be. They need to become part of the development process.
When there are problems with an application – which there always are – it’s sent back to the contractor or internal development team that developed it. These problems occur because the development team didn’t have the tools that they needed in the first place. This lack of tools becomes a bottleneck because they’re not securing the code in the first place.
Jeff Ingram: Instead of, “shifting left,” which is a security term that was used in waterfall development, we are hearing DevOps teams referring to “shifting center”, where security is integrated within every stage of development with an emphasis on shortening the feedback loop. We could conceptualize the old security methodology with the historical phrase or mindset, “Trust but verify.” Now, the phrase or mindset would be more akin to, “Never trust, always verify.”
GDSOH: Checkmarx has a history of providing AST solutions to the DoD. Do you have any metrics or success stories that illustrate how AST solutions have benefited these organizations?
Peter Archibald: The accuracy of the product and overall cost reductions as far as reducing incidents and incident responses would be among the most important metrics. Reducing the cost of mistakes is a very important benefit. For instance, let’s say that a fix that costs $100 in production may have only cost ten cents during development. Identifying those problems when they cost ten cents and not hundreds of dollars is critical.
Those kinds of metrics are one way to measure the benefits of this technology, but there’s also the mission cost. What is the cost of a breach? What is the loss of business value? What about the loss of a service as a result of something like a DDoS attack? What about the cost of compromised intellectual property?
You can see the costs easily in the OPM breach. Along with a tremendous amount of personal information, tangible security plans were stolen including F-35 plans. Those were stolen by an adversary nation-state, and who knows what else they stole? The source code for major weapons systems, monitoring, and reconnaissance systems, or communication and signal systems – all of which were potentially exposed in the recent widespread “supply chain” breach and those pose significant monetary and security losses to our nation. What’s the real cost of that?
At the end of the day, the cost of responding to an incident is a lot more expensive than developing securely in the first place. I would say that it’s ten-to-one, or one hundred-to-one more costly. It’s far less costly than avoiding it or leaving it to the ATO process. That’s where Checkmarx comes in and provides a system that lets you automate easily with a minimum of fuss.
And that’s another area where AST delivers value. We’ve gained new customers that switch from the legacy approaches to application testing they’ve been using to our AST solution, and they can subsequently run their security program with one person instead of five.
Jeff Ingram: One of our federal customers was exploring how to build out their pipeline and asked around their programs for ideas and suggestions. What they found was that the DoD Checkmarx customers they talked to were attaining ATOs within a day or two of finishing development on their software. Nobody else was even coming close to getting ATOs that quickly. That’s the power of an effective AST solution and baking security into application development.