Software Composition Analysis (SCA)
debt(d5/e3/b5/t5)
Closest to 'specialist tool catches it' (d5). SCA requires a dedicated specialist tool (npm audit, pip-audit, Snyk, Dependabot, etc.) to surface vulnerable dependencies. No compiler or default linter catches this; you must deliberately integrate a scanning tool into CI. detection_hints.tools is empty so citing category-appropriate tools from training data explicitly.
Closest to 'simple parameterised fix' (e3). The quick_fix is a single CLI command to identify issues, but actual remediation involves bumping dependency versions (updating lock files, resolving conflicts, re-testing) — more than a one-liner but typically contained within one component or project's dependency manifest. Not cross-cutting unless the vulnerable dependency is deeply integrated.
Closest to 'persistent productivity tax' (b5). SCA must be continuously maintained — new CVEs emerge constantly, thresholds need tuning, licence risks need triage, and lock files must be kept current. The common_mistakes list (ignoring low severity, not scanning lock files, alert fatigue) all point to an ongoing operational tax across many work streams and PR cycles, though it doesn't reshape the entire architecture.
Closest to 'notable trap' (t5). The misconception field is explicit: developers commonly believe SCA provides comprehensive security coverage, but it only catches known, disclosed vulnerabilities in databases. Zero-days, logic bugs, supply-chain attacks in new unscanned releases, and licence risks are all invisible to SCA. This is a documented gotcha that security-aware developers eventually learn — narrowing false confidence is the core trap.
Also Known As
TL;DR
Explanation
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.
Common Misconception
Why It Matters
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.
Avoid When
- A trivial internal tool with zero external dependencies and no user input — the signal-to-noise is low.
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.