A software composition analysis (SCA) tool lists the open source components inside your software, including nested ones, and compares each name and version with databases of known vulnerabilities. It then reports which components are affected and which fixed version exists. Many SCA tools also flag license terms and outdated or unmaintained packages.
Definitions
Component. A library, package or module your code pulls in, such as an npm package or a Maven artifact.
Direct dependency. A component you chose and declared in a manifest file.
Transitive dependency. A component that one of your dependencies pulled in. You did not pick it, but it ships with your software.
Known vulnerability. A flaw that has been published in an advisory database, usually with an identifier such as a CVE or GHSA number.
What the tool actually does
Most SCA tools work in four steps.
- Inventory. Read manifests and lockfiles, or inspect built artifacts, to build a list of every component and its exact version.
- Match. Compare each component with advisory data. The match depends on package name, ecosystem and version range.
- Report. Show the affected component, the advisory, severity, and a fixed version when one exists.
- Track. Re-check when new advisories appear, because a build that was clean last month can be affected today.
The OWASP Top 10 entry on vulnerable and outdated components says you are likely at risk if you do not know the versions of all components you use, nested dependencies included, and if you do not scan regularly. It recommends continuously inventorying component versions and using software composition analysis to automate the work.
What it does not do
SCA looks at components you did not write. It does not find a SQL injection in your own code, and it does not test a running application. Those jobs belong to static and dynamic testing.
SCA also reports presence, not use. A vulnerable function you never call can still appear as a finding. Some tools add reachability analysis to separate the two.
SCA output compared with related tools
| Tool type | Looks at | Typical question it answers |
|---|---|---|
| SCA | Third party components | Which of my dependencies have known flaws? |
| SBOM generator | Software contents | What is in this build, in a shareable format? |
| SAST | Your source code | Did we write an unsafe pattern? |
| DAST | A running app | Can this deployed app be attacked? |
How to start
- Commit your lockfiles so the exact versions are visible.
- Run a scan against the repository and read the direct findings first.
- Check whether each fixed version is a patch, minor or major change.
- Add the scan to continuous integration so new findings show up on pull requests.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a component and compare direct and transitive entries in the inventory.
Quick check
Does SCA find bugs in code my team wrote?
No. SCA covers third party components. Use static analysis for your own source and dynamic testing for a running app.
Is an SCA scan a one time job?
No. New advisories are published after you ship, so the same dependency list can produce new findings later.
Safeguard includes SBOM and dependency scanning plus reachability analysis. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
