Software development has shifted into overdrive to keep pace with the demand for rapid releases. To meet this challenge, the industry has moved in recent years to the far more agile development and operations (DevOps) model, which has enabled companies to push out releases faster and more efficiently.

However, more code means more vulnerability alerts. What can teams do to remain operational? They must find ways to prioritize their workload by first tackling the alerts that are most likely to have a significant impact on their product’s security.

The Threat of Known Security Vulnerabilities

Security vulnerabilities are a fact of life when it comes to developing code. The good news: While zero-day exploits will always be a threat, security researchers are actually pretty good at finding, reporting and publishing vulnerabilities on databases like the National Vulnerability Database (NVD).

The problem? Once these vulnerabilities become known, cybercriminals can use them to target victims. Known security vulnerabilities are among the most pressing threats to software. Gartner estimated in November 2017 that nearly all vulnerabilities exploited through 2020 would be ones that are known to security professionals. This is especially relevant when it comes to managing open source software components.

According to IBM X-Force, the number of uncovered infrastructure vulnerabilities peaked last year — jumping from 10,530 in 2016 to 15,562 in 2017. Defenders certainly have their work cut out for them to keep their applications properly patched.

Why Open Source Code Is Low-Hanging Fruit

Open source components are the building blocks of software. Their widespread reuse among developers makes them prime targets for cybercriminals. Since a reported vulnerable open source component could be used in thousands of products, they represent a gift basket full of potential victims for attackers.

With so many vulnerabilities to contend with, how can security teams prioritize their remediations? Defenders are in a race against time under the weight of more alerts than they can address. Without the means to prioritize these potential threats, they risk leaving serious vulnerabilities unaddressed.

Beyond the need for prioritization, there is a human aspect at play here as well. Developers and security teams are in a constant state of friction: Security does not trust development to follow policies against using components with known security vulnerabilities — and developers feel like they are often being sent on wild goose chases to search for supposedly pressing flaws in their code.

Prioritizing Open Source Remediation

The first step toward establishing a more secure workflow is to gain visibility into which open source components developers are using in their code. Simply put, you cannot patch what you do not know you have. Software composition analysis (SCA) tools can help teams continuously monitor which components they have in their development environment and products. SCA tools can also alert them when new security vulnerabilities are detected.

For the purposes of prioritization, however, it is not enough to know whether the open source component you are using contains a vulnerability. When developers take an open source component from sites like GitHub to add a specific functionality, they add them to their proprietary code as-is.

However, a component contains multiple functionalities, many of which are not effective and have no impact on the code. This can be confusing for SCA tools that are looking for flawed components since a single faulty functionality will designate a component as vulnerable — thus creating an alert that needs to be remediated.

By understanding which vulnerable functionalities are effective and which ones do not impact your code, you can significantly reduce the scope of alerts that your already-overworked security team needs to contend with.