SCA (Software Composition Analysis)
Finding the known vulnerabilities in the open-source components your software depends on.
What is Software Composition Analysis?
Software Composition Analysis identifies the third-party components your application depends on and reports the known vulnerabilities, licenses, and supply-chain risks attached to them. It answers a different question from the code scanners: not "is the code we wrote flawed" but "is the code we borrowed flawed".
That distinction matters because most of a modern application is borrowed. A typical Node or Java service is single-digit percent first-party code by volume; the rest arrives through the dependency tree, most of it transitively, most of it never chosen by anyone on the team. SCA is the only tool that looks at that majority.
How it works
Three stages, and the third is where most tools stop short:
- 01
Resolve the dependency tree
Read the manifests and lockfiles (
package-lock.json,go.sum,pom.xml,Cargo.lock) and expand them into the full transitive graph. A lockfile is authoritative; a manifest alone is a guess, because version ranges resolve differently on different days. - 02
Match against advisory data
Join every resolved component and version against vulnerability feeds — the CVE, CWE, EPSS and KEV signals, plus ecosystem-specific advisory databases. This is where a naive tool produces its thousand-row report.
- 03
Decide which findings are real
A CVE in a package you depend on is not a vulnerability in your application unless the vulnerable code path is actually reachable from your code. Reachability analysis is what separates a list of components from a list of problems.
Why it matters
Every major supply-chain incident of the last decade — Log4Shell, event-stream, the xz backdoor — was an SCA problem. The vulnerable code was not written by the affected organisations, it was pulled in, often several levels deep, and the first question in every one of those incidents was "where do we ship this".
The failure mode of SCA is not missing things, it is finding too much. An unfiltered scan of a mature service returns hundreds of advisories, the overwhelming majority of which touch code that never executes. Teams that cannot rank them stop reading the report, which is functionally the same as not running the scan.
What value it adds
Coverage of the code you did not write
The majority of your attack surface arrives through dependencies. Nothing else looks at it.
Transitive depth
The dangerous dependency is usually not the one in your manifest — it is four levels below it, pulled in by something you did choose.
License exposure alongside security
The same dependency graph answers "can we ship this under our license", which is a legal question with the same root data.
Fix paths, not just findings
Advisory data carries the fixed version, so a finding can become a fix PR rather than a ticket.
The join key for everything else
An SBOM is the durable form of the same graph, and it is what makes the next incident a query instead of an investigation.
How Safeguard uses it
Safeguard resolves the full transitive graph, correlates it against vulnerability intelligence, and then applies reachability analysis so the report ranks what is exploitable rather than what is merely present. See SCA and the eliminate vulnerability exposure workflow.
See which dependency CVEs are actually reachable.
Point Safeguard at a repository. Get the transitive graph, the advisories, and the subset that your code can actually reach.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.