Vulnerability remediation breaks down at codebase scale: AI code without context, detection coverage gaps, and fixes that take weeks across 10,000 repos.
On June 10, CISA issued Binding Operational Directive 26-04, and it should make every VP of Engineering uncomfortable. Starting December 7, federal agencies will have as little as 3 days to remediate vulnerabilities in the highest-risk class of flaws. Not three days to file the ticket. Three days to fix, verify, and run forensic triage. Most enterprise security programs can't meet that clock at codebase scale today. Not because the tools are bad, but because remediation breaks down in three specific places once you operate across thousands of repositories. Each one looks like a separate problem. Each one gets a separate budget line. And none of your current tools covers the gaps between them.
Key takeaways
CISA's reasoning names the problem out loud: threat actors' "use of AI may further narrow the time defenders have to react between patch release and possible exploitation." The remediation timelines in the directive follow from that premise. A vulnerability that is publicly exposed, listed in the Known Exploited Vulnerabilities catalog, automatable, and high-impact gets three days. Lower-risk combinations get 14 or 60. The directive replaces the older, flatter rules of BOD 19-02 and BOD 22-01 with a risk-based vulnerability management model.
The directive binds federal agencies, not your company. But the operating assumption behind it applies to everyone: the gap between patch release and exploitation is collapsing, so remediation speed is now a primary security metric, not a hygiene afterthought. The codebase you'd have to remediate, meanwhile, is growing faster than ever. Those two curves, shrinking windows and expanding code, are what make the following three breakdowns urgent rather than theoretical.
AI coding agents write code that fails security review at high rates, and they write a lot of it. Veracode tested more than 100 large language models and found 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Volume makes it worse: Apiiro's Fortune 50 research found AI-assisted developers made 3 to 4 times more commits while their teams shipped 10 times more security findings.
The defect rate isn't the most interesting part. The kind of defect is. Apiiro measured privilege escalation paths up 322% and architectural design flaws up 153% in AI-assisted code. Those aren't typos a linter catches. They're the flaws that come from not knowing how your systems fit together.
That's the context problem. An agent working from one repo fragment doesn't know that your org standardized on a hardened auth middleware in 2024, that the deprecated crypto helper it just copied exists in your codebase precisely because nobody finished removing it, or that the service it's calling assumes a validation layer that lives two repos away. So it generates something plausible. Plausible code that ignores your conventions is how one insecure pattern becomes forty insecure patterns at generation speed.
Your secure-coding guidelines don't cover this, because the agent never reads them. Your code review process doesn't cover it either: the same Apiiro research shows that AI-assisted work arrives in fewer, much larger pull requests, diluting reviewer attention. Prevention that depends on a human noticing is losing to a machine that doesn't sleep.
Here's a question that quietly separates a real security posture from an assumed one: what percentage of the code your organization owns did your scanners actually see last month?
Most teams can't answer it, and the honest answer is usually "the repos someone remembered to wire into CI." That leaves out the archived service still running in production, the repositories that arrived with the last two acquisitions, the internal tools nobody classified as "applications," and every transitive dependency those things pull in. Scanner findings describe the code that was scanned. They say nothing about the code that wasn't, which is exactly where incidents like to start. We made this argument in depth in Detection in One Repo Isn't a Security Posture: a finding in one repo is a fact, not a posture.
The volume math keeps making this worse. The CVE program published 321 records in 1999 and more than 28,900 in 2023, a 460% increase over a decade, per GitHub's analysis. Every disclosure triggers the same question: which of our repos contains this, directly or transitively? If your answer requires checking repos one at a time, your coverage confidence is a feeling, not a number.
For CISOs, this is the gap that matters most, because everything downstream inherits it. Prioritization frameworks like KEV and EPSS can only rank the findings you have. A perfect triage process applied to 60% of your codebase is a 60% security program with great paperwork.
The standard enterprise remediation motion looks like this: security identifies the vulnerable package, files tickets against every team that owns an affected service, and then waits. Each team independently figures out the upgrade, fights its own dependency conflicts, opens its own pull request, and closes its ticket on its own schedule. Verification means re-scanning and hoping the scan coverage matches the exposure (see Breakdown #2).
That motion was tolerable when "everywhere" meant forty repos. At thousands of repos, it produces remediation timelines for a single CVE measured in weeks, with no central view of how many instances remain. The work isn't hard; it's the same fix applied hundreds of times. What doesn't scale is the coordination: ticket-per-team, PR-per-repo, status-by-spreadsheet.
Now put that against the new clock. CISA's directive gives federal agencies three days for the highest-risk class of vulnerability and requires agencies to operate this way by December 7, 2026. Federal mandates have a habit of becoming enterprise expectations: through FedRAMP environments, contract language, board questions, and cyber insurers. When your CEO reads that the U.S. government patches its highest-risk actively exploited vulnerabilities in 72 hours, "we're at week three of the rollout" stops being an acceptable status update.
There's a quieter cost, too. Teams that know remediation takes weeks make rational, bad decisions: they punt on upgrades, pin old versions, and accumulate the exact backlog that turns the next disclosure into a fire drill.
None of this is an argument that your scanners are bad. It's an argument that every tool in the standard stack operates inside a boundary that the risk doesn't respect.
| Tool class | What it's good at | Which breakdown does it miss? |
|---|---|---|
| SAST / SCA scanners | Finding known-pattern flaws in repos they're wired into | #2: coverage limited to onboarded repos; no answer for "did we scan everything we own?" |
| AI coding assistants' built-in checks | Catching syntax-level issues at generation time | #1: no knowledge of org-wide patterns, conventions, or cross-repo architecture |
| ASPM / finding aggregators | Deduplicating and prioritizing scanner output | #2: a unified view of partial coverage is still partial |
| Ticketing and workflow tools | Routing known work to known owners | #3: one ticket per team per repo is the thing that doesn't scale |
| Patch management platforms | Rolling out OS and host-level updates | #3: code-level fixes (dependency upgrades, pattern changes) aren't host patches |
Read the table by column, and each tool earns its budget. Read it by row, and the three breakdowns sit precisely in the seams: before code merges, across the repos nobody scanned, and in the coordination layer between detection and done.
The common denominator across all three breakdowns is the inability to treat your codebase as one queryable, changeable surface. The capability that fixes this is unglamorous: universal code search across every repository you own, paired with the ability to act on what you find, everywhere, at once.
Concretely, that means three things. Complete coverage: every repo, including archived and acquired code, indexed and searchable, so coverage confidence is a query result rather than an assumption. Exact answers: given a CVE, a vulnerable function signature, or a risky pattern, an exhaustive list of every occurrence instead of a sampling. Coordinated change: the fix was generated, applied, and tracked as pull requests across every affected repository from one place, so remediation status is a dashboard, not a spreadsheet.
This is the layer we build at Sourcegraph, and the clearest illustration is public: when CVE-2025-55182 (React2Shell, CVSS 10.0) dropped, we documented hunting the vulnerability across enterprise codebases with a single search, then fixing and tracking it across every affected repository with batch changes rather than a ticket queue. The same index that answers "where is this everywhere?" also gives AI agents the codebase context that Breakdown #1 starves them of, your actual patterns and conventions, instead of plausible guesses.
To be precise about scope: universal code search doesn't replace your SAST, SCA, or secrets scanners. They remain the detection rules. It's the coverage and action layer underneath them, the part of the stack that makes "everywhere" a real word.
Prioritize by reach and exploitability together: how many repositories, services, and teams a vulnerability touches, weighted by whether it's actively exploited (KEV status) and reachable in production. Blast radius turns prioritization from a severity-score debate into a metric, and it requires knowing the exact location of the vulnerability first.
CISA's four risk variables, asset exposure, KEV status, exploit automation, and technical impact, are a sound starting rubric for internal SLAs, too, and CISA's SSVC decision model formalizes the same logic. The difference at codebase scale is the unit of analysis: you're not triaging a finding in a repo, you're triaging a pattern with a footprint.
The three breakdowns are one problem wearing three costumes. AI agents generate insecure code because they can't see the whole codebase. Detection coverage can't be proven because no one can see the entire codebase. Remediation takes weeks because nothing can act on the whole codebase. We've written about what it means in practice to fix the underlying problem in our application security posture explainer. For a deeper, vendor-neutral look at cross-repo security visibility, read The codebase visibility and security framework.
Vulnerability remediation is the process of permanently eliminating identified security flaws by patching, upgrading dependencies, changing code, or removing vulnerable components, and then verifying the fix. It differs from mitigation, which reduces exploitability through compensating controls without removing the underlying flaw.
Remediation removes the root cause: the vulnerable code or component is gone after the fix. Mitigation blocks the exploit path while the flaw remains present, using controls such as WAF rules or network isolation. Mitigation buys time; remediation ends the exposure. Mature programs use both, in that order of preference.
Start with a complete, queryable index of every repository so affected code can be located exhaustively. Generate the fix once, then apply it as tracked pull requests across all affected repos from a single workflow, with central monitoring of merge status. Re-run the original query to verify zero remaining instances.
BOD 26-04, issued June 10, 2026, requires federal agencies to remediate vulnerabilities on risk-based timelines: as quickly as three days (plus forensic triage) for flaws that are publicly exposed, known to be exploited, automatable, and high-impact. Agencies must implement the new processes by December 7, 2026. It supersedes BOD 19-02 and BOD 22-01.
With Sourcegraph, the code understanding platform for enterprise.
Schedule a demo