What is Software Composition Analysis (SCA) and why is it critical?
Short answer
SCA inventories the open-source and third-party components an application pulls in — including transitive dependencies — and flags those with known CVEs or problematic licenses. It matters because most modern code is dependencies you didn't write, and a single vulnerable transitive package (like Log4j) can expose the whole app. Good SCA prioritizes by reachability and exploitability, not just raw CVE counts.
Modern applications are mostly code someone else wrote. Software Composition Analysis (SCA) is how you keep track of that code and the risk it carries.
What SCA does
An SCA tool parses your manifests and lockfiles (package-lock.json, pom.xml, go.sum, and so on) to build an inventory of every open-source component you ship. It then cross-references each component and version against vulnerability databases (the NVD, GitHub Advisories, vendor feeds) to flag known CVEs, and checks declared licenses so legal-risk components (e.g. strong copyleft in a proprietary product) surface early.
Why it's critical
The headline reason is transitive dependencies: the libraries your libraries depend on. You might pull in 20 direct packages and inherit 800 transitive ones. You never chose them, you rarely audit them, and a flaw deep in that tree — Log4Shell being the canonical example — can compromise an app whose own code is flawless. SCA is the only practical way to know what's actually in your build.
Doing it well
Raw CVE counts overwhelm teams. Mature SCA prioritizes by reachability (is the vulnerable function actually called?), exploitability (is there a known exploit, an internet-facing path?), and severity — not just the count. It runs in CI so a newly disclosed CVE in an existing dependency fails the build, and it feeds the SBOM so you can answer "are we affected?" in minutes when the next big vulnerability drops.
What interviewers look for
They want you to stress transitive dependencies, connect SCA to incident response speed, and show you'd triage by reachability rather than drowning developers in noise.
Likely follow-ups
- Why are transitive dependencies the hard part?
- How would you prioritize hundreds of SCA findings?
- How does SCA relate to an SBOM?