To build a vulnerability management program, inventory your assets, scan them, rank findings by exploitation and exposure, assign each to an owner, set deadlines, and measure time to fix. Start small with your internet facing systems, then widen. CISA's BOD 26-04 and NIST SP 800-40 Rev 4 give a workable model.
Key takeaways
- The inventory comes first. CISA's directive requires tagging internet reachable assets with organization, environment, exposure and asset type.
- Rank by exploitation, exposure and impact, not severity alone.
- Every finding needs one named owner.
- Report on time to fix, not on counts of findings.
Step 1: What should I inventory?
Inventory everything you run: hosts, cloud resources, containers, applications and open source dependencies. For each, record an owner, environment and whether it is reachable from the internet. BOD 26-04 asks federal agencies to continuously tag internet reachable assets with organization, environment, exposure and asset type, which is a good template for any team.
Step 2: How do I find vulnerabilities?
Match scanners to asset types: a host scanner for servers, an image scanner for containers, and a dependency scanner for code. Scan on a schedule and on every build. You can start with a free dependency check at gold.safeguard.sh/scan, which runs in your browser on up to 100 dependencies.
Step 3: How do I decide what to fix first?
Use exploitation evidence first. Check whether the CVE is in the CISA KEV catalog, look at its EPSS score, and ask whether the asset is exposed. BOD 26-04 uses exposure, KEV status, automatability and technical impact. Use CVSS to break ties. The prioritization guide covers the details.
Step 4: Who fixes each finding?
The team that owns the asset. Route findings into the tracker that team already uses. A finding without an owner will not be fixed.
Step 5: What deadlines should I set?
Write a short policy with deadlines by risk tier, and a rule for exceptions with an expiry date. See the remediation SLA guide. Keep it to a few tiers people can remember.
Step 6: What should I measure?
- Time from detection to fix, by risk tier.
- Share of items fixed inside the deadline.
- Age of the oldest open exploited item.
- Asset coverage: what share of your inventory is scanned.
NIST SP 800-40 Rev 4 notes a disconnect between business owners and security teams over the value of patching. Reporting these numbers to both groups helps close it.
Try it yourself
Pick one product line. Build its asset list, scan it, and rank the top ten findings by KEV, EPSS and exposure. Assign owners and dates. That is a small working program.
Click through it at your own pace, or open it full screen.
Frequently asked questions
What are the stages of vulnerability management?
Common stages are discover assets, scan, prioritize, remediate, verify and report. The cycle then repeats.
How big a team do I need to start?
One person can start with an inventory, one scanner per asset type and a ranked top ten. Ownership by asset teams makes it scale.
Do I need a vulnerability management platform?
Not on day one. A spreadsheet and your scanners work for a small estate. Move to a platform when deduplication and ticketing become manual work.
How is a program different from running a scan?
A scan finds issues once. A program adds owners, deadlines, verification and reporting so issues get fixed.
Sources
- CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- NIST SP 800-40 Rev 4: https://csrc.nist.gov/pubs/sp/800/40/r4/final
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- FIRST EPSS: https://www.first.org/epss/
Last reviewed: 19 October 2026.
