How to set up a vulnerability management program

Most organizations don't fail at vulnerability management because they lack tools — they fail because they never built a program around the tools. A scanner generates ten thousand findings, nobody owns triage, patches ship on no fixed cadence, and six months later the same critical CVE that should have been closed in a week is still sitting open in production. If you're starting from scratch or trying to formalize something ad hoc, this guide walks through exactly how to set up a vulnerability management program that survives contact with a real engineering org: scope and ownership, a scanning cadence, a risk-based triage model, a patch management process, and the metrics that prove it's working. By the end, you'll have a repeatable vulnerability management lifecycle you can run every week without heroics.

Step 1: Define Scope and Ownership Before You Set Up a Vulnerability Management Program

Before touching a scanner, decide what's in scope and who is accountable. Programs collapse when "everyone owns security" quietly becomes "no one owns security." Concretely:

• Asset inventory first. You can't manage vulnerabilities on assets you don't know exist. Pull an inventory from your cloud provider, CMDB, container registry, and source control. At minimum, tag each asset with an owning team.

# Example: pull a quick asset baseline from AWS
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters ec2:instance ecs:service lambda:function \
  --query 'ResourceTagMappingList[].{ARN:ResourceARN,Tags:Tags}' \
  --output json > asset-inventory.json

• Assign a program owner (usually security engineering) and remediation owners (the engineering teams that actually hold the keys to the affected systems). Write this down in a one-page RACI — it will get referenced in every escalation you ever have.
• Set severity-based SLAs up front. For example: Critical = 7 days, High = 30 days, Medium = 90 days, Low = best effort. These numbers become the backbone of every later step.

Step 2: Choose Scanners That Cover Your Full Stack

A single scanner rarely covers everything. Most mature programs combine:

• SCA (software composition analysis) for open-source dependencies and container base images
• SAST for first-party code
• DAST for running web applications and APIs
• Cloud/infrastructure scanning for misconfigurations (IAM, storage, network exposure)
• Secrets scanning across repos and CI logs

Wire these into CI/CD so findings surface before merge, not after deploy:

# .github/workflows/vuln-scan.yml
name: vulnerability-scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run SCA scan
        run: safeguard scan sca --path . --fail-on=high
      - name: Run container scan
        run: safeguard scan image --tag ${{ github.sha }} --fail-on=critical

Don't stop at CI — pipeline scans only catch what's committed today. New CVEs get disclosed against dependencies you shipped months ago, so you need scheduled, environment-wide scanning too (that's the next step).

Step 3: Build a Vulnerability Scanning Schedule

This is where a lot of programs quietly stall: they scan once during a security review and never again. A defensible vulnerability scanning schedule usually looks like this:

A simple cron-based cadence for a nightly full-environment scan:

# /etc/cron.d/vuln-scan
0 2 * * * root safeguard scan environment --scope production --report-to slack://sec-alerts

The point of a fixed schedule isn't the calendar entry — it's that newly disclosed CVEs against dependencies you already shipped get caught within a bounded window, instead of whenever someone happens to re-scan.

Step 4: Triage by Exploitability, Not Just CVSS Score

CVSS alone produces noisy backlogs — plenty of "critical" CVEs are unreachable in your environment, and plenty of "medium" ones are being actively exploited. Layer in:

• Reachability: Is the vulnerable function actually called in your code path?
• Exposure: Is the asset internet-facing, or buried three network hops behind a private VPC?
• Known exploitation: Cross-reference against CISA's KEV (Known Exploited Vulnerabilities) catalog.
• Compensating controls: WAF rules, network segmentation, or runtime protections that reduce real-world risk.

A basic triage decision matrix:

if CVE in CISA-KEV: severity = CRITICAL, SLA = 48h
elif reachable AND internet_facing: severity = HIGH
elif reachable AND internal_only: severity = MEDIUM
elif not_reachable: severity = LOW / accept_risk (document justification)

Document every risk acceptance with an expiration date and a named approver. Undocumented "we'll get to it" exceptions are the single most common audit finding in SOC 2 and ISO 27001 reviews.

Step 5: Formalize the Patch Management Process

Triage tells you what to fix; the patch management process is how it actually gets fixed without breaking production. A workable process includes:

1. Ticket creation — auto-file a ticket in your tracker (Jira, Linear) the moment a finding crosses your SLA threshold, pre-populated with severity, affected asset, and owning team.
2. Patch testing — run patched dependencies through your standard CI suite plus a targeted regression pass for anything touching the vulnerable code path.
3. Staged rollout — canary or blue/green deploy the patch to a subset of traffic before full rollout, especially for critical infrastructure.
4. Rollback plan — every patch ships with a documented rollback path; don't patch production without one.
5. Verification — re-scan the asset post-deploy to confirm the finding is actually closed, not just marked resolved in the ticket.

# Example: re-scan a single asset after patch deployment to confirm closure
safeguard scan image --tag app:patched-2026-07-06 --compare-to app:2026-06-28

Automate what you can — dependency bots (Dependabot, Renovate) handle the bulk of low-risk patch PRs — but keep a human gate on anything touching production auth, payment, or data-access paths.

Step 6: Report on the Lifecycle, Not Just Open Findings

A vulnerability management lifecycle only proves itself over time. Track and review these metrics monthly with engineering leadership:

• Mean time to remediate (MTTR), broken out by severity
• SLA compliance rate — percentage of findings closed within their committed window
• Open critical/high count, trended over time (not just a snapshot)
• Recurrence rate — vulnerabilities that reopen after being marked fixed, often a sign of incomplete patches or missing regression coverage
• Scan coverage — percentage of known assets actually being scanned on schedule

Feed these into a recurring risk review with leadership. This is also the artifact auditors will ask for first if you're pursuing SOC 2, ISO 27001, or a customer security questionnaire — a documented, repeatable lifecycle with metrics is worth far more than a clean scan on the day of the audit.

Troubleshooting and Verification Checklist

Once the program is running, use this checklist to confirm it's actually working rather than just producing reports:

• Findings pile up faster than they close — check whether your scanning schedule is outpacing remediation capacity. Consider tightening scan scope to reachable/exploitable findings first, or adding remediation headcount before adding scan coverage.
• Same CVE reopens repeatedly — usually means the patch was applied to one image/branch but not the golden base image, so it keeps reappearing in new builds. Fix the base image, not just the instance.
• SLA compliance looks good but audits still flag gaps — verify your asset inventory is complete. SLA math on an incomplete inventory is meaningless; shadow IT and unmanaged cloud resources are the most common blind spot.
• Engineering teams ignore tickets — confirm severity thresholds and SLAs were agreed with engineering leadership up front, not imposed unilaterally by security. Ownership without buy-in doesn't stick.
• Scanner findings don't match reality — periodically validate scanner output against manual testing or a third-party pentest; tooling drift and false positives erode trust in the whole program faster than almost anything else.
• No one can answer "are we compliant right now?" — if that question requires a manual spreadsheet pull, your reporting layer needs to move from ad hoc queries to a live dashboard tied to your ticketing system.

How Safeguard Helps

Safeguard is built to remove the manual glue work that usually breaks vulnerability management programs in their first six months. Instead of stitching together SCA, container, cloud, and secrets scanners by hand, Safeguard unifies findings across your software supply chain into a single risk-scored queue — factoring in reachability and exploitation status, not just raw CVSS. It enforces your vulnerability scanning schedule automatically across CI/CD and running environments, so nothing silently falls off the calendar, and it auto-generates and tracks tickets against your SLAs so the patch management process has an audit trail from disclosure to verified closure. For teams building toward SOC 2 or ISO 27001, Safeguard's reporting layer keeps the metrics auditors ask for — MTTR, SLA compliance, coverage — live and exportable, so proving your program works is a dashboard view, not a fire drill. If you're setting up a vulnerability management program today, Safeguard is designed to be the system of record you can run it on from day one.