Software Composition Analysis: How to Protect Open Source Dependencies in the Software Supply Chain

Introduction: why Software Composition Analysis is now indispensable

In modern DevSecOps, the Software Composition Analysis (SCA) has become a central element for continuously managing the open source and third-party components used throughout the development lifecycle. For CTOs, development teams, and software security leaders, this means having constant visibility into what truly enters the code and the risks that arise from it.

Beyond known vulnerabilities, the supply chain can be exposed to intentionally published malicious packages, dependency confusion attacks, and compromises of maintainer accounts—risks that require additional controls beyond CVE analysis alone.

The critical point is the growing risk in the software supply chain. Direct and transitive dependencies can introduce known vulnerabilities, unmanaged projects, insecure dependency chains, and license compliance risks, with real impact on security, compliance, and operational continuity.

SCA generation tools generate a Software Bill of Materials (SBOM), thereby cataloging components, versions, licenses, and known CVEs. When integrated into IDEs and CI/CD pipelines, they allow moving controls left, applying policy, and automating remediation or blocks.

Today it's no longer just a best practice. With the rise of supply chain attacks and regulatory requirements mandating SBOMs, dependency management must become a proactive, continuous, centrally governed function.

What a SCA checks: component inventory, vulnerabilities, and SBOM

A Software Composition Analysis solution analyzes project files such as package.json, pom.xml, or requirements.txt to identify all open-source dependencies. It doesn't stop at direct dependencies: it also reconstructs the entire graph of transitive dependencies, often the least visible part of the software supply chain.

In containerized architectures, SCA can extend the analysis to Docker images and system packages included in the base operating system. Components like OpenSSL, glibc, curl, or other libraries present in the image can introduce vulnerabilities independent of application dependencies and must therefore be included in the software inventory and SBOM.

For every detected component and version, the SCA performs a comparison with vulnerability databases to flag known CVEs and assign a risk level, often based on CVSS. It can also detect the licenses of the packages, to support compliance policies and automatic checks in CI/CD.

Another key output is the SBOM, i.e., the structured inventory of software components. Modern solutions generate it in standard formats such as SPDX and CycloneDX, so it can be archived and re-examined over time when new vulnerabilities emerge.

In practice, the SBOM helps with audit, compliance, and incident response. SPDX is widely used for legal and licensing aspects, while CycloneDX is security-oriented, with useful information to quickly correlate components, dependencies, and vulnerabilities.

How to integrate the SCA into the CI/CD cycle with a DevSecOps mindset

In a DevSecOps approach, SCA should be run automatically on every push and pull request within the CI/CD pipeline. In GitHub Actions, for example, this means scanning dependencies and the related software artifacts to detect known CVEs, outdated versions, and high-risk licenses, with results visible also in the Security tab via SARIF.

The next step is policy enforcement: the workflow can fail if vulnerabilities exceed a severity threshold or if unapproved packages appear. In this way, only components on an approved list reach merge or release.

To reduce supply chain risk, it is useful to apply version pinning to both dependencies and the GitHub Actions used in pipelines. Tools like Dependabot and Renovate can automatically update versions and commit SHAs of GitHub Actions, facilitating the adoption of immutable references in pipelines.

An effective pipeline also combines SCA, IaC checks, and continuous monitoring. With GitHub Actions workflows, you can use Trivy for dependencies and container images, Checkov for Terraform, CloudFormation, Kubernetes manifests, and Dockerfiles, plus nightly scheduled jobs to catch vulnerabilities that emerge after deployment, balancing delivery speed and security.

Tools and criteria for choosing open source dependency management

Among open-source Software Composition Analysis tools, OWASP Dependency-Check represents a mature solution for detecting vulnerabilities in software dependencies. It also supports exporting to standards like CycloneDX and SPDX, although its main focus remains vulnerability analysis rather than full native SBOM management, an area where other tools offer more extensive features.

If the goal is an SBOM-first approach, Syft and Grype work well together. Syft rapidly generates SBOMs from containers, filesystems, and many software ecosystems, while Grype uses those SBOMs to look up known CVEs and adds indicators like EPSS, KEV, and OpenVEX support.

For continuous governance, Dependency-Track is the reference: it imports SBOMs from various sources, applies policy, creates tickets, and offers dashboards and useful APIs in enterprise contexts. OSS Review Toolkit is instead suitable when dependency resolution and license compliance checks are also needed. SPDX-tools, finally, is useful for creating, validating, and converting SPDX documents.

In practice, the choice depends on four criteria: scanning capability, SBOM support, pipeline integration, and governance. In many corporate contexts, a targeted combination of these tools delivers more value than a single solution.

Conclusion: from visibility to control, with the support of a technical partner

Software Composition Analysis helps transform open source management from reactive activity to a continuous process. With a complete inventory of direct and transitive dependencies, vulnerability monitoring, and checks on outdated versions or licenses, teams gain more visibility and more control over software security.

Integrated into pre-commit stages, CI/CD pipelines, and post-deployment monitoring, SCA reduces risk exposure, lowers remediation costs, and prevents non-compliant code from reaching production. It also supports supply chain security, reduces technical debt, and fosters a DevSecOps culture based on continuous risk assessment and governance.

To achieve tangible results, SCA should be embedded in broader processes, together with other security practices and up-to-date dependency management. This way you can improve compliance, code quality, and resilience without slowing development.

If your goal is to strengthen software security without compromising delivery speed, Astrorei can help you design and integrate tailored DevSecOps processes, with an Agile approach focused on risk mitigation. From strategy definition to implementing automated controls in CI/CD, the team supports companies and technical teams in delivering reliable, scalable, and truly context-appropriate custom solutions.

To deepen the topic of security in the development cycle, you can also read our article on DevSecOps and security in development and on Continuous Integration and Continuous Deployment, two foundational pillars for effectively bringing SCA into production.