Skip to main content

Software Composition Analysis

Think of software development today as building something with LEGO blocks. Instead of manufacturing each small block from scratch, you use ready-made blocks (open source components, libraries, frameworks) to assemble your application much faster.

SCA is essentially the tool that analyzes all those LEGO blocks you used to ensure they don't have dangerous defects.

Software Composition Analysis (SCA) is an automated process that identifies open source software components in a codebase. The main objective is to evaluate these components to find security vulnerabilities, license compliance issues and analyze the overall quality of the code you are "importing" into your project.

It is estimated that between 80% and 90% of the code in modern applications is open source. When you import open source libraries, the vulnerabilities contained in them become yours as well.

  • Inherited Vulnerabilities: If you use a vulnerable library, your application becomes vulnerable. The most famous and recent example was the Log4Shell vulnerability (CVE-2021-44228) in the Java Log4j library. Companies worldwide panicked to find out if and where they were using this library. SCA tools were essential for this rapid identification.
  • Transitive Dependencies: The library you add (direct dependency) may depend on ten other libraries (transitive dependencies). A vulnerability in any of them affects you, even if you have never heard of that package. SCA maps this entire dependency tree.
  • License Compliance: Open source components come with licenses (MIT, Apache, GPL, etc.). Some of these licenses have restrictions on how you can use the code, especially in commercial products. Improper use can lead to serious legal problems. SCA verifies these licenses and alerts about conflicts.

The Process​

  1. Scanning: The tool analyzes your project's manifest files (such as package.json in Node.js, pom.xml in Java/Maven, requirements.txt in Python, etc.). These files declare the project's direct dependencies.

  2. Identification and Mapping: The tool builds a complete inventory of all components, including transitive dependencies. The result of this step is, ideally, an SBOM (Software Bill of Materials).

  3. Vulnerability Analysis: Each identified component is compared with known vulnerability databases, such as the NVD (National Vulnerability Database), GitHub Advisories, and the tool's own private databases. It searches for CVEs (Common Vulnerabilities and Exposures) associated with that specific version of the component.

  4. License Analysis: The licenses of each component are identified and compared with policies defined by your company to ensure compliance.

  5. Report and Alerts: The tool generates a detailed report with:

    • List of vulnerable components.
    • The severity of each vulnerability (generally using the CVSS score, or Common Vulnerability Scoring System).
    • Information on how to fix (e.g., "update library X from version 1.2.3 to 1.2.5").
    • Alerts about incompatible licenses.

Main Benefits of SCA in SDLC​

  • Visibility: You finally know what is inside your code.
  • Security "Shift-Left": By integrating SCA in the early stages of development (in the developer's environment, in the code repository), you find and fix security issues earlier, when they are easier and cheaper to resolve. This is a pillar of DevSecOps.
  • Risk Reduction: Prevents known vulnerabilities from reaching production.
  • Speed: Allows development teams to use open source components with confidence, without slowing down the innovation process.
  • Compliance: Ensures compliance with software licenses and security regulations.

There are several tools on the market, both commercial and open source:

Commercial:

  • Snyk Open Source: Very popular among developers for its integration and ease of use.
  • Veracode Software Composition Analysis: Part of a broader application security suite.
  • Sonatype Nexus Lifecycle: Focused on component governance throughout the lifecycle.
  • Checkmarx SCA (formerly CxSCA): Integrated with Checkmarx's SAST (Static Application Security Testing) solution.
  • Sonarqube: Offers native SCA from its paid editions (Developer Edition onwards). The free Community edition focuses on static code analysis (SAST).

Open Source:

  • OWASP Dependency-Check: A classic and widely used tool that can be integrated into CI/CD pipelines.
  • Trivy: A versatile tool that, in addition to containers, can also scan application dependencies. We already have documentation about it here on the site.

SBOM (Software Bill of Materials)​

The SBOM is a direct and crucial result of the SCA process. Making an excellent analogy with the Node.js ecosystem, the SBOM is like a portable and language-agnostic package-lock.json.

While package-lock.json describes the exact dependency tree for a Node.js project, an SBOM does the same in a standardized way (using formats like CycloneDX or SPDX) for any type of software. It is literally a formal and structured "ingredient list" of all components that make up an application.

The great power of an SBOM file lies in its portability, allowing it to be used as a data source for various security tools. For example, Trivy can both generate an SBOM from a project and analyze an existing SBOM for vulnerabilities. This way, an inventory generated by one tool can be consumed by another, such as OWASP Dependency-Check, optimizing the analysis process.

It is fundamental to understand that the SBOM is the component inventory, not the vulnerability report. However, it is based on this precise inventory that we can generate risk reports, analyze the impact of new threats and, crucially, manage license compliance.

In this context, the SBOM becomes the best modern tool for license disclosure. The task of verifying legal compliance ceases to be a manual process and becomes an automated analysis over an engineering artifact. Although there is no universal law that requires every company to disclose its components in all cases, this is already a requirement in many B2B contracts and for selling software to government sectors, making the SBOM a business necessity.