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.”
There’s plenty of detail involved in achieving that, of course—which Jarzombek covered in a recent webinar titled “Key Steps for Integrating Software Application Security Testing in DevSecOps.”
While the webinar is aimed at defense contractors, the DevSecOps principles apply in any industry.
Share the responsibility of security
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.”
Achieve software assurance
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).
Know the difference between a weakness, a vulnerability, and an exposure
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.
- A weakness is “a mistake or flaw condition in information and communication technology (ICT)/IoT architecture, design, code, or process that, if left unaddressed, could under the proper conditions be vulnerable to exploitation. It represents potential source vectors for zero-day exploits, according to CWE,” Jarzombek said, adding that “two-thirds of these weaknesses are at the code level. You can detect and mitigate them simply by using automated tools.”
- A vulnerability is a mistake in software that can be directly used by a hacker to gain access to a system or network.
- An exposure is a configuration issue or a mistake in logic that allows unauthorized access or exploitation.
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:
- Security: 74 CWEs in source code representing the most explicit security weaknesses in software, including the CWE/SANS Institute top 25 most dangerous security errors, and the Open Web Application Security Project (OWASP) Top 10
- Reliability: 74 CWEs in source code impacting the availability, fault tolerance, and recoverability of software
- Performance efficiency: 18 CWEs in source code impacting response time and utilization of processor, memory, and other resources
- Maintainability: 29 CWEs in the source code impacting the comprehensibility, changeability, and scalability of software
- Data protection: 89 CWEs in source code impacting data leakage or data corruption—potential vectors that could enable unauthorized reading or modification of data
“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.”
Keep pace with automation
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.”
Choose the right security tools
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:
- Coverity® for static analysis, which helps developers to find and fix security defects in code as it’s being written
- WhiteHat Dynamic for dynamic analysis
- Seeker® for interactive analysis
- Defensics® for protocol fuzz testing
- Black Duck® software composition analysis (SCA) for finding known vulnerabilities and potential licensing conflicts in open source software components
“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.”
Make the cultural shift to DevSecOps
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:
- Tracking security issues in a bug tracking system accessible to development
- Reviewing and taking appropriate steps to prevent repeat problems
- Tracking metrics from all tools in a common dashboard
- Breaking the build on functional and security blockers
- Setting up automated alerting
- Training the team in the culture of DevSecOps
- Implementing role-based training
- Measuring the success of the training program
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.
Continue Reading
SANS report: Securing the shifting landscape of application development
