To improve DevSecOps, set application security priorities

Where does application security fit into DevSecOps? Everywhere: from preventing vulnerabilities to securing open source to prioritizing significant defects.

You can’t do it all, especially when it comes to application security. If you try to make software perfect, not only will you fail, but you’ll never bring a product to market.

As the 18th-century philosopher Voltaire put it, “Perfect is the enemy of good.”

Or as Gartner put it 150 years later in 2019 research titled 12 Things to Get Right for Successful DevSecOps, “Perfect security and zero risk are impossible.”

Sponsorships Available

Sponsorships Available

Sponsorships Available

So in DevSecOps, to do good while getting things done, you have to set application security priorities. Fix the biggest problems. Eliminate the worst threats.

Indeed, a major reason for conflict between development and security teams is developers’ perception that the security people “won’t let us do our job.” It’s impossible to eliminate every risk. But without a system to prioritize application security risks, your developers will waste their time on issues that don’t matter, such as false positives and known vulnerabilities that aren’t exploitable.

Now, thanks to the expanding DevSecOps movement, this message is being heard and embraced by security leaders.

How to set application security priorities in DevSecOps

The most recent RSA Conference in February featured a day of keynotes, panel discussions, and workshops on how to do DevSecOps better. The bulk of them focused on what has become a mantra: Help development teams to “build security in” to their code. Don’t force them to stop what they are doing and go back to fix mistakes they made a week ago. Instead, make the secure way the easier and faster way.

That means that doing DevSecOps right requires setting application security priorities. Jennifer Czaplewski, director of product security at Target, said as much at an RSA panel, calling the idea that it is mandatory to “scan all things” a security myth. “It’s too much information,” she said. “We were unable to prioritize.”

Priority: Securing open source software

So what elements of application security should you prioritize in DevSecOps? Near the top is open source software, which now composes most of the code in an application—often 90% or more.

Open source is no more or less secure than proprietary or commercial software. And fixing open source vulnerabilities is often as simple as patching or upgrading. But without an inventory of your open source, or a software bill of materials (BOM), you’re likely to miss an update or patch for a vulnerability. In short, you can’t secure what you don’t know you have.

It is impossible to comb through thousands of software components and dependencies to compile a list manually. But a software composition analysis (SCA) tool integrated into your DevSecOps workflow can flag both known security vulnerabilities and potential licensing conflicts and create a BOM automatically.

Having a BOM also offers a long-term benefit: When you find that a component has a critical security vulnerability, you’ll be able to find out immediately which applications are affected.

Priority: Preventing weaknesses that cause vulnerabilities

Open source is not the only risk, of course, which is why other application security tools are necessary in your DevSecOps pipeline. Among the most crucial is static analysis, or SAST, which helps find defects and weaknesses in code before they become vulnerabilities. The trick is making it easy for developers to fix mistakes as they’re coding, rather than days later.

And there is a tool to help: the Code Sight IDE plugin. It lets developers view results from both static analysis and software composition analysis, right in their IDE (IntelliJ, Eclipse, or Visual Studio).

Patrick Carey, product marketing director at Synopsys, said earlier this year that with the latest version of the Code Sight IDE plugin, developers can find and fix problems with both proprietary and open source code while software is being built, instead of “switching tools or interrupting their workflow.”

Think of it as a version of spell-check. Your mistakes are flagged immediately, making it easier, faster, and ultimately cheaper to check in code that is free of significant defects.

Priority: Fixing significant defects

The last, but not least, application security priority in DevSecOps: “significant” defects. Since it’s not possible to eliminate every risk, your goal should be to eliminate the most serious ones.

This is where the Polaris Software Integrity Platform comes in. Polaris integrates results from several types of application security tests to provide a holistic view of application security risk across your portfolio and the SDLC. That means giving developers a guide to severity—high-risk defects.

Which are, obviously, the ones that need to be fixed.

All of which leads to accomplishing the achievable and necessary goal: Making the secure way to develop software the easier way.