Software composition analysis (SCA) is the practice of identifying the open-source and third-party components in your code, matching them against known vulnerabilities and licenses, and prioritizing what to fix. Because open source now makes up 70% to 90% of a typical application, SCA has become the primary lens most teams have on their supply chain risk. Modern SCA goes beyond version matching to reachability analysis — determining whether the vulnerable code is actually invoked in your application — which is the difference between a backlog of thousands of alerts and a short list of findings that matter.
Frequently Asked Questions
What is software composition analysis (SCA)? SCA is an automated technique for discovering every open-source and third-party component your software depends on, then mapping those components to known vulnerabilities (CVEs), license obligations, and other risk signals. It works by parsing manifests and lockfiles, resolving the full dependency graph, and comparing resolved versions against vulnerability databases. The output is an inventory plus a prioritized risk assessment of the components you ship rather than the code you wrote yourself.
How is SCA different from SAST and DAST? SAST (static application security testing) analyzes your first-party source code for coding flaws like injection and unsafe deserialization, and DAST (dynamic application security testing) probes a running application from the outside. SCA is concerned with the code you did not write — the open-source libraries and their transitive dependencies. The three are complementary: SAST and DAST find bugs in your logic, while SCA finds inherited risk in your dependency tree and license posture.
What does an SCA tool actually scan?
A good SCA scanner reads package manifests and lockfiles such as package-lock.json, pom.xml, requirements.txt, go.sum, and Cargo.lock, and it can also inspect built artifacts and container image layers. From those inputs it resolves the complete dependency graph, including indirect dependencies pulled in several levels deep. Safeguard's software composition analysis resolves that graph and matches every component against vulnerability, license, and threat-intelligence data in one pass.
What is reachability analysis and why does it matter? Reachability analysis traces call paths from your application's entry points down through direct and transitive dependencies to determine whether the specific vulnerable function in a library is actually invoked. A version-only match tells you a CVE exists in a package you installed; reachability tells you whether that CVE is exploitable in your context. This is the single biggest lever for cutting noise, because the majority of matched CVEs sit in code paths your application never calls.
Why do traditional SCA tools produce so much alert fatigue? Legacy SCA flags every CVE that matches an installed package version, which routinely produces thousands of findings per repository — most of them unreachable dead code. Teams that triage by CVSS score alone burn sprint capacity patching dependencies that pose no real exposure while genuinely exploitable issues age in the backlog. Reachability-aware SCA reverses that by ranking findings on whether they are actually callable, so the "critical" list reflects real risk instead of raw version matches.
Does SCA detect transitive (indirect) dependencies? Yes — and this is where most real exposure lives. Modern JavaScript and Java projects commonly resolve to trees several hundred packages deep, and a vulnerability four or five levels down is invisible to anyone who only reads the top-level manifest. Log4Shell was so damaging in 2021 precisely because Log4j was usually a transitive dependency buried inside other frameworks, and teams spent months just finding where it ran.
What is the difference between SCA and an SBOM? An SBOM (software bill of materials) is the inventory artifact — a machine-readable list of every component and its metadata. SCA is the analysis layer that produces and consumes that inventory, adding vulnerability, reachability, and license context on top. In practice you generate an SBOM with a tool like SBOM Studio and let SCA continuously evaluate it as new CVEs are disclosed against components you already ship.
Can SCA detect malicious packages, not just known CVEs? Modern SCA increasingly does both. Known-CVE matching catches disclosed vulnerabilities, but typosquatting, dependency confusion, and slopsquatting (installing plausible package names that AI assistants hallucinate) require behavioral and reputation signals rather than a CVE lookup. Safeguard's Griffin AI engine watches registry activity and dependency behavior to flag anomalies consistent with malicious packages before they reach production.
How does SCA prioritize which vulnerabilities to fix first? Effective prioritization blends several signals: reachability, exploit maturity and CISA KEV (Known Exploited Vulnerabilities) status, CVSS severity, and whether a safe fix exists. A reachable, actively exploited critical with an available patch should sit far above an unreachable medium with no known exploit. Relying on CVSS score alone is the classic mistake, because severity says nothing about exploitability in your specific application.
What is VEX and how does it relate to SCA? VEX (Vulnerability Exploitability eXchange) is a standardized way to communicate whether a product is actually affected by a given vulnerability — for example, "not affected because the vulnerable code is unreachable." Formats include OpenVEX, CSAF, and the CycloneDX VEX profile. Reachability-driven SCA is a natural source of VEX statements, because the same analysis that suppresses an internal finding can be published downstream to your own customers.
How does SCA fit into CI/CD pipelines? SCA is designed to run automatically on every pull request and build, failing or annotating a build when a new reachable, high-severity vulnerability is introduced. Running it in CI shifts detection left, so a risky dependency is caught before merge rather than in a quarterly audit. The key is tuning policy gates to reachability and severity so that pipelines block on real exposure instead of every version match.
Does SCA cover open-source license compliance too? Yes. Alongside vulnerabilities, SCA identifies each component's license and flags obligations or conflicts — for example, a strong copyleft license like GPL or AGPL appearing in a proprietary product. Mapping licenses across a deep transitive tree by hand is impractical, so SCA automates the detection and lets policy define which licenses are allowed, flagged, or blocked.
How does modern SCA differ from legacy scanners like Snyk or Black Duck? Legacy scanners lean heavily on version-to-CVE matching, which is why their output is dominated by unreachable findings. The differentiator in 2026 is reachability plus AI-assisted triage and merge-ready fixes rather than a longer list of matches. Our comparison with Snyk and comparison with Black Duck walk through how a reachability-first approach changes both the finding count and the time-to-remediation.
How does SCA handle actually fixing vulnerabilities? Detection is only half the job; the value is in remediation. Once a reachable, exploitable vulnerability with a safe upgrade path is confirmed, Safeguard's automated fix pull requests propose the patched version directly in your workflow and run your pipeline against the change. That turns a triaged finding into a merge-ready fix instead of another open ticket sitting in a backlog.
Can I avoid vulnerable dependencies in the first place? Partly, yes — the cheapest vulnerability is the one you never introduce. Choosing well-maintained libraries, pinning versions with lockfiles, and preferring components with a clean security history all reduce inbound risk. Safeguard maintains a catalog of 500,000+ vetted, zero-CVE components so teams can standardize on dependencies that start clean rather than remediating them after the fact.
Register at app.safeguard.sh/register, or read the documentation at docs.safeguard.sh.