The Dependency Problem
Modern applications are not written from scratch. Realistically, 80–90% of the code running in your application was written by someone else — open-source libraries and frameworks you imported. A Node.js application might pull in 500+ packages transitively (packages that your packages depend on). A Python data science project might have 200+ pip dependencies.
If any one of those libraries has a security flaw, your application inherits that flaw. This is called a software supply chain vulnerability, and it is one of the most common attack vectors today. The 2021 Log4Shell vulnerability (CVE-2021-44228) is the canonical example: a critical remote code execution flaw in the log4j Java logging library that affected hundreds of thousands of applications worldwide — most of which had no idea they were even using it (it was a transitive dependency).
How SCA Works
Software Composition Analysis (SCA) scanners do not look at your code. They look at your dependency manifest files — package.json / package-lock.json for Node.js, requirements.txt / Pipfile.lock for Python, pom.xml for Java Maven, go.sum for Go — to build a complete inventory of every direct and transitive dependency you use, including exact version numbers.
They then cross-reference this inventory against databases of known vulnerabilities:
- NVD (National Vulnerability Database) — The US government's authoritative CVE database.
- OSV (Open Source Vulnerabilities) — Google's open database covering npm, PyPI, Maven, Go, and more.
- GitHub Advisory Database — Integrated directly into GitHub's Dependabot.
Each vulnerability is assigned a CVE ID (e.g., CVE-2021-44228) and a CVSS score (0–10) indicating severity.
Popular SCA tools include Snyk, OWASP Dependency-Check, GitHub Dependabot, and Trivy (which does SCA in addition to container scanning).
When it runs: Early, alongside SAST, triggered whenever dependency files change. Many teams also run SCA on a schedule (nightly) to catch newly published CVEs against existing dependency versions — a library that was safe yesterday can become vulnerable today when a new CVE is published.
Key Insight: You might write perfectly secure code, but if you import an insecure library, you are still vulnerable. SCA is the only scanner that addresses this. Ignoring it means you are blind to the majority of your attack surface.
A common interview question is: "How would you handle a critical CVE discovered in a transitive dependency you don't control directly?" The answer has three parts: (1) Check if the vulnerability is actually reachable in your code path — many CVEs affect features you don't use. (2) Update the direct dependency that pulls in the vulnerable transitive one, or use dependency overrides/resolutions to pin the transitive dependency to a safe version. (3) If no fix exists, assess compensating controls (WAF rules, network isolation) and document the accepted risk with a time-bound remediation plan.