Vulnerability management in CI/CD: what to set up first

Set up vulnerability management in CI/CD in four steps: build an inventory of what ships, scan every pull request, rank findings with exploit evidence, then add a gate that blocks only what matters. Gating before you can rank findings trains developers to ignore the pipeline.

Why does order matter?

Most failed rollouts do the last step first. A team turns on a build breaker, the first run fails on four hundred findings, and within a week someone adds an exception that never expires. The gate exists but means nothing.

The fix is to earn the gate. Each stage below produces something the next stage needs.

Step 1: What is in the software?

You cannot manage what you cannot list. Generate a software bill of materials on every build, including transitive dependencies, base images and build tooling. Store it next to the build artifact so you can answer "do we ship this library?" in minutes, not days.

NIST's Secure Software Development Framework (SP 800-218) exists to give teams a common set of practices for reducing vulnerabilities in released software. An inventory sits underneath most of them.

Step 2: Scan where the change happens

Run the scan on the pull request, not only on the main branch. A developer who sees a finding on their own diff fixes it in the same session. A finding that appears a week later in a dashboard becomes a ticket.

Keep scans fast. If the check takes twenty minutes, people will merge around it. Cache the inventory, scan only what changed where your tooling allows, and run the deep scan on a schedule.

Step 3: How do you decide what to fix first?

Severity scores alone produce long lists. Add signals that say whether anyone is actually attacking the flaw.

• CISA's Known Exploited Vulnerabilities catalog lists flaws seen exploited in the wild. CISA says organizations should use it as an input to their vulnerability management prioritization framework.
• FIRST's EPSS gives a daily score from 0 to 1 estimating the chance a published CVE is exploited in the next 30 days.
• Reachability asks whether your code actually calls the vulnerable function. A flaw in a library you import but never invoke is a different problem from one on your request path.

Used together these cut a long list to a short one. Safeguard's reachability analysis is built for this step, and you can read how the check works in the demo below.

Open the CI/CD demo

Step 4: What should the gate block?

Start narrow. Block on known exploited flaws and on critical findings that are reachable. Warn on everything else. Review the rule monthly and tighten it as the backlog shrinks.

Give every exception an owner and an expiry date. An exception without an end date is a permanent hole.

Honest limits

No scanner finds everything. A scan sees known flaws in known components. It will not catch a logic bug in your own code or a stolen credential. Pair it with code review, secrets scanning and runtime monitoring.

Reachability results are an estimate. Treat "not reachable" as a reason to lower urgency, not as a clean bill of health.

What to do

1. Generate an inventory on every build and store it with the artifact.
2. Run a scan on each pull request and report findings in the review.
3. Add KEV, EPSS and reachability to your ranking.
4. Gate on exploited and reachable critical findings only.
5. Set an owner and expiry for every exception.
6. Review the gate rules once a month.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework
• CISA Known Exploited Vulnerabilities catalog
• FIRST, Exploit Prediction Scoring System

Last reviewed: 18 October 2026.