Start with the vulnerability management basics: an inventory, owners and deadlines. Add SCA second, so detection feeds a process that already exists. Consider ASPM last, when several tools and many applications make a single ranked view worth the effort. Tools without a process produce lists nobody acts on.
Why process first
If you buy SCA before agreeing on owners and deadlines, you get a long list and no one responsible for it. That is the most common way new tools fail. Setting the rules first costs a few hours and no budget.
Stage 1: the basics (weeks 1 to 2)
- Inventory. List repositories, services and where each is deployed. A sheet is fine.
- Owners. Assign a team or person to each application.
- Deadlines. Choose a short, written deadline for the most urgent findings, and longer ones for the rest. Base them on your capacity, not on someone else's template.
- Exceptions. Decide who approves one and for how long.
- Where tickets live. Use the tracker your developers already open.
Stage 2: add SCA (weeks 3 to 6)
- Scan the most important applications first, using lockfiles.
- Run it in CI so new dependencies are checked before merge.
- Triage the first results by hand to learn what the noise looks like.
- Rank using the CISA Known Exploited Vulnerabilities catalog and EPSS from FIRST, then add reachability where the tool provides it.
- Route the top items as tickets with the deadlines from stage 1.
OWASP's guidance calls for regular scanning and a patch management process. Stage 2 is where you start doing both.
Stage 3: tighten (weeks 7 to 10)
- Add rescans of deployed software so new advisories reach you without a release.
- Add a policy gate for the most severe, exploited and reachable cases.
- Start tracking two or three metrics such as time to fix and age of open findings.
Stage 4: consider ASPM (week 11 onward)
Ask whether you now have the problems ASPM addresses: several scanners, duplicate findings, unclear ownership across many applications, and a need for one report. If not, wait. If yes, evaluate with your own data and the checklist of what your findings must contain.
What to skip at first
- Dashboards for leadership before you have two months of data.
- Blocking every build on any finding. Begin in warn mode, then block narrow, well understood cases.
- Scanning everything at once. Coverage grows faster when the first group is fixed and trusted.
A note on capacity
A team of ten cannot fix every finding. The point of the order is to ensure the fixes you make are the right ones. A written policy that says what you will not fix, and why, is more useful than a backlog that silently grows.
A worked example
A team of 12 engineers, two product lines and 15 repositories follows the order below. The timeline is illustrative.
- Weeks 1 to 2. One person builds the application sheet with owners and writes a one page policy. Deadlines are agreed with engineering leads.
- Weeks 3 to 4. SCA runs on the 5 most important repositories. The first results are triaged by hand. About half are marked not reachable and parked with expiry dates.
- Weeks 5 to 6. SCA coverage extends to all 15 repositories. Tickets for the top tier flow into team boards.
- Weeks 7 to 8. A gate in warn mode appears on pull requests. After two weeks of observation, a narrow block rule is turned on for known exploited and reachable cases.
- Weeks 9 to 10. The team reviews three metrics and trims noisy rules.
- Week 11. A review concludes the shared sheet is still enough, so ASPM is deferred.
The team did not buy a new category and still ended up with a working program.
Step by step: your first 30 days
- Day 1 to 3. List applications and owners.
- Day 4 to 5. Draft the policy. Share it with two engineering leads for edits.
- Day 6 to 10. Run SCA on one important repository, read every finding, and note what is noisy.
- Day 11 to 15. Extend to the next four repositories and set up ticket creation.
- Day 16 to 20. Add a rescan of deployed software.
- Day 21 to 25. Add a pull request check in observe mode.
- Day 26 to 30. Review results and adjust the policy.
Decision points along the way
| Question | If yes | If no |
|---|---|---|
| Are findings reaching owners within a day? | Continue | Fix routing before adding tools |
| Is noise above what one person can triage? | Add reachability and exploit signals | Keep the current setup |
| Do multiple tools overlap in what they report? | Consider aggregation | Skip it for now |
| Are developers bypassing the gate? | Narrow the rules | Consider tightening gradually |
Cost control without prices
Time is the main cost for a small team. Avoid projects that create ongoing manual work, such as hand editing exports every day. Prefer automation that runs in CI and ticket creation that needs no human step. Where free options exist, such as a one off free scan to learn what your first list looks like, use them to calibrate before committing to larger changes.
Try it yourself
Open the sample pull request and see which dependency changes warn and which block.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard supports stages two and three with dependency scanning, reachability analysis, policies and gates, and a free scan at gold.safeguard.sh/scan is a low effort way to see what the first list looks like.
Quick check
Can I skip stage one if I buy a good tool?
No. Without owners and deadlines the tool produces findings that no one is accountable for.
When do I really need ASPM?
When multiple scanners and many applications make duplicate findings and ownership gaps hard to manage by hand.
What if leadership wants a dashboard in week one?
Offer a simple snapshot of coverage and open items by tier, and explain that trend lines need a month or two of data to be meaningful.
Sources
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, EPSS
Last reviewed: 19 October 2026.
