How do VM, SCA and ASPM work together in one seven step flow?

They work as one flow: inventory the application, scan its dependencies with SCA, aggregate and deduplicate in ASPM, prioritize with exploit and context signals, route to an owner, fix, and verify by rescanning. Vulnerability management is the rulebook that sets deadlines and exceptions at every step.

The seven steps

1. Inventory. List repositories, services and images. You cannot scan what you have not found. This is the base of any program.

2. Detect with SCA. Read lockfiles and built artifacts, produce a dependency list, and match it to known vulnerabilities. Run it in the repository, in CI and against deployed images.

3. Aggregate in ASPM. Combine SCA findings with output from other scanners. Merge duplicates and link each finding to an application and a team.

4. Prioritize. Apply exploit signals such as the CISA Known Exploited Vulnerabilities catalog and EPSS, add reachability, and weigh exposure and data sensitivity.

5. Route. Create a ticket in the owning team's tracker with the deadline from policy, the fixed version, and the dependency path.

6. Fix. Upgrade, replace, mitigate or, with a documented exception and an expiry date, accept the risk.

7. Verify and report. Rescan to confirm. Close the ticket only when the scan agrees. Feed time to fix and open age into your reports.

Which layer does what

Where flows stall

Between 4 and 5. A ranked list exists, but nobody creates tickets. Fix: automate ticket creation for items above a threshold.

Between 5 and 6. Tickets sit in the backlog. Fix: put the deadline in the ticket and report on age by team.

Between 6 and 7. A fix is merged but never verified, and the finding reopens at the next scan. Fix: make the rescan part of the pipeline.

Before step 1. Shadow repositories and forgotten services never enter the flow. Fix: periodic discovery against your source host and registries.

Where to start

You do not need all seven steps automated on day one. A sensible order is detect, route, verify, then prioritize, then aggregate. Detection with no routing creates noise. Routing with no verification creates false confidence. Prioritization improves once there is a flow worth ordering. Aggregation matters when several tools exist.

NIST's patch management guidance describes the work as identifying, ranking, obtaining, deploying and confirming. The seven steps are the same idea, split out so each handoff has a name.

A worked example

Follow one finding through all seven steps. The details are illustrative.

1. Inventory. A payments service is in the application catalog with an owner team.
2. Detect. The nightly SCA run finds a vulnerable XML parsing library, version resolved from the lockfile, pulled in through a reporting package.
3. Aggregate. An image scan found the same library in the deployed container. After deduplication, one finding remains, tagged to the payments service.
4. Prioritize. The CVE is not on the CISA Known Exploited Vulnerabilities list, EPSS is modest, but reachability shows the parser is called on user uploaded files, and the service is internet facing. Policy places it in the second tier.
5. Route. A ticket appears in the payments team tracker, with a deadline, the fixed version and the dependency path.
6. Fix. The team upgrades the reporting package, which brings in the fixed parser. Tests pass.
7. Verify. The next scan no longer reports the library. The ticket closes automatically, and the time to fix goes into the monthly report.

Step by step: implement the flow with minimal tooling

1. Create the application catalog as a sheet with owner and exposure columns.
2. Schedule scans in CI and nightly against deployed builds.
3. Collect results in a shared place, with one row per finding.
4. Add KEV and EPSS columns and recompute weekly.
5. Write tiers and deadlines and apply them to the sheet.
6. Create tickets for tier one and two items using the team trackers.
7. Rescan after merges and close rows when the scan agrees.

What good looks like at each step

Signs the flow is leaking

• Findings older than the deadline with no ticket.
• Tickets closed while the scanner still reports the issue.
• Applications that never appear in any scan.
• Exceptions with no expiry date.

Pick the leakiest step and fix it before polishing the others. A flow is only as strong as its weakest handoff.

Try it yourself

Follow a single finding through detection, prioritization and fix in the demo.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard covers dependency scanning, reachability, policies and gates, and fix pull requests (off by default), which map to steps two, four, five and six. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• NIST SP 800-40 Rev. 4, enterprise patch management
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, EPSS

Last reviewed: 19 October 2026.