Software Composition Analysis (SCA)

Software Composition Analysis (SCA) is a category of application security tooling and practice focused on identifying, inventorying, and risk-rating the open-source and third-party components embedded in a software project. SCA operates at the intersection of supply chain security, license compliance, and vulnerability management — making it a critical control layer for any organization that ships software containing reused code. Regulatory frameworks including the White House Executive Order 14028 on Improving the Nation's Cybersecurity and NIST guidance on secure software development treat component transparency as a foundational requirement, not an optional enhancement. This page covers the definition, mechanism, operational scenarios, and decision boundaries that structure the SCA service and tooling landscape.

Definition and scope

SCA is formally defined within the software supply chain security domain as the process of cataloging all open-source and third-party dependencies in a codebase, mapping those dependencies to known vulnerability databases, and surfacing license obligations that may create legal or operational risk.

The scope of SCA extends across four primary asset categories:

1. Direct dependencies — packages explicitly declared in a manifest file (e.g., package.json, pom.xml, requirements.txt)
2. Transitive dependencies — packages pulled in by direct dependencies, which can constitute the majority of a project's total component surface
3. Vendored or bundled code — third-party source copied directly into a repository rather than managed through a package manager
4. Container base images — operating system and runtime layers in Docker or OCI-format images that carry their own package inventories

NIST defines the broader supply chain risk context in NIST SP 800-161 Rev. 1, which addresses Cyber Supply Chain Risk Management (C-SCRM) for federal agencies and their contractors. The OWASP Dependency-Check project and the OWASP CycloneDX standard provide open specifications for component enumeration, with CycloneDX serving as one of two dominant Software Bill of Materials (SBOM) formats recognized by the Cybersecurity and Infrastructure Security Agency (CISA).

SCA is distinct from Static Application Security Testing (SAST), which analyzes first-party source code for logic flaws, and from Dynamic Application Security Testing (DAST), which probes running applications. SCA targets the composition of the software supply chain rather than the behavior of application logic — a boundary that has practical implications for tool selection and application security providers when assembling a testing program.

How it works

SCA tooling follows a structured pipeline that moves from discovery through remediation guidance:

1. Manifest and binary parsing — The tool ingests package manifests, lock files, or compiled binaries to extract component names, versions, and dependency graphs. Lock files (e.g., package-lock.json, Pipfile.lock) are preferred over loose manifests because they capture resolved, pinned versions.
2. SBOM generation — Discovered components are serialized into a machine-readable SBOM, typically in CycloneDX or SPDX format. CISA's SBOM resources page documents both formats and their respective use cases.
3. Vulnerability correlation — Component records are matched against one or more vulnerability databases. The National Vulnerability Database (NVD) maintained by NIST at nvd.nist.gov is the primary public source; commercial feeds augment NVD with faster triage timelines and exploit availability data.
4. Severity scoring — Matched vulnerabilities receive a CVSS (Common Vulnerability Scoring System) score. CVSS v3.1 scores range from 0.0 to 10.0, with scores of 9.0–10.0 classified as Critical (FIRST CVSS Specification).
5. License classification — Each component's declared license is categorized against a policy baseline. Copyleft licenses (GPL family) carry different redistribution obligations than permissive licenses (MIT, Apache 2.0), and the degree of restriction determines whether legal review is required before shipping.
6. Remediation prioritization — Findings are ranked by exploitability, reachability within the application's call graph, and availability of a patched version, allowing engineering teams to address the highest-risk items first.

Integration points include source control hooks, CI/CD pipeline stages, and IDE plugins. The application security in CI/CD pipelines context is particularly relevant because automated SCA gates can block builds when a newly introduced dependency carries a Critical-severity CVE or a prohibited license.

Common scenarios

Open-source vulnerability response — A published CVE affects a transitive dependency used across 40 microservices in a production environment. SCA tooling identifies every affected service, the dependency path introducing the vulnerable package, and whether an unaffected version exists. Without automated SCA, this inventory is assembled manually, a process that can take days and produce incomplete results.

SBOM delivery to customers or regulators — Federal agencies procuring software under guidance aligned with Executive Order 14028 may require vendors to deliver an SBOM as a contractual artifact. CISA's minimum elements for an SBOM, published in 2021, define the required fields: supplier name, component name, version, unique identifier, dependency relationship, author of the SBOM data, and timestamp.

M&A technical due diligence — Acquiring organizations use SCA to assess the open-source license exposure and known-vulnerability density in a target company's codebase before close. GPL-licensed components embedded in proprietary software can create material license compliance obligations that affect deal structure.

Container security posture — Base images pulled from public registries (Docker Hub, Amazon ECR Public) often carry packages with published CVEs. SCA applied at the container layer identifies OS-level packages requiring updates before deployment.

The page describes how SCA fits within the broader application security service ecosystem cataloged on this platform.

Decision boundaries

SCA addresses a specific subset of application security risk and should be evaluated against adjacent controls:

SCA vs. SAST — SCA identifies vulnerabilities in third-party code; SAST identifies vulnerabilities in first-party code. Both are required for comprehensive coverage; neither substitutes for the other. A codebase with no known-vulnerable dependencies can still contain SQL injection flaws detectable only by SAST.

Reachability analysis — Basic SCA flags all vulnerable components regardless of whether the vulnerable function is called by the application. Reachability-aware SCA (available in advanced tooling) traces the call graph to determine whether the vulnerable code path is actually exercised, which reduces false-positive volume and improves prioritization accuracy.

SCA scope thresholds — Organizations below a certain scale may deprioritize SCA in favor of manual dependency audits using tools such as npm audit or pip-audit. At production scale — typically when a codebase contains more than 200 declared dependencies or operates under PCI DSS Requirement 6.3.2, which mandates a maintained inventory of bespoke and custom software (PCI DSS v4.0, PCI Security Standards Council) — automated SCA becomes operationally necessary rather than optional.

SBOM format selection — CycloneDX is optimized for security use cases and vulnerability management workflows; SPDX (Software Package Data Exchange), maintained by the Linux Foundation, is optimized for license compliance and is the format referenced in ISO/IEC 5962:2021. The selection depends on whether the primary consumer of the SBOM is a security operations team or a legal and compliance function.

Regulatory applicability — NIST SP 800-53 Rev. 5 Control SA-12 (Supply Chain Protection) applies to federal systems and FedRAMP-authorized services (NIST SP 800-53 Rev. 5). FDA guidance for medical device software (SBOM requirements under the Consolidated Appropriations Act of 2023) extends mandatory component transparency to software-as-a-medical-device manufacturers. Organizations operating outside those regulatory perimeters may still adopt SCA as part of a voluntary secure software development framework aligned with NIST SP 800-218 (Secure Software Development Framework).