Open Source Vulnerability Management Recommendations for 2024

Stepping in 2024, the dynamics of open source vulnerability management are shifting. Rapid changes to software development demand a more nuanced approach to open source security from practitioners. From redefining risk to the cautious integration of auto-remediation, here are the pivotal recommendations for successful open source vulnerability management in 2024 and beyond. 

1. Embrace the Permanence of Open Source (& It’s Vulnerabilities) 

We’ve known it for years; open source is here to stay. Github’s Octoverse report tells us: “A whopping 97% of applications leverage open-source code, and 90% of companies are applying or using it in some way.” 

The permanence (and risk) of open source is proven by the White House’s Executive Order on Improving the Nation’s Cybersecurity. It places huge importance on open source vulnerability management, calling it out specifically: “Developers often use available open source and third-party software components to create a product... Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.” 

Once you embrace that you’re still going to need it, you must address the likelihood that none of the problems with open source vulnerabilities are going to suddenly go away. The benefits and efficiencies of millions of libraries performing standard tasks makes the risks worth it for most organizations. Speaking of risks, don’t drown in the noise. 

2. Optimize for Risk or You’ll Drown in the Noise 

A crucial open source vulnerability management recommendation is about prioritization. What happens after you scan with Software Composition Analysis (SCA), and you’re inundated with opportunities for more security?  

Optimize for risk or you’ll drown in the noise. Three key aspects to look at when optimizing for risk are: 

• Reachability 

• Severity 

• Exploitability 

A crowning jewel of prioritization in any open source vulnerability management system is called vulnerable methods. This feature allows you to see how the findings from SCA scan are relevant to your code (the method by which your software is vulnerable...if it exists). For instance if, your code uses a library which turns out to have a vulnerability with just one of the functions it provides, but you’re not using that function, then the risk can be downgraded (but should probably still be addressed). 

Keep in mind: known vulnerabilities are only one kind of open source security risk you need to look out for. Here are four more open source security risks, especially for IT leaders. 

3. Tread Carefully When “Automating” Remediation 

The arms race for AI solutions that increase efficiency is well underway. Several companies in the software security space are finding ways to use AI for reducing tedious remediation tasks. Our recommendation is that remediation should be (more) automated, but tread carefully. 

First off, “automated” remediation sets your sights a bit beyond the acceptable capacity here. You can automate some of the work (simple updated libraries, etc), but there will be times when a library change will require rework of code. Look for tools that suggest changes developers must approve before implementation. 

4. Cozy Up to SBOMs 

In the future, if you can’t provide a Software Bill of Materials (SBOM) for your products: no one is going to use them. One critical advantage of SBOMs is they make tracking and identifying vulnerabilities, especially in the event of a zero-day vulnerability like Log4j, quick and easy.  

We predict having SBOMs for the code you buy, write, and distribute will become de facto mandatory (more than it already is). You can generate an SBOM using either Veracode SCA or Veracode Container Security. 

Final Thoughts on Open Source Vulnerability Management Designed for the Future 

2024 will bring more of the same. More open source, more vulnerabilities, more regulations, and overall more demands for security. It seems unlikely, however, that these greater demands will come with more budget or people. For a more relaxing 2024, security and development teams will need to scale up intelligently, leverage automation, optimize for risk, and augment remediation.  

If you’d like to make 2024 just a little easier than 2023, check out Veracode’s Software Composition Analysis solution or do some more reading here.