What is software composition analysis (SCA)?

SCA tools operate by scanning the software’s source code, collecting it in a database, comparing it to known vulnerability databases, checking for updates or licensing issues and then producing a report. 

While software composition analysis can scan all kinds of software elements, including proprietary components and container images, it is most commonly used to analyze open source libraries. Open source components are included to some extent in nearly every modern codebase, and because vulnerabilities in their code are public knowledge it is especially important to keep open source software updated and transparent.

SCA tools manage the risks of security vulnerabilities from software components of unknown origin, compatibility issues between different open-source licenses and incomplete or insufficient documentation or support for open-source libraries.  

Software composition analysis is part of the cloud-native DevOps pipeline that integrates the software development process with IT operations. SCA also support an organization’s security posture as part of the DevSecOps pipeline, which integrates security with development and operations. SCA tools can be deployed in an integrated development environment (IDE), providing code analysis in real-time during the development process.

SCA differs from other forms of vulnerability scanning such as static application security testing (SAST), dynamic application security testing (DAST) and dependency scanning.

IT teams often use SCA tools to generate a software bill of materials (SBOM). The SBOM lists all components, libraries and modules in a software product in a machine-readable format for compliance and supply chain security. SBOMs can also further inform SCA scanning policies.

According to survey data from the International Data Corporation, 93 percent of companies with at least 100 employees used open source software as of 2024, which highlights the widespread need for SCA solutions.¹

SCA works by collecting source code, comparing it to vulnerability databases, analyzing the codebase for potential compliance issues, removing false positives and creating a report for cybersecurity and development teams. 

SCA tools actively scan and analyze code during development as part of the continuous integration and continuous delivery (CI/CD) pipeline across the development lifecycle, focusing primarily on open-source components and third-party dependencies.

In order to do this, SCA tools first list the basic elements of all software in the IT environment, including their components, frameworks, libraries, container images, modules and dependencies. The two primary forms of SCA scanning are: 

• Static, or manifest scanning, which reads configuration and metadata files to find the elements explicitly described there.

• Dynamic, or runtime scanning, which identifies libraries as they run in real time by scanning the binary code. 

Both types of scans have benefits and drawbacks. A static scan might include vulnerabilities from third-party components in source code that are not actually deployed in the runtime environment, creating false positives. A dynamic scan, on the other hand, might never be completely thorough, as all elements of the code aren’t executed in the runtime environment. Many organizations use a combination of both.

Once an SCA tool has finished collecting code, it creates a software bill of materials (SBOM) and compares the components of the SBOM to databases that describe common vulnerabilities and modern software security risks.

Security teams compare the SBOM to both proprietary databases of known security vulnerabilities and public ones like the National Vulnerability Database (NVD) or Common Vulnerabilities and Exposures (CVEs) list. Once potential vulnerabilities are flagged, the SCA tool will assign each a threat score (often using the Common Vulnerability Scoring System, or CVSS) that allows the cybersecurity team to prioritize remediation.

Some security tools automate vulnerability management by applying the appropriate patch or update as part of the CI/CD pipeline. Security teams typically monitor this process to ensure that the changes applied do not affect existing dependencies or functionality.

SCA tools also check the SBOM against company policies and laws about software licensing to ensure compliance.

The Open Source Initiative lists over 100 approved open source licenses, some of which allow proprietary products to be created from open source code. Not all of them are compatible, however, meaning organizations are responsible for making sure their products are in compliance.

SCA solutions can check that all open source software carries the required attribution, or that elements subject to “copyleft”—which prohibits their use in proprietary, copyrighted software—are not included in the development of that software. 

Software composition analysis can also detect dependencies between project components, a major source of potential vulnerabilities.

SCA tools can detect both direct dependencies—where software components are used directly by each other at the level of code—and transitive dependencies. A transitive dependency occurs when a piece of software becomes indirectly dependent on a software component on which one of its direct dependencies is dependent. For example: Component A is dependent on component B, which is dependent on component C. In this scenario, component A is transitively dependent on component C.

SCA tools must determine which dependencies introduce vulnerabilities and which do not, to reduce the number of false alerts. They do this by assessing the software supply chain and determining whether a vulnerability in the code is “reachable”—that is, whether it will be called in a runtime environment given the network’s current configuration. 

The results of software composition analysis are then compiled in a report and often presented in a proprietary dashboard, raw data such as a JSON file, a new SBOM or some combination of all three.

In recent years developers have made advances in reducing false positives in these reports.

• Vulnerable method analysis traces the call paths of software components to ensure that detected vulnerabilities are reachable.

• Machine learning and artificial intelligence have contributed to the identification of false positives. With the right trainin, models can accurately identify whether a vulnerability is reachable or not. Natural language processing is also used to analyze version control commit messages from repositories such as GitHub to detect potential issues not identifiable in code. 

Some SCA tools include continuous monitoring and automatic remediation features, which further integrate the practice into the DevSecOps development workflow. Automatic remediation is commonly done by initiating pull requests that notify developers to fix licensing issues or apply new security patches.

The benefits of SCA include higher confidence in an organization’s compliance and cybersecurity stances, as well as increased automation of IT workflows.

By helping to ensure that all open-source components in the IT ecosystem are used in accordance with their licensing and compliance requirements, SCA can help organizations reduce legal risk.

Identifying network vulnerabilities created by the unpredictability of open source software components is a crucial part of IT risk management. In making the open source software supply chain more transparent, organizations can enjoy the benefits of customizability and lower costs while remaining confident that they have reduced the attendant security risks.

In automating large chunks of vulnerability, dependency and compliance tracking, SCA solutions free up IT teams to accomplish other tasks. This extensive automation also helps reinforce an organization’s DevOps practices.

Some of the challenges posed by software composition analysis include a lack of comprehensiveness in tracking vulnerabilities, limiting false positives and managing the scope of the analysis.

Software composition analysis is different from DAST and SAST, two additional testing methods used to identify security vulnerabilities in modern applications. 

Whereas SCA provides IT teams with a comprehensive map of software components, dependencies and vulnerabilities, DAST and SAST focus on and reveal the individual flaws in those components and the larger software applications they constitute.

The difference between DAST and SAST is similar to the difference between static and dynamic scanning in SCA. Dynamic application security testing (DAST) assesses applications in their production environments, mimicking malicious users and cyberattacks to help identify security issues. Static application security testing (SAST) delves into an app’s source code, searching for vulnerabilities in the code as it is written.  

Whereas SCA focuses on enumerating and analyzing the components in a given piece of software, DAST and SAST are specifically focused on testing that software for security vulnerabilities, whether in runtime in the case of the former or the source code in the case of the latter. Both are often used alongside SCA, but may also be practiced independently. 

SCA differs from dependency mapping, the process of identifying, understanding and visualizing the relationships between applications, systems and processes within an organization’s IT operations.

SCA tools provide an overview of components’ dependencies and identify potential vulnerabilities that might arise from them, but dependency mapping refers to a broader category of observability practices that identify dependencies across the entire IT environment.

Dependency mapping can focus on dependencies within and between applications, but it can also go bigger, looking for dependencies in network infrastructure or entire real-world systems, such as a smart electric grid. Dependency mapping is often a component of SCA practices, but can be executed on its own, independently of SCA solutions.