A dependency scan reads your project's manifest and lock files, lists every open source component and version it finds, including those pulled in indirectly, and compares each against known vulnerability data. It tells you what is inside and what has known flaws. It does not read your own code for bugs.
The three steps
- Inventory. The scanner reads files such as package manifests and lock files and builds a list of components with names and versions. This list is, in effect, an SBOM. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components.
- Matching. Each component and version is compared against vulnerability databases. A match means a published advisory covers that version.
- Reporting. Findings are shown with severity, the version that contains a fix, and where in your project the component comes from.
Direct and indirect parts
You choose some components yourself. Those pull in others, which pull in more. Many projects end up with far more indirect parts than direct ones. A scan that follows the whole tree finds flaws you never knowingly added.
What it finds, and what it does not
| Finds | Does not find |
|---|---|
| Known vulnerabilities in open source components | New bugs in your own code |
| Which version contains a fix | Flaws no one has published yet |
| Components pulled in indirectly | Problems in a service you call but do not ship |
| Components you did not know about | Configuration mistakes in your servers |
A clean result means no known issue in the matched components today. It does not mean the app is safe, and tomorrow's advisories can change the answer.
How to read the results
Not every finding deserves the same urgency. Ask three questions of each one:
- Is a fix available, and is the upgrade small or large?
- Does the flaw sit in code my app actually calls? This is what reachability analysis answers.
- Is the flaw known to be exploited in the wild? CISA's KEV catalog lists those.
Start with findings that are reachable and exploited, then work down.
What to do after the first scan
- Save the inventory so you have a record of what shipped.
- Fix the top few findings first, rather than all at once.
- Set a rule for new code, such as blocking critical flaws in pull requests.
- Re-scan on a schedule, since new advisories arrive daily.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation produce the inventory, reachability analysis cuts the list down to what your code can reach, and policies and gates keep new risk out of pull requests. Fix PRs can be opened for review, with autonomous remediation off by default and every category on Manual. You can run the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component and see where it came from, whether it is direct or indirect, and which version fixes it.
Quick check
Does a dependency scan look at my own source code?
No. It checks the open source parts you use. Reading your own code for bugs is a different kind of scan.
Will a scan change my code?
A scan only reads and reports. Any fix is a separate step that you review and approve.
Sources
Last reviewed: 19 October 2026.
