Software composition analysis (SCA) refers to obtaining insight into what open source components and dependencies are being used in your application, and how — all in an automated fashion.
This process serves the purpose of assessing the security of these components and any potential risks or licensing conflicts brought forth by them.
Incorporating SCA tools in your software development workflow correctly is a significant step toward strengthening the security and integrity of the software supply chain by ensuring any borrowed code doesn’t introduce security risks or legal compliance issues into your products.
Why software composition analysis is needed
Gone are the days when software applications were built from scratch. Rampant open source software adoption has revolutionised application development. Independent developers and enterprises can use existing components and libraries in their code to implement functionalities from simple web form validations to complex cryptographic operations.
While open source code reuse has largely eliminated the need to reinvent the wheel, it comes with some caveats: What if the code you’re borrowing has bugs or security vulnerabilities? Moreover, what if the terms of the license carried by the open source component conflict with your application’s license? Who is to review all this?
Review a dozen components could be a simple task to perform manually, but modern software applications are built using hundreds of libraries. These libraries may themselves have other dependencies. This process can run many layers deep, and before you know it, your application that otherwise appears to contain just a handful of libraries, may be pulling in hundreds or thousands of transitive dependencies. This is where SCA comes to the rescue.
Software composition analysis and SBOMs
Most SCA tools can generate a software bill of materials (SBOM). An SBOM is a detailed account of inventory—all dependencies and components that make up your application. An ideal SBOM provides the component’s name, version number, date of release, checksum, license information among other metadata for every component present in your application.
This can be done in one of two ways:
- Binary scanning: The SCA tool scans your build artifacts and identifies the open source components via binary fingerprinting. This process identifies all packages included in the final build of your application, which reduces false positives and catches third-party software and libraries added to your applicationin a non-standard way. Not every SCA tool has binary scanning capabilities.
- Manifest and binary scanning: Some SCA solutions may opt for a hybrid approach: scanning both manifests and binaries scanning to arrive at highly accurate SBOMs. Therefore, the sophistication of your SCA solution determines how precisely it can identify all components lurking in your application.
How do SCA tools help find open source vulnerabilities?
Automated SCA tools can help software teams build and ship high-quality code and empower stakeholders with a proactive approach to risk management. By identifying security vulnerabilities and risks early in the software development process, SCA tools can enable software developers to select more secure components upfront seamlessly.
This advantage speeds up the development process by minimising the need for repeated security assessments as sufficient care is taken from the beginning when including third-party components and libraries in an application.
If a component with known risks and vulnerabilities is absolutely necessary, development teams can make a judgment call when the component is first introduced and contemplate adopting potential workarounds to use the component safely.
The goal of the SCA process and tools doesn’t end at merely scanning your application sources and binaries to produce an SBOM. The key challenge lies in accurately mapping each version of the component to known vulnerabilities. Further comes the compliance aspect: letting stakeholders seamlessly review and resolve any licensing conflicts posed by the components.
A few years ago, the process may have been straightforward. Simply reviewing the CVE feeds provided by MITRE or NVD and mapping them to the component versions present in your application would have been enough.
Research including a paper produced by the University of Central Florida, George Mason, and Georgia Tech have shown that CVE advisories can often be inaccurate and contain inconsistencies. Other times CVE data can be misinterpreted due to how Common Platform Enumeration (CPE) data is presented in these advisories.
For example, a CVE advisory issued for vulnerability in the Tomcat server may apply to only a select component under the Apache Tomcat namespace, such as org.apache.tomcat:coyote rather than the entire Apache Tomcat namespace, but this may not be clear alone from the CPEs mentioned in the advisory.
Read more on the next page...