Product Security Glossary
Software Composition Analysis
What is SCA?
SCA stands for Software Composition Analysis. It’s a type of Application Security Testing (AST), and it deals with managing open-source software components.
Why is SCA Necessary?
SCA is necessary because many software developers use open-source code components in the proprietary software that they develop. In fact, it has been estimated that open-source code makes up somewhere from 60% to 80% of proprietary code bases. Developers need to ensure that the open-source components that they’re using are secure, and that there are no licensing conflicts. Unfortunately, too many organizations don’t pay as much attention to these problems as they should.
What Does SCA Do?
SCA scanning tools start by creating an inventory of all open-source components in a particular code base. This includes any components that have to be loaded in as dependencies.
The next step is to create a report about the open-source licenses that the components use. A big challenge that developers face is that there are many different open-source licenses, and all of them have their own set of terms and conditions. Some open-source licenses, such as the BSD and MIT licenses, allow developers to include the open-source code in proprietary products. On the other hand, the GPL open-source license prohibits that. And some open-source licenses even conflict with each other.
An SCA scan also looks for known security vulnerabilities in open-source components. A well-designed SCA tool will tell the developer not only about which libraries have know vulnerabilities, but also about whether his or her code will pull in one of these vulnerable libraries. Some SCA tools will even alert the developer about this before it allows the pull request for the open-source library to execute.
More advanced SCA tools can cross-reference each open-source component with the organization’s own policies, to automatically determine which components will be allowed for use. The tool can be set up to either automatically approve or fail the software build as part of the CI/CD process.
What are the Components of a Good SCA Tool?
To begin with, an SCA tool needs to have a comprehensive database of information about the various open-source software projects. The challenge is that there’s no centralized authority or source of information for all open-source software. This is why the SCA database needs to bring in information from many different sources.
The SCA tool also needs to support many different programming languages. The challenge here is that you might know which languages your shop is using today, but you might not know which languages it will be using a year from now. You’ll want a tool that has you covered.
Finding potential security and licensing problems is good, but it’s not enough. A good SCA tool should also be able to create meaningful, comprehensive reports on its findings. There should be a good variety of reporting tools that can be used by personnel from the R&D, DevOps, DevSecOps, management, legal, and security teams.
The reports should prioritize the problems that the tool finds, and suggest solutions for remediation. This makes it easier to remediate the most critical problems without slowing down the development process.
SCA is an important part of the software development cycle. It can help prevent security problems, as well as problems with license non-compliance. But SCA will not locate all security exposures. Therefore, SCA should be accompanied by SAST tools that can help you effectively find vulnerability patterns that might be too subtle for other tools such as SCA.