Software Composition Analysis (SCA)

Software Composition Analysis (SCA) is an automated security testing discipline that scans a codebase, build artefact, or binary to identify all third-party and open-source components — libraries, frameworks, modules, and their transitive dependencies — and then cross-references each identified component against vulnerability databases (CVE/NVD, OSV, vendor advisories) to detect known security issues. SCA tools can also identify licence compliance risks. Modern SCA is integrated into CI/CD pipelines so that vulnerability checks run automatically at every build, providing developers with near-real-time feedback on newly discovered vulnerabilities in components they already use.

Article 13(5) of the CRA requires manufacturers to identify and document the components contained in their products, and Annex I Part I(2)(f) requires manufacturers to address vulnerabilities in those components. SCA is the scalable mechanism that makes both obligations achievable. Without SCA, manually tracking hundreds of dependencies across multiple product versions and monitoring each for new CVEs is operationally infeasible. SCA tools automatically generate SBOM artefacts (in CycloneDX or SPDX format) as a build output and alert when any component has a newly disclosed vulnerability — providing the actionable intelligence needed to meet the CRA's patching obligations without undue delay.

Effective SCA implementation requires integration at multiple points in the development lifecycle. During development, SCA should run on every pull request, blocking merges when newly introduced components carry critical vulnerabilities. In CI/CD pipelines, SCA should run on every build and fail the build on policy violations (e.g. new critical CVEs). At release, SCA output should generate the SBOM that accompanies each product version. Post-release, manufacturers should subscribe to vulnerability feeds and configure SCA tooling to alert the product security team when any component in a shipped product receives a new CVE. This continuous monitoring is what enables the timely patch response that the CRA requires.

The most common SCA implementation error is scanning only direct dependencies and missing transitive (indirect) dependencies — which often constitute the majority of a product's open-source exposure. Another error is treating SCA as a development-phase activity only: manufacturers must also monitor components in shipped products after release, as new CVEs are discovered in already-integrated packages continuously. A third mistake is configuring SCA to alert without establishing a defined remediation process: an alert that no one acts on provides no compliance benefit. Finally, manufacturers sometimes rely on package manager manifests alone, missing components bundled as binaries or copied source files.