There are several things to consider when choosing a software composition analysis tool, but a few key things are critical to implementing a long-term open source strategy.
Understanding what open source is in your code is the first crucial step. After all, you can’t fix what you don’t know you have. When choosing an SCA solution, you have to look at each toolset’s language coverage to be sure it includes the languages you use today. But don’t forget to look toward the future. Your needs may expand and grow over time, and you don’t want to quickly outgrow your toolset. Second, be sure you understand what discovery methods the tool employs to find open source. Scanning package managers are quick and efficient but they can miss open source that may have been modified or copied over in pieces. In these cases, you’ll want a more sophisticated scanning approach. Additionally, you might not always have access to source code, so you’ll want to choose a tool that can scan binaries.
2. Vulnerability data
Once you have a complete Bill of Materials (BoM), it needs to be mapped to known security vulnerabilities. Tools that have a diverse set of data sources and their own research team augmenting the data will provide the most comprehensive and actionable data. As the number of vulnerabilities continues to increase year over year and DevOps practices require teams to continue to increase speed and agility, finding a vendor that not only reports on vulnerabilities but prioritizes them and provides actionable remediation guidance becomes even more important. Note that the National Vulnerability Database (NVD) is a great source of vulnerability information, but it shouldn’t be your only source. Vulnerabilities are reported in a variety of places and they can take some time to find their way to the NVD.
3. License data
Security has taken center stage in the open source realm as major breaches like Apache Struts often make front page news. But license risk in open source can be just as costly if not managed properly. Finding a tool that combines expansive coverage of open source licenses, as well as comprehensive discovery methods, helps drastically reduce that risk. And implementing the proper policies up front increases the speed at which new open source components can be approved and used, because teams can set the policy and let the tool do the rest.
To keep teams working quickly and efficiently, it’s best to have a tool that works seamlessly with the tools that teams are already using. Ensuring that an SCA tool integrates across the software development life cycle (SDLC) is key to adoption. And don’t just stop at CI/CD tools. Integrating an SCA tool into the IDE earlier helps developers make informed choices about their open source usage sooner, and sending issues directly into the issue tracker they already use speeds remediation. These actions combined can have a big impact on speed and efficiency—fewer issues make it into the codebase, and those that do go directly to tools developers are already familiar with. Finally, beyond just integration at various points in the SDLC, finding a tool that can meet a broad set of your application security testing (AST) tool requirements can provide an even more tightly integrated experience for development teams.
To that end, Gartner’s “Technology Insight for Software Composition Analysis” offers specific advice around adding SCA tools into an existing AST program: “Organizations evaluating SCA tools should generally first consider the tools offered by their existing testing tool provider. As noted, the combination of [static application security testing (SAST)] and SCA can help deliver higher-fidelity results.”
There are benefits to looking to one vendor for multiple AST needs, according to Gartner. Not only do you get the benefits of easier administration and maintenance, and fewer vendors to manage, but often the tools can come with tighter integration points and easier installation than using multiple point solutions.