“Hardware and software should be treated together, integrated with cybersecurity early and frequently.”
― Linda Rawson, author and founder of DynaGrace
You’ve likely heard of DevOps – a way to deliver software and services to market faster – but have you heard of DevSecOps? And more importantly, are you using it in your organization? If not, you should consider it.
Using a DevOps model, development and operations teams work together across the entire software application lifecycle, from development and test through deployment to operations, according to synopsys.com. DevSecOps integrates security into the continuous integration and continuous delivery (CI/CD) pipeline, allowing development teams to address the most pressing security challenges at the speed of DevOps, according to VMware. It changes development from the traditional model, which adds security late in the process, to always adding security at every level.
According to a recent report by Mezmo, only 22% of respondent organizations have developed a formal DevSecOps strategy of integrating security into software development lifecycle processes. Of those, most of them reported a positive impact on accelerating incident detection (95%) and response (96%) efforts.
“Although adoption is low for now, the study also confirms potential growth in the industry with 62% of respondents saying their organization is actively evaluating use cases or has plans to implement DevSecOps, TechRepublic reported.
DevSecOps Upending the Process
Joel Morris, enterprise architect and cybersecurity and IT leader for consultancy firm SAIC, said he was frustrated and considering leaving IT when he learned about DevOps. The idea of it energized him, renewing his interest in the field. He had worked with the USDA for many years, living in Kansas City, and whenever there was a deployment, “it was all hands on deck,” he said. Each deployment was a very big deal, and some people would be working through the night.
But with DevOps, that process was upended. “The reason that you see new features show up on Facebook, Netflix or Amazon Prime, is because they are doing continuous integration, continuous delivery,” Morris said. “They are testing features, and they don’t ‘turn it on,’ it’s there. And whenever they’ve got all the bugs worked out they turn it on, and, ‘Oh, my interface looks a little bit different.’ But after using it for a few days, you don’t remember what the old interface looked like.”
For security, the concept is to bake the security into the development process. Morris cited the 1-10-100 rule for software development as a way to assess the impact of mistakes throughout development. Preventing a bug by catching it while writing code costs little to nothing ($1) to fix. If it gets caught in QA, it costs $10 to fix, and if your customers are impacted by it, the cost rises to $100 or more, according to AKFpartners.com.
“The same thing is true for the vulnerability,” Morris said. “So, you will see a lot about a shift-left movement – shift your security testing to the left. The thing that I tell folks all the time is, ‘Hey, the easiest and the cheapest vulnerability to fix is the one that never makes it to production.’ So those software tools, those security testing tools, you can get implemented earlier and sooner.”
And that’s what he brought to the USDA. Morris and his team added static application security testing (SAST) to the USDA. SAST is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities, according to Gartner. SAST solutions analyze an application from the inside out in a non-running state, another tool for DevSecOps to keep software development as secure as possible.
Melding DevSecOps with Outside Requirements
As a cybersecurity pro consulting with governments, Morris has to keep up with the federal guidelines of NIST and presidential executive orders. One recent law came in May 2021 from the White House: Executive Order 14028, which focused on two important initiatives – zero-trust architecture in the federal government and the software bill of materials (SBOM) initiative, the latter of which enhances supply chain security.
The SBOM initiative means that when you sell a piece of software, you must provide details of where it all came from and how secure it is.
“Plenty of software is built using open source, libraries and things of that nature. Folks don’t know what’s in their bill of materials. So that’s the reason it’s important to know, so you don’t have Log4js or WannaCry,” Morris said.
Is it time to switch to DevSecOps for your software deployment? Perhaps. It’s a tool that should have its roots in its strategic monetary value to the organization, Morris said, and it constantly changes. “DSO requires executive-level buy-in to be successful. It’s more of a cultural transformation than it is a technology goal. As with any of these, DSO, cybersecurity, cloud, digital transformation, etc. … it’s a journey. The point at which you think you’ve arrived, the technology changes. Security events are going to continue to occur. This will be in a constant state of evolution.”