There’s a growing need for both security and speed in application development. DevSecOps introduces security earlier in the SDLC to ensure secure code.
Comparing the speed of software development today to even just a decade ago is a bit like comparing a bullet train to a bicycle. With CI/CD and DevOps now mainstream, it’s faster by orders of magnitude. According to a 2015 report from Puppet Labs, “high-performing IT organizations deploy 30x more frequently with 200x shorter lead times.”
And that was five years ago. It’s even faster now. How is security supposed to keep up with that?
Joe Jarzombek, director of government and critical infrastructure programs at Synopsys, is glad you asked. The short answer is to embed security into DevOps throughout the software development life cycle (SDLC), making it DevSecOps. The way to do that is with a combination of improved security culture, automated tools, and processes that, as he puts it, “reduce the time and effort needed to address risks attributable to exploitable software.”
While the webinar is aimed at defense contractors, the DevSecOps principles apply in any industry.
One of the most important steps, which has become a mantra at security conferences, is to “make the secure way the easy way.” In the case of DevSecOps, that means although security has to be everybody’s responsibility, not everybody has to be a security expert.
“Using tools with security checkers ‘under the hood’ enables team members to catch security defects like using a spellchecker,” Jarzombek said. “As you’re typing, it gives you a warning and shows you the path to mitigation. Security checkers drive savings in time and resources while rapidly mitigating risks even if developers don’t have full knowledge of the security defect itself. The tools do it for them.”
The goal of embedding security testing into DevOps is “software assurance,” Jarzombek said, which refers to the level of confidence that software will function as intended and is free of exploitable vulnerabilities.
“The fact is that software is processing data that we are very concerned about, and we want to make sure that your systems, through the software that enables and controls them, are not leaking data,” he said.
Of course, no software is entirely free of vulnerabilities, so another key to software assurance is to set priorities—to find and fix defects that are most likely to be exploited by attackers and/or could do the most damage.
One way to do that is to look for the known vulnerabilities and weaknesses in the common vulnerabilities and exposures (CVE) and common weakness enumeration (CWE) lists, which are part of the national vulnerability database (NVD), the U.S. government repository of standards-based vulnerability management data maintained by National Institute of Standards and Technology (NIST).
Even those lists need to be narrowed to the most important threats, however. And as Jarzombek noted, there are important differences between weaknesses, vulnerabilities, and exposures.
The goal of an attacker is, of course, to try to exploit any or all of those. Among common attacks are cross-site scripting (XSS), which is improper neutralization of inputs during webpage generation, and SQL injection, which is an improper neutralization of special elements used in a SQL command.
“But this is where tools come into play,” Jarzombek said, noting that good testing tools can flag hundreds of known weaknesses or vulnerabilities included in the Object Management Group (OMG) automated source code quality measures (ASCQM). The ASCQM categories include:
“With security checkers under the hood, you don’t need to know all these,” Jarzombek said. “You just have to treat them as quality defects and process them. That’s the beauty of it.”
That doesn’t make everything simple, however. Jarzombek said the complexity of modern applications, along with the speed of development and delivery, means automated testing tools are mandatory for security to keep pace.
“Modern applications are a technology stack that includes data storage, data access, frameworks, business logic, UI/API, and cloud/mobile,” he said. “Software is mission-critical infrastructure. There is more complexity, including languages, platforms, open source, third-party licensed code, proprietary code, containers, and cloud.”
“That level of complexity makes it very challenging if you don’t bring automation to the table,” he said. “For example, an application with 20 GB of source code could have almost 70% open source, with 67% reciprocal licenses and 2% permissive licenses, proprietary code of 30%, and licensed third-party code of 6%. Those could have vulnerable components including 6 high severity, 13 medium, and 19 low.”
And the importance of finding and fixing those vulnerabilities has never been greater, since applications have become the primary attack surface. Jarzombek said multiple studies have found that about 84% of all cyber attacks happen at the application level, and that 90% of exploitable vulnerabilities are in applications.
Yet organizations are still spending more on network security. “You do need to protect your networks,” he said, “but we need to put more effort into the security of the applications themselves. Hackers are targeting the application vulnerabilities because we make it easy for them.”
That’s in part because applications don’t age like fine wine. “They age more like milk,” he said. “Over time, we discover more and more vulnerabilities. Once it’s deployed, you still have to keep checking and doing updates. So it’s key for DevSecOps teams to use automated software vulnerability scanning to keep up with it. There’s really not another way around it.”
The Synopsys suite of software testing tools covers the entire SDLC, Jarzombek noted. Those tools include:
“It’s different tools for different stages of the SDLC, and the beauty of this is when you bring in best-of-breed tools, you get the best-of-breed overall solution,” he said.
Those tools are integrated into the Polaris Software Integrity Platform™ that includes Code Sight™, the IDE plugin, which brings together both Black Duck SCA and Coverity static analysis.
Of course there are multiple tools on the market—some of them free. “But remember, not all tools are created equal,” Jarzombek said. “Just because you have a tool that’s in one space, that doesn’t mean it looks for everything. In fact, if you say which tool you’re using, many people can tell you they know what you’re not looking for. You should know the capabilities of the tools you bring to the table.”
Finally, he said, effective DevSecOps requires a cultural shift. “DevOps teams must own security in the same way that they own development and operations,” he said. “Application security must match your release and test paradigms. It’s not an added thing; it’s just the way to do business. It has to be embedded into what we do.”
Doing DevSecOps right means “integrating security into defect tracking and postmortems,” he said. It should include:
Yes, all this takes time and money. But it’s an investment that will pay dividends. “It’s much more cost-effective than reacting to vulnerabilities, incidents, and breaches after the software has been deployed,” Jarzombek said. “DevSecOps teams should only be dealing with new threats for vulnerabilities that weren’t previously known. They shouldn’t have to be reacting to things that have been known but somebody just didn’t address them in development.”
Which is another way of saying that DevSecOps is the path to building secure, high-quality software faster.