SCA

How it works

SCA (Software Composition Analysis) reads your dependency manifests and lockfiles (package-lock.json, requirements.txt, go.sum, pom.xml) to build a full bill of materials of every open-source library your app pulls in, direct and transitive. It matches each package and version against vulnerability databases (the National Vulnerability Database, GitHub's advisory database, vendor-specific feeds) and flags known CVEs, plus license terms that could create legal exposure (GPL in a proprietary product, for instance). Modern SCA tools also check whether the vulnerable function is actually called, not just present in the tree, to cut false positives. Vendors: Snyk, Dependency-Track, GitHub Dependabot, Mend (formerly WhiteSource).

When it matters

SCA matters from the first dependency you add, because the vast majority of code in a typical app is someone else's open-source package, not code your team wrote. Skip it and you inherit every disclosed CVE in your dependency tree silently: log4shell in December 2021 sat undetected in production apps for weeks at companies with no SCA gate in CI, while teams running SCA got an alert and a patched version within hours of disclosure. It belongs next to SAST in the pipeline: SAST checks the code you wrote, SCA checks the code you imported.

Common misconceptions

• "SCA is the same as SAST." SAST analyzes your own source code for flaws. SCA analyzes third-party dependencies for known vulnerabilities; neither substitutes for the other.
• "A clean SCA scan means the app is secure." SCA only catches known, disclosed vulnerabilities in named packages. It says nothing about bugs in your own code or zero-days in a dependency.
• "Updating to the latest version always fixes it." Major version bumps can break APIs and introduce new bugs. Teams need a patching process, not a blind auto-update, especially for transitive dependencies several layers deep.