By Matthew Venne | November 5, 2026
Vulnerability remediation used to be a calendar problem. Find the CVE, look up the severity, pick the SLA, patch inside it. For FedRAMP-style programs that usually meant 30 days for a critical, or 14 if you take the stricter reading. Either way, the answer to “what do we do?” was “patch it before the clock runs out.”
The new Vulnerability Detection and Response (VDR) model asks something different: given what we know about this vulnerability and where it lives, what do we do right now? We got a very real lesson in the difference last week.
The vulnerability
One of our FedRAMP authorized solutions, the one that hosts agency work, runs on Kubernetes. Like a lot of teams, we were hit by the new Brotli decoder out-of-bounds write (CVE-2026-111497). Brotli is everywhere. It’s baked into web servers, proxies, language runtimes and base images, so it showed up in a lot of places in our system, including components reachable directly from the internet. Notably, the affected components were third-party vendor images rather than our own code.
CVSS called it critical. If you’re working from the traditional playbook, you’re now debating whether your window is 30 days or 14.
Then it showed up on KEV
That debate ended when CISA added it to the Known Exploited Vulnerabilities (KEV) catalog.
KEV doesn’t care about your scanner’s severity score. A KEV listing means someone is exploiting this in the wild today, and the remediation deadline comes from the listing itself rather than from CVSS. Ours landed on November 10: about 12 days out, well inside even the aggressive end of the old range.
The EPSS score told the same story at 82.64%, and the finding was internet-reachable. Every signal pointed the same direction.
The part we couldn’t patch
Here’s where it got interesting. The vulnerable components weren’t code we wrote. They were running third-party vendor images, software we deploy and operate but don’t build or control, and they were internet reachable. We can’t rebuild the image or bump a version in our own tree. The fix has to come from the vendor.
That’s the uncomfortable combination: the exposure is ours, since we’re the ones running it on the internet for agencies, but the fix isn’t.
We went to the vendor and asked for a patch. They were already working on one, but their release date was November 12, two days after our deadline. We told them what that gap meant on our side: this was a KEV, it was prevalent across the images they provide, and it was sitting on internet-exposed workloads. And we didn’t wait for their answer.
The traditional move here is to file a deviation request, note “waiting on vendor,” and wait. But that was never really the right move; it’s just the one the process made easy. Too many programs treated remediation clocks as a compliance cycle, a date to hit or a paper trail to produce, instead of asking what the clocks were meant to protect: the system and the government’s data.
VDR is closer to what we should have been doing all along. Whether or not we can patch in time is beside the point. The vulnerability is severe, actively exploited and internet-reachable. Something has to change today to limit exposure, and the patch isn’t what changes it.
So we mitigated
We put a WAF rule in front of the exposed component right away, then:
- Tested for impact. We validated that legitimate traffic wasn’t affected before leaving it in place.
- Told our agency customers first. We contacted them about what we were about to do and why. We hadn’t seen application impact, but we said plainly that a WAF rule can cause disruption, asked them to tell us if they noticed anything, and committed to removing the rule once the vendor patch lands.
- Kept the patch on the books. The WAF rule is a mitigation, not a resolution. The finding stays open until the vendor fix ships and we’ve rolled it out.
There’s a subtlety worth calling out. Under the new federal rules, mitigating a non-KEV vulnerability can extend or reset the remediation clock, so a mitigation can earn you a compliance win. On a KEV, it doesn’t. The clock is the clock whether you mitigate or not, and the November 10 deadline stood regardless of the WAF rule.
We mitigated anyway, because we weren’t doing it for the clock. A mitigation that doesn’t buy you time is still the right thing to do when a known-exploited, internet-reachable vulnerability is sitting in front of the government’s data. Not getting credit for it doesn’t absolve you from doing what’s right.
It was a bit of a circus. But this is just how it works now: you take the action that reduces risk today and you’re transparent about it, rather than waiting for a fix you don’t control.
What made it tractable
The reason this was a one-day response instead of a week-long scramble is the tooling we’ve been building for VDR: our open source Trivy-based scanner and the vulnerability tracking system built specifically for VDR.
The question that normally eats the first several days of an incident is where is this, and how bad is it here? We had the answer almost immediately:
- Every affected workload, including child workloads, across the whole system.
- Which ones are internet-reachable, which is what separated “act now” from “track it.”
- The context for each finding: exposure, exploitability, KEV status, EPSS, and the deadline, in one place.
Each finding is scored on more than severity. It carries an impact rating (here N3, “Disruptive”), exposure (IRV, directly internet-reachable), exploitability (LEV) and KEV status, and from those it derives a deadline.
The “why this is hot” panel is the part we use most. It spells out why a finding got the priority it did: internet accessible, directly reachable, on the CISA KEV list, high EPSS.
And it’s tracked down to the individual workload, so we know exactly which deployments and containers need the patch or a mitigation.
It works the other way too. TSW tracks vulnerability counts on each component, and affected-component counts for each vulnerability or rule. A finding preserves the remediation component: the place a lasting fix has to land, down to each container or init-container reference and, for VMs, the scaling group that recreates them (an AWS ASG, GCP MIG or Azure VMSS). That shows how far a vulnerability has spread and which configuration locations still need action, which makes “how prevalent is this, really?” trivial to answer. For this one CVE, the tracker listed 22 affected components, each one a place the fix had to land.
Making the mitigation official
A WAF rule that only lives in a Terraform file isn’t much use to an assessor or an agency. We also need a record of what we did, who approved it, and how it changes the way we score the finding. That’s what attestations are for.
Any time we put a mitigation in place, we file an attestation against the affected findings in the tracker. It goes through an approval process: one person submits it, and a different person reviews and approves it. The attestation spells out exactly what was done in the system and how it works, in plain language, with a link to the change that implemented it. Here, that’s the Cloud Armor rule that denies requests carrying a Brotli Content-Encoding, plus the plan to rebuild the images once the fix is available.
Once it’s approved, the finding updates immediately. Depending on what the attestation claims, it can change the PAIN score, internet reachability (IRV), and likelihood of exploitability (LEV) where those apply. It also gives us a running record of our posture: anyone can look at a finding and see what has been done, by whom, and when.
On a KEV finding like this one, none of that changes the deadline (see above), so the scoring effect doesn’t matter much here. It’s still worth doing. The finding now shows, in our vulnerability tracking system, that the mitigation was applied and officially recorded, and it stays open until the patch ships.
Then the vendor delivered
On November 5, we got the patch applied: five days ahead of our November 10 KEV deadline, and seven days ahead of the November 12 date the vendor had first given us. We took the WAF rule back out, as we’d told our agency customers we would, and closed the finding.
It would be easy to read that as proof that waiting would have been fine. It wouldn’t have. The day we found this, the date we had missed the deadline, and nothing guaranteed it would move. The WAF rule protected us from the first day, so the patch arrived as a bonus instead of a dependency.
What we’d point to is the pairing. The mitigation bought safety immediately, and the same facts we used internally (a KEV listing, wide prevalence in the vendor’s own images, internet-exposed workloads) were the case we took to the vendor. Both were in motion at once.
The takeaway
Four things changed in how we think about this:
- The clock comes from exploitation, not severity. KEV, EPSS and reachability decide urgency. A “medium” that’s actively exploited and exposed beats a “critical” that isn’t.
- “Can we patch in time?” is no longer the gating question. If you can’t, you still owe an immediate risk reduction: a WAF rule, a config change, network isolation, whatever fits.
- Speed of assessment is a capability. Knowing in minutes where a component lives and what’s exposed is what makes the first two points possible.
- Mitigate now, and work the vendor in parallel. Bring them the facts you use internally: a KEV listing, how common it is in their images, how exposed it is. Neither replaces the other.
We’re already seeing returns from the system we’ve been building, and this was one of the first real tests. It won’t be the last.
Take the Next Step in Your FedRAMP Journey
Understanding vulnerability response is just one part of building a successful FedRAMP strategy. From choosing the right authorization path to navigating compliance requirements and maintaining continuous readiness, having the right game plan makes all the difference.
Download stackArmor’s FedRAMP Playbook for practical insights and actionable strategies to help your organization navigate the road to authorization with confidence.