Every mid-size company gets to the point where they realize they need a vulnerability management program. Auditor asks for one. Insurance policy requires one. Or an engineer notices the scan reports have been piling up unread.

The instinct is to buy a tool. Deploy the scanner, wire up the dashboard, pipe findings into a ticket queue, and declare the program running. Six months later the ticket queue has 4,000 open findings, engineering ignores it, the security team burns out chasing status, and everyone concludes vulnerability management “doesn’t work here.”

It doesn’t work because the program was designed around the wrong assumption from day one: that vulnerability management is a security team problem. It isn’t. It’s a shared workflow between security and engineering, and the design decisions you make in the first few weeks determine whether that workflow can survive contact with real work.

Here are the failure modes that break VMPs, drawn from real deployments including a fully custom, budget-constrained VMP I recently built end to end. This post is about the design principles that come before tooling — the ones you have to get right in the first few weeks or spend the next year fighting.

Part 1 of a 6-post series on vulnerability management. Later posts go deep on scanner architecture, prioritization beyond CVSS, SLA design, automation with n8n, and metrics that actually matter. Full series overview at the bottom.

Failure Mode 1: CVSS-Only Prioritization

The single most common design mistake is pointing your ticket queue at raw CVSS scores. A “Critical” finding on an isolated internal test box outranks a “Medium” finding on your internet-facing payment service. Engineering catches on within a week, loses trust in the queue, and starts ignoring it.

CVSS is one input, not the answer. Real prioritization needs at least four inputs:

  • Exploitability — is there a known exploit in the wild? (CISA KEV, EPSS score)
  • Exposure — is the affected asset internet-facing, or behind a bastion, or air-gapped?
  • Data sensitivity — does this asset handle payment data, PII, source code, or dev-only test data?
  • Blast radius — if this gets exploited, does it compromise one machine or your entire environment?

A CVSS-7 on an internet-facing service handling payment data with a known exploit is genuinely critical. A CVSS-9 on a dev sandbox with no sensitive data is not. Any program that can’t distinguish between them will drown in noise, and engineering will correctly conclude the queue is signal-free.

The prioritization design specifically is the topic of post #3 in this series. For now: if your program prioritizes by CVSS alone, you already have a fatal design flaw.

Failure Mode 2: Security Owns the Fix Queue

The moment security team ends up being the ones responsible for closing findings — chasing engineering managers, updating ticket status, opening JIRA sub-tasks — the program is dead. Not because security lacks skill, but because engineering doesn’t own the outcome.

The pattern is predictable. Security team stands up the program. Findings appear in a queue. Engineering doesn’t know what to do with them, so security starts triaging, categorizing, and assigning. Engineering learns that findings will get handled by “someone else” if they wait long enough. Without deliberate countermeasures, security ends up carrying a workload that scales with finding volume — which scales with the environment. Findings age. Program collapses.

The fix is a design decision made on day one: vulnerability management is a shared responsibility, and engineering owns the fix. Security’s job is to identify, prioritize, provide context, and hold the SLA. Engineering’s job is to fix, defer with justification, or escalate the risk.

Getting this right isn’t a policy statement — it’s an onboarding process. Every engineering team that owns a service needs to be walked through:

  • Which findings will land in their queue
  • How they’re prioritized and why
  • What SLAs they’ve agreed to
  • How to defer or dispute a finding
  • How to escalate if a fix isn’t feasible

Skip this, and you have a program where security cares and engineering doesn’t. That’s an org chart problem you can’t fix with better tooling.

Failure Mode 3: SLAs Designed Unilaterally

Related failure mode: security decides “Critical: 7 days, High: 30 days, Medium: 90 days” without ever asking engineering whether those timelines are achievable. Six weeks in, everything is out of SLA, dashboards are red, and the meaning of “SLA breach” collapses because breach is the default state.

SLAs are contracts. Contracts require agreement from both parties. If engineering hasn’t signed off on the SLA structure, they haven’t agreed to anything — and you don’t have an SLA, you have a wish list.

Real SLA design is negotiated. You get engineering leadership in the room and walk through:

  • What’s realistically fixable in 7 days? 30 days? 90?
  • What deferral paths exist (compensating controls, acceptance of risk, planned quarterly work)?
  • Who signs off when a finding needs to be deferred?
  • What happens when a finding ages past SLA — who escalates to whom?

The negotiation itself is the value. Once engineering has agreed to the SLA structure, they own it. They’ll defend it, prioritize against it, and push back on unrealistic security asks with data instead of resistance.

The SLA design pattern gets its own post (#4 in this series). The critical point: an SLA imposed unilaterally isn’t an SLA. It’s a metric that will be ignored, then removed, then quietly forgotten.

Failure Mode 4: Alert Fatigue from Unfiltered Scanner Output

Modern scanners produce thousands of findings for medium-sized environments. Container image scans alone can produce hundreds of findings per image. Send that raw output to engineering and you’re not running a vulnerability management program — you’re running a denial-of-service attack on your own dev team.

Every finding that reaches engineering needs to have already passed through:

  • Deduplication — same CVE across 100 images = 1 remediation task, not 100
  • Suppression rules — known false positives, unavoidable transient issues, findings on components you don’t ship
  • Context enrichment — the finding needs to arrive with asset, exposure, data classification, and priority attached, not as a raw CVE ID
  • Threshold filtering — findings below the priority threshold don’t reach engineering; they age in a separate low-priority bucket

The scanner architecture and this filtering layer are the topic of post #2. The design principle: if engineering sees the raw scanner output, the program has already failed at the input stage.

Failure Mode 5: No Feedback Loop

Programs that “run” but never improve share a pattern: security tracks findings closed, engineering tracks nothing, leadership sees a green dashboard, and the underlying question — are we actually getting more secure — is never answered.

The feedback loop that fixes this needs three things:

  • Metrics engineering cares about — mean time to remediate, deferral rate, findings by service, findings per release. Not just security’s dashboard.
  • A regular review — monthly or quarterly, security and engineering leadership sit down and look at the numbers together. What’s stuck? What’s ageing? What’s getting deferred repeatedly and why?
  • Program iteration — SLAs adjust based on real data, priorities shift as the environment changes, tooling gets tuned.

The metrics design (what to track, what to show leadership vs your team) is post #6 in this series. The design principle: a program with no feedback loop is not a program, it’s a report generator.

What Actually Works: Shared Responsibility From Day One

The programs that survive share one thing: security and engineering agreed on the design before the first scan ran.

That agreement looks like:

  • Ownership is defined. Every service has a team that owns its findings. Security doesn’t own fixes; security owns the process.
  • Prioritization is contextual and mutual. CVSS is one input. Exposure, data sensitivity, exploitability, and blast radius are the others. Engineering and security agree on how these combine.
  • SLAs are negotiated. Realistic timelines that engineering signed off on. Clear deferral and escalation paths.
  • Findings arrive filtered and contextual. Not raw scanner output. Dedup, suppression, and enrichment happen before findings reach engineering.
  • Metrics are shared. Both teams see the same numbers and iterate on the program together.

None of this is about tooling. You can do it with a spreadsheet and email if you have to (I don’t recommend it, but you can). Conversely, the most expensive VMP platform on the market won’t save a program that skipped these design decisions.

That’s the real lesson: budget doesn’t fix a broken VMP design, and design doesn’t require budget. The fully custom, budget-constrained VMP I recently built works because we got these design decisions right in the first two weeks. The next posts in this series walk through how each layer actually gets built.

The Rest of the Series

This is post #1 of a 6-part series on building a vulnerability management program that survives real engineering work. Coming next:

  • #2 — Designing the scanner architecture: coverage vs noise trade-offs
  • #3 — Prioritization that actually works: moving beyond CVSS
  • #4 — SLA design and how to enforce without burning out engineering
  • #5 — Automating the toil with n8n: patterns that scale
  • #6 — Metrics that matter to leadership vs your team

Posts land roughly every 2-3 weeks, interspersed with other AWS security content.

If you’re staring at a scanner backlog nobody’s fixing, or an audit deadline forcing you to spin up VMP from scratch on a limited budget — that’s the exact situation I’ve been through. Happy to talk through it.