Best practices for selecting software composition analysis tools
SCA tools automate the process of identifying and classifying open source code used in a development environment, identifying security, licensing and quality issues. Here's how to pick a product.
ITCS
Software composition analysis (SCA) gives software developers, and the organizations that they work for, visibility into the inventory of open source components they are using to build applications.
SCA tools came into existence after development organizations and application security teams experienced trouble tracking open source components, including direct and transitive dependencies within their code base. Developers who relied on manual processes and spreadsheets found this practice to be inefficient, error-prone, and nonscalable.
How software composition analysis tools work
An SCA tool automates the process of identifying and classifying open source code used in a development environment, identifying potential security problems, licensing issues, and the quality of the open source components along with their dependencies.
Users who reviewed Sonatype Nexus Lifecycle on IT Central Station discussed best practices for choosing an SCA solution.
SCA and continuous monitoring
To work effectively, an SCA tool must monitor code continuously, as modern development methodologies that use open source code are continuous in nature.
A security team lead liked this feature saying, “In our company we’re always building new applications, and some of them are more actively developed than others. What we found was that we had a lot of vulnerabilities in applications that weren’t being actively developed, things that needed to be fixed.”
[ Insider Pro product reviews ]
This is why visibility is an essential consideration when choosing an SCA solution. It’s imperative that developers, along with those responsible for their work, are aware of open source components used in development.
“It’s like working in the dark and all of a sudden you’ve got visibility," said a devsecops staffer at a financial services firm with over 10,000 employees. "You can see exactly what you’re using and you have suggestions so that, if you can’t use something, you’ve got alternatives. That is huge.”
An SCA user at a financial services firm with over 1,000 employees echoed this sentiment. “We’re no longer building blindly with vulnerable components. We have awareness, we’re pushing that awareness to developers, and we feel we have a better idea of what the threat landscape looks like.
“Things that we weren’t even aware of that were bugs or vulnerabilities, we are now aware of them and we can remediate really quickly", they added.
Low rate of false positives
False positives can waste time and lead to user burnout in SCA. Conversely, false negatives introduce security and licensing problems into the code. For these reasons, SCA solutions need to be as precise as possible.
A senior lead for solution services framed the importance of the issue: “This helps us avoid critical vulnerabilities being exposed onsite. It saves us time in any remediation activities that we may have had after deployment, because if we had discovered security issues after the application was completely developed and deployed, it would be more difficult to go back and make changes or put it back into a cycle.”
Increased developer productivity and ROI
SCA is not just about protecting the code. It should also be a driver for increasing developer productivity.
“The solution has increased developer productivity when remediating issues, as the issues are clearly laid out,” the senior lead for solution services also found. Putting it into numbers, he said, “we are saving five to 10 percent in developer productivity.”
Users emphasized that SCA technology should pay for itself. A financial services devsecops staffer said. “It’s going to cost you a lot of money to fix the security vulnerabilities that you are ingesting in your development lifecycle.”
Open source policies
SCA practices and solutions are ultimately about enforcing security policies to all parts of the code base. Thus, the preferred SCA solutions are ones that can enforce open source policies.
A financial services devsecops staffer added, “because it’s proactive and live data, you know instantly if any part of your application is now vulnerable.”
While security policies do need to be strong, if they are overly rigid, they can negatively affect developer productivity. They might even be circumvented altogether. It’s useful, therefore, if SCA solutions provide flexible policy enforcement.
It [SCA] is a new mitigating control to find a new class of vulnerability. It helps enforce secure coding practices and that can have a time cost when you’re first rolling it out but, after a while, it may not have as much of a cost because more developers are familiar with it.”
Additionally, a user at a small financial services firm said, “it can even grandfather certain components, because in real world scenarios, we cannot always take the time to go and update something because it’s not backward compatible."
"Having these features make it a lot easier to use and more practical. It allows us to apply the security, without having an all or nothing approach."
Based on IT Central Station reviews of Sonatype Nexus Lifecycle, users want SCA to have continuous monitoring with visibility and awareness of development activities. They also want SCA to have high quality data from multiple sources, a low rate of false positives, increased developer productivity, ROI, flexible policy enforcement, enforcement of open source policies by breaking builds, integration capabilities and strong vendor support.