What Is Software Composition Analysis (SCA)?

Software composition analysis (SCA) provides a deep analysis of open source packages in use by an application. SCA highlights vulnerabilities and licenses in dependencies for risk and compliance assessments, and it can generate a software bill of materials (SBOM) of all resources to share with internal stakeholders and external customers.

What Is Software Composition Analysis?

Software composition analysis safely enables developers to leverage open source packages without exposing organizations to unnecessary vulnerabilities or legal and compliance issues.

Open source components have become pervasive in modern software development, with the majority of modern applications’ codebases made up of such packages. This method allows developers to move more quickly since they don't need to recreate code that is freely available and vetted by the community. However, this process also comes with its own set of risks.

What Are the Risks of Using Open Source Components?

Before building container images with these components, developers need to be aware of security concerns stemming from previously discovered vulnerabilities in the packages. They also need to ensure they are meeting compliance requirements around software use licenses.

Community members frequently find and patch vulnerabilities, but the burden is on developers to update their code. When a vulnerability is found, it’s only a matter of time before a public exploit is made available, opening the door for even low-level attackers to take advantage of the issue.

The problem is exacerbated by the fact that a majority of vulnerabilities in software are not in immediate or root packages but in dependencies of dependencies, multiple layers deep. Fixing just the root packages in use will not always secure the libraries in use.

Additionally, there are dozens of open source licenses with a variety of rules. For example, some require attribution while others require the source code for the application that uses the component to also be published. Keeping track of all of the licenses and their rules can be difficult.

Software Composition Analysis Identifies Risks in Open Source Packages

SCA tools identify all open source packages in an application and all the known vulnerabilities of those packages. This knowledge can be used to notify developers of the issues in their code to fix them before they are exploited. A good software composition analysis process will look beyond package managers into infrastructure as code (IaC) and Kubernetes manifests, pulling images to identify vulnerabilities in those images.
SCA tools with connections to IaC templates and limitless dependency scanning ensure vulnerabilities don’t go undetected or unresolved.

Software composition analysis tools can also be used to generate a software bill of materials (SBOM or software BOM) that includes all the open source components used by an application. The SBOM lists details about the package version as well as known vulnerabilities and licenses for each component in use. For example, for Python, the BOM will include all the packages in import statements, such as httplib2, along with the version number, discovered vulnerabilities and licenses for each package.

SCA programs should enable collaboration among stakeholders such as engineering, DevOps, security and compliance teams. Many organizations will use these programs to create alerts and/or block code from merging into repositories if said code includes open source components that violate the organization’s compliance mandates for controlling exposure. Determining an acceptable severity level for vulnerabilities and license types should involve the relevant stakeholders.

How to Use SCA in the Development Processes

A good SCA process is embedded throughout the development process. Starting in local environments, developers need to be able to check their code for vulnerabilities and license compliance as they write it.

Leveraging integrated development environments (IDEs) plugins, SCA tools can notify developers about vulnerabilities as they add packages. Before code is committed to a repository, checks and automated pull request comments should inform developers of any issues being introduced and block code that does not meet requirements.

This should carry over to deployments where software with predetermined levels of vulnerabilities or types of licenses can be blocked from being deployed. Security teams should also have broad visibility into the posture of the components in their environment.

Software composition analysis extends coverage from code to cloud and from infrastructure to application layers to track vulnerabilities throughout the development lifecycle.

In all areas, developers should be informed about risks to which the packages can expose them. Vulnerabilities need to be ranked and prioritized (e.g., using CVE scores and time since the vulnerability was reported) based on criticality and infrastructure impacts (e.g., if the vulnerable package is in a private VPC). Licenses should be grouped by those allowable but that require additional details, such as attribution, and those that are not allowable under organization policies, such as "copyleft" licenses.

The Benefits of Software Composition Analysis

It is important for teams to be aware of the posture of their application environments. By providing license compliance and vulnerability feedback early and often, software composition analysis helps alleviate some of the risks of using open source components in applications. While 100% patch rates are unlikely, knowing the risk and weighing the cost to fix a vulnerability is part of improving security posture.

To learn more about securing modern development processes, check out What Is DevSecOps?