A vulnerability scanner works in six stages. It lists what you run (inventory), compares that list with advisory data (matching), adds context such as severity and exploit signals (enrichment), ranks the results (prioritization), presents them (reporting) and passes work to the people who fix it (remediation handoff). Most scanner problems trace back to one weak stage.
The six stages in one table
| Stage | Question it answers | Typical input | Typical output |
|---|---|---|---|
| Inventory | What is in this project or image? | Lockfiles, manifests, package databases, image layers | A list of components with names and versions |
| Matching | Which components have known advisories? | Component list plus advisory databases | Candidate findings |
| Enrichment | What else do we know about each finding? | Severity scores, exploit data, fix versions | Findings with context |
| Prioritization | Which ones matter first? | Enriched findings plus your environment | An ordered queue |
| Reporting | How do we show it? | The queue | Dashboards, SARIF, PDFs, tickets |
| Remediation handoff | Who fixes it, and how? | Reports plus ownership data | A pull request or ticket |
Treat the stages as a pipeline. An error early on flows downstream. If inventory misses a package, no later stage can recover it. If matching is too loose, every later stage spends effort on noise.
Stage 1: inventory
The scanner builds a list of components. It reads files that describe what you depend on, or inspects what is actually installed. Each source has blind spots, which is why inventory sources are worth understanding on their own.
Stage 2: matching
Each component is compared with advisory records. A record names an ecosystem and package, then describes affected versions. The OSV schema, for example, expresses this with an affected list, and ranges built from events such as introduced and fixed. A component matches when its version falls inside an affected range for the same package in the same ecosystem.
Stage 3: enrichment
A bare match says little. Enrichment attaches fields: a severity score, a weakness category, whether the issue is known to be exploited, how likely exploitation is, and which version fixes it. These come from different publishers, so they can disagree.
Stage 4: prioritization
Thousands of matches become a short list by applying filters (is the code reachable, is it a development-only package) and rankings (known exploitation, exploit probability, asset importance). Severity alone is a weak sorter, because it describes a vulnerability in general, not in your system.
Stage 5: reporting
The same findings need different shapes for different readers. Engineers want file paths and fix versions. Managers want trends. Auditors want dated evidence. Machine formats such as SARIF let other tools consume results.
Stage 6: remediation handoff
A finding that never reaches an owner is just a number. Good handoff names the component, the safe version, the repository, and the person or team who can act, ideally as a pull request that is ready to review.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow one finding from detection to resolution and notice where context gets added along the way.
Where Safeguard fits
Safeguard covers these stages with SBOM and dependency scanning, reachability analysis, policies and gates, and autonomous remediation that opens fix pull requests (off by default, every category on Manual). You can try a free scan on your own project.
Quick check
Which stage causes the most missed vulnerabilities?
Inventory. A component that was never listed cannot be matched, enriched or reported, so the scan looks clean while the risk remains.
Is enrichment the same as prioritization?
No. Enrichment adds facts to each finding. Prioritization uses those facts, plus your own context, to decide the order of work.
Sources
Last reviewed: 19 October 2026.
