{
    "slug": "software_composition_analysis",
    "term": "Software Composition Analysis (SCA)",
    "category": "security",
    "difficulty": "intermediate",
    "short": "The practice and tooling for identifying all open-source and third-party components in a codebase, detecting known vulnerabilities (CVEs) in them, and flagging licence risks — distinct from static analysis of your own code.",
    "long": "SCA tools parse manifests (composer.lock, package-lock.json, go.sum, requirements.txt, Cargo.lock), resolve the full transitive dependency tree, and cross-reference every package + version against vulnerability databases such as the National Vulnerability Database, GitHub Advisory Database, OSV.dev, and Snyk's own feed. Output typically includes: direct vs transitive hit, severity (CVSS), fix-available version, and licence compatibility with your project's licence. Popular tools include Dependabot, Snyk, GitHub's built-in advisories, OWASP Dependency-Check, Grype, and Trivy. SCA differs from SAST (which analyses your own source code for bugs) and DAST (which tests running applications) — it is concerned only with the components you pulled in. Modern supply-chain-attack awareness (SolarWinds, xz-utils, Log4Shell) made SCA a mandatory part of any security programme.",
    "aliases": [
        "SCA",
        "dependency scanning",
        "OSS vulnerability scanning"
    ],
    "tags": [
        "security",
        "supply-chain",
        "cve",
        "dependencies"
    ],
    "misconception": "SCA only catches vulnerabilities that are already disclosed and in a database — it cannot find zero-days, logic bugs, or supply-chain attacks where the malicious code is in a new release that has not yet been flagged. Pin versions and review changelogs; do not rely on SCA alone.",
    "why_it_matters": "Most production code is 70-90% third-party by line count. A vulnerability in a transitive dependency you have never heard of can become your vulnerability overnight. SCA surfaces the problem before an attacker does, and compliance regimes (SOC 2, ISO 27001, NIST) increasingly require it.",
    "common_mistakes": [
        "Scanning only direct dependencies — transitive dependencies are often the ones with critical CVEs; make sure your tool resolves the full tree.",
        "Ignoring 'low' severity findings forever — low + widespread + in a signing library can be more dangerous than a 'critical' in an obscure dev-only package.",
        "Not scanning lock files — scanning a range spec like ^1.2.0 finds hypothetical vulnerabilities; scan the lock file for what is actually installed.",
        "Treating SCA as a gate without triage — flooding pull requests with findings burns out the team and everything gets marked 'won't fix'; tune thresholds and require context in the ticket.",
        "Forgetting the licence axis — SCA also flags GPL or AGPL pulled into a commercial proprietary product; that risk can be bigger than the CVE list."
    ],
    "when_to_use": [
        "Any project shipping to production — run SCA in CI on every pull request.",
        "Compliance audits — SOC 2 / ISO 27001 / PCI-DSS increasingly expect continuous component scanning.",
        "Before accepting a new major-version upgrade — run SCA against the new lock file first."
    ],
    "avoid_when": [
        "A trivial internal tool with zero external dependencies and no user input — the signal-to-noise is low."
    ],
    "related": [
        "supply_chain_attack",
        "dependency_confusion_attack",
        "dependency_audit",
        "dependency_security",
        "vulnerability_disclosure"
    ],
    "prerequisites": [
        "dependency_management",
        "vulnerability_disclosure"
    ],
    "refs": [
        "https://owasp.org/www-community/Component_Analysis",
        "https://osv.dev/"
    ],
    "quick_fix": "Run a free SCA pass locally: `npm audit --production` or `composer audit` or `pip-audit` — fix criticals before merging.",
    "severity": "high",
    "effort": "medium",
    "created": "2026-04-18",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/software_composition_analysis",
        "html_url": "https://codeclaritylab.com/glossary/software_composition_analysis",
        "json_url": "https://codeclaritylab.com/glossary/software_composition_analysis.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Software Composition Analysis (SCA)](https://codeclaritylab.com/glossary/software_composition_analysis) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/software_composition_analysis"
            }
        }
    }
}