What Practitioners Actually Think About Vulnerability Management

Where this comes from

Cloud Security Office Hours is a free, open Zoom that runs every Friday. Practitioners drop in, someone asks a question, the room works through it, and every session gets a published recap. Vulnerability management has come up in sixteen sessions since September 2024. This page draws on the eight where it was genuinely worked through rather than mentioned in passing, including one in July 2026 given over to it almost entirely.

This is not a survey and not a consensus document. It is what people said to peers rather than to a camera. No attendee is named. Where sessions contradicted each other, both views are here. Where a member described their own experience with a named product, it is reported as their experience and not as a recommendation.

Nobody trusts the score, everybody still uses it

The most consistent position across two years is that a CVSS score answers a question almost nobody is actually asking. In the September 27, 2024 session the room worked through a vulnerability that had been widely reported as a 9.9 remote code execution and concluded it was far less severe in practice, because exploitation required a long chain of unlikely conditions. The observation that stuck was structural rather than specific: CVSS scores the worst imaginable case, so a score is a ceiling, not an estimate.

That session also put the alternatives on the table. EPSS was described as measuring the likelihood a vulnerability gets exploited in the next thirty days, which is a different question from how bad it would be. The same discussion noted that CVSS scoring is subjective, with different numbering authorities producing different assessments of the same flaw.

The pattern repeated with a React vulnerability in the December 5, 2025 session: a high CVSS score, but limited real risk because few organizations had adopted the affected server components. That session also raised CVSS version 4 and a question that recurs constantly here, which is how reachability should be assessed and who is responsible for assessing it, the vendor or the customer.

By the July 17, 2026 session the framing had settled: CVSS, EPSS, and the CISA KEV catalog were described as all reaching for the same goal from different angles, with the deciding factor being environmental and temporal context rather than which scale you pick.

The plumbing quietly broke

One of the more useful things in the archive is not an opinion at all. In the July 17, 2026 session, an attendee who works in this space laid out the current state of vulnerability enrichment: the National Vulnerability Database stopped enriching vulnerabilities roughly two years earlier and now enriches only what is relevant to the federal government, so vendors have shifted to leaning on scores supplied by CVE Numbering Authorities for metadata.

The numbers offered alongside that are the part worth carrying around. Roughly 90 percent of vulnerabilities now carry a CNA-supplied CVSS score, but only 10 to 20 percent carry CPE (Common Platform Enumeration) information. CPE is what tells you which product and version a vulnerability actually applies to. A score without a CPE is a severity rating you cannot reliably match against your own inventory, which quietly undermines any pipeline that assumes matching can be automated.

This had been visible for a while. The April 4, 2025 session already discussed developments at the National Vulnerability Database and the difficulties they created for vulnerability management, along with the need for alternative approaches and a new consortium forming to tackle vulnerability data. What changed by 2026 is that the workaround (leaning on CNA-supplied metadata) became the default rather than the fallback.

This is the sort of detail that rarely makes it into a vendor deck, and it reframes a good deal of the frustration elsewhere in these sessions: some of what looks like a prioritization problem is really a data-quality problem upstream of prioritization.

Context is the whole game

If there is a house position, this is the closest thing to it. The July 17, 2026 session put it directly: the window between disclosure and exploitation has collapsed from weeks to hours or minutes, so the useful work is understanding attack surface and which endpoints are actually reachable, rather than continuing to enumerate everything that exists.

The structured version of that argument is SSVC, and it comes up twice. The September 27, 2024 session introduced it as a decision-tree model weighing exploitability, automatability, scope, and asset context to decide what to do about a given vulnerability, noting it was open source and already adopted in industry. The June 12, 2026 session returned to it as CISA formalized it in a binding operational directive, weighing exposure, known exploitation, automatability, and impact.

That second discussion is more interesting than the first because it covered the friction rather than the theory. Attendees flagged a three-day patching expectation for high-risk vulnerabilities as difficult to meet in practice, and noted that because CISA writes for federal agencies, any non-federal organization adopting SSVC has to do custom work to map it onto whichever compliance framework it already answers to.

The same July 2026 session described vulnerability management converging with attack surface management, which is arguably just this argument taken to its conclusion: if reachability is what matters, the inventory of what is exposed matters more than the inventory of what is vulnerable.

Why patching stalls

The sessions are unusually blunt that the bottleneck is rarely knowing about the vulnerability. In the July 17, 2026 session an attendee working with large heterogeneous estates described the real constraint as patching itself, including the risk of breaking production workloads, a concern that does not appear anywhere in a severity score.

Container images make this concrete. The May 9, 2025 session included a walkthrough of why container vulnerability management behaves differently: images are built in layers, and a running container is a copy of a gold image rather than something you patch in place. The remediation path is patch, rebuild, retest, redeploy, which puts the fix in a development pipeline rather than an operations one, and explains why container findings accumulate.

Deadlines imposed from outside are their own pressure. The August 1, 2025 session worked through FedRAMP remediation service levels of 30, 90, and 180 days for critical, high, and medium findings, and weighed the available approaches against them. Set that beside the three-day expectation in CISA's directive discussed a year later and the range of what "timely" is supposed to mean becomes the point.

Grouping is the other lever. The April 4, 2025 session explored targeting critical vulnerabilities first, fixing many at once rather than individually, and moving to more secure base images, all versions of getting more remediation out of a single unit of engineering effort.

Automation as the escape hatch has been debated since at least the October 11, 2024 session, where auto-remediation was described as being in growing demand from overwhelmed teams facing personnel shortages, while the room agreed it is genuinely hard to implement well at scale. The July 17, 2026 session revived the idea in a sharper form, with one attendee advocating bulk automated fixes over individual tickets and citing a vulnerability that had gone unaddressed for 200 days as evidence that the ticket-per-finding model does not clear the backlog.

Minimalism: fix it by not shipping it

A theme that grew over the archive is that the cheapest vulnerability to manage is the one you never installed. The July 17, 2026 session named this directly as a trend toward minimalism in security, where removing unnecessary components reduces the population of vulnerabilities you have to triage at all.

The August 1, 2025 session is the one with numbers attached. Patrick Burke of Chainguard presented on minimal container images and ran a live demo building the same Python application on four base images, then scanning each with Trivy. The stock python image produced 1,699 vulnerabilities (269 critical or high), python:slim dropped that to 90, python:alpine to 3, and the vendor's own base image to 2. That is a vendor demonstrating a vendor product and should be read as such, but the shape of the curve is the point and it is not really in dispute.

The framing offered there is the useful part: CVE counts have climbed year over year for close to a decade, so adding engineers to remediation scales badly, and the industry response is to shrink the surface that can carry a vulnerability at all. The May 9, 2025 session made the same argument from the mechanics of image layering, and the April 4, 2025 session arrived at more secure base images from the opposite direction, as one of several ways to stop fighting findings one at a time.

This connects back to the reachability argument. Both are attempts to attack the denominator rather than grinding through the numerator.

Organization size changes the answer

Several sessions land on the same uncomfortable point: advice that works at one scale is actively wrong at another. The July 17, 2026 session contrasted a large enterprise scanning pull requests for vulnerabilities with a smaller organization applying conventional controls to newer infrastructure, and an attendee argued that smaller, more agile organizations hold a real advantage over estates built on large legacy systems. Another attendee described how strategies differ by industry, using financial services as the example, and emphasized that the hard part is scaling remediation rather than scaling detection.

The June 12, 2026 session approached scale from the inventory side, asking how organizations track and secure GitHub repositories across an entire organization rather than one repository at a time, specifically to surface shadow IT and supply-chain exposure. That session also acknowledged that securing GitHub Actions is genuinely hard because the runners are transient, and discussed layered access controls (conditional access through the identity provider, CASB, SASE) as the practical response.

Where the room disagrees

These are live disagreements, not strawmen. None of them were settled.

Is vulnerability management working?

This is the sharpest split in the archive and it happened in a single exchange in the July 17, 2026 session. One position was that despite the well-rehearsed complaints, existing approaches still deliver real benefit and should be improved rather than abandoned. The counter-position was that the premise of constant patching deserves to be challenged outright, with guardrails and defense in depth doing more for less effort. A third attendee pushed back on the most radical version of that, arguing that writing custom code to avoid dependencies introduces its own vulnerabilities, and that environmental controls such as web application firewalls have real limits as compensating measures.

Should you trust a composite score, or any single vendor's version of one?

Also from the July 17, 2026 session: one attendee raised concerns both about blending multiple metrics into a single number and about depending on any one vendor's scoring, while another argued the various models are converging on the same problem and that the fix is supplying proper environmental and temporal context rather than picking a winner. Nothing resolved this.

Bulk automation or human triage?

The October 11, 2024 and July 17, 2026 sessions both circle this without landing. Auto-remediation is agreed to be in demand and agreed to be difficult to do safely at scale. The unresolved question is whether the failure mode of automated bulk fixes is worse than the failure mode of a backlog nobody ever works through.

How far should a score be trusted by whoever receives it?

A quieter thread from the September 27, 2024 session: one attendee raised the risk that vulnerability scores get misinterpreted downstream, while others in the room were actively trying to learn how these models are applied in practice. The concern is not that the models are wrong, it is that a number travels further than the caveats attached to it.

FAQ

Is this an official position of Cloud Security Office Hours?

No. It is a synthesis of what attendees said on the live Friday call across eight sessions. CSOH is vendor-neutral and takes no house position on vulnerability management, on any scoring system, or on any vendor named here. Where attendees disagreed, both sides are reported rather than reconciled, and opinions are labeled as opinions.

Why are no individual attendees named?

The Friday session is open to anyone, but it is a conversation, not a publication. People think out loud, change their minds, and talk about their employers informally. Attributing opinions to named individuals would change what people are willing to say. Guest speakers who presented publicly are named, because presenting is a public act.

How were these sessions selected?

They are the recaps between September 2024 and July 2026 in which vulnerability management was a substantive part of the discussion rather than a passing mention. Every claim on this page links to the recap it came from, so any reader can check the source.

Does this page tell me which scanner to buy?

No, and deliberately so. Members name the tools they use in passing, and those mentions are reported as individual experience rather than as evaluation. The site owner works at a vendor in this space, which is one more reason this page reports the argument rather than picking a product.

Can I join the Friday session?

Yes. It runs every Friday, it is free, there is no pitch, and there is no requirement to speak. Details are on the sessions page, and every past session has a published recap.