Tom Hundley
For three decades, the scarce resource in software security was the human who could find the bug. That assumption is now breaking. Anthropic's Frontier Red Team has reported that its unreleased Claude Mythos model, run autonomously, found a vulnerability in one case for under $50 and produced exploits — in hours — that expert penetration testers said would have taken them weeks. The discovery side of security is being industrialized.
The number that should reorganize your roadmap is a different one. Anthropic reports that fewer than 1% of the potential vulnerabilities it has discovered so far have been fully patched by their maintainers. Its own framing is blunt: the constraint has moved. Finding is no longer the bottleneck — human capacity to triage, report, and deploy patches is. And Anthropic forecasts that within 6 to 12 months, many other AI companies will field models of comparable capability. Assume attackers get tools like this too, and plan as if the bug firehose is already pointed at you.
Here is the honest part: almost nothing in this playbook is new. SBOMs, fast patch cadences, exploitability-based prioritization, behavioral detection — these have been best practice for years. What changed is the cost of neglecting them. A slow remediation pipeline used to be a quiet liability you could carry; when discovery becomes cheap and fast for adversaries too, that same slowness becomes the gap an attacker walks through. This is a playbook of discipline, ordered by what will hurt first. Work the tiers in order.
If finding is solved and fixing is not, then your remediation pipeline is the single highest-leverage thing you own. Start here, before any new scanning tool.
1. Measure mean-time-to-remediate (MTTR), and make it a tracked, reported metric. You cannot improve what you do not instrument. Measure the wall-clock time from a vulnerability being known to you to it being deployed in production, segmented by severity. If you do not know your current MTTR for critical issues, that is your first action item this week. Set explicit targets — for example, critical/actively-exploited within days, not the 30-to-90-day windows many teams quietly tolerate.
2. Automate the patch-to-PR path. The moment a fixed version of a dependency exists, a pull request raising it should open automatically. Dependabot (GitHub-native) and Renovate (cross-platform, highly configurable) do exactly this and have for years. Adopt one across every repository, not just your flagship services. The goal is that the default state of a known-fixable vulnerability is "a PR is already open," not "someone needs to notice."
3. Make those PRs mergeable without a heroics meeting. An automated PR that sits for three weeks because nobody trusts the test suite is theater. Invest in the CI that lets a dependency bump merge on green: good test coverage, fast pipelines, and auto-merge for low-risk patch-level bumps. The bottleneck is rarely writing the fix — it is the confidence to ship it.
4. Build a staged rollout you actually trust. Speed without a safety net produces outages, and an outage caused by a rushed patch teaches your organization to patch slowly — exactly the wrong lesson. Canary deployments, progressive rollout, and fast automated rollback let you move quickly because you can reverse a bad change in minutes. Staged rollout is what makes "patch fast" survivable.
5. Document and rehearse an emergency-patch path. Your normal cadence is for normal weeks. You also need a separate, pre-authorized lane for "this is being exploited right now": who can approve an out-of-band deploy, how change control is short-circuited, how you communicate it. Write it down before you need it. The first time you exercise this path should not be during the incident.
You cannot patch what you do not know you run. Industrial-scale discovery will find the forgotten library on the forgotten service. Inventory is no longer hygiene; it is the map an attacker is already building of you.
6. Generate and maintain SBOMs. A Software Bill of Materials is a machine-readable inventory of every component in a build. Adopt a standard format — CycloneDX or SPDX — and generate an SBOM on every build, for every deployable artifact. When the next foundational-library disclosure lands, "are we affected, and where?" should be a query, not a week of archaeology.
7. Build a real dependency inventory, transitive included. Most of your risk lives in dependencies you never chose directly — the libraries your libraries pull in. Your inventory must capture the full transitive graph. The widely felt incidents of the last several years landed through exactly this layer.
8. Hunt your EOL and unmaintained components. End-of-life and abandoned dependencies are where cheap, automated discovery pays the highest dividend for an attacker: no upstream fix is coming, so a found bug stays exploitable. Flag every component past end-of-life, with no release in years, or with a bus-factor of one. For each, decide deliberately — upgrade, replace, vendor-and-maintain, or isolate. Do not let "it still works" be the decision.
9. Map the long tail of foundational libraries. The bugs Anthropic highlighted were in decades-old, battle-tested code — the foundational software everything quietly depends on. Identify the load-bearing, low-glamour libraries in your stack (parsers, codecs, crypto, network protocol handlers) and give them disproportionate attention. They are where this class of discovery aims.
When the volume of valid findings jumps by an order of magnitude, a flat severity score becomes noise. A CVSS 9.8 in a library you load but never reach, on a host with no internet path, is not your emergency. Triage by exploitability, and you turn an unmanageable firehose into a ranked queue.
10. Lead with actively-exploited signals — CISA KEV. CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with confirmed in-the-wild exploitation. Anything in your environment that matches KEV jumps the queue, regardless of its base score. "Actively exploited" beats "theoretically severe" every time.
11. Use EPSS to rank the rest. The Exploit Prediction Scoring System (EPSS) estimates the probability a given vulnerability will be exploited in the near term. Where KEV tells you what is being exploited now, EPSS helps you rank the long tail by likelihood rather than by CVSS severity alone. Use them together: KEV first, then EPSS-weighted, then base severity as a tiebreaker.
12. Apply reachability analysis. A vulnerable function that no code path in your application actually calls is a far lower priority than one on a hot path. Modern SCA tooling can perform reachability (call-graph) analysis to tell you whether the vulnerable code is even invoked. This single filter routinely removes the majority of "critical" findings from the urgent pile — and lets you spend human attention on the ones that matter.
13. Filter by internet exposure and blast radius. An internet-facing, unauthenticated service weighs more than the same flaw on an internal host behind authentication and segmentation. Combine exposure (reachable from the internet?), authentication (does exploitation require credentials?), and blast radius (what does a compromise reach?) into your ranking. Exploitability is the product of these factors, not the CVSS number in isolation.
If discovery and exploitation both accelerate, your detection window collapses with them. The time from public disclosure to working exploit has been shrinking for years; assume the gap is now hours, not weeks. Detection that depends on a known signature for a known CVE will always be a step behind a machine that writes a novel exploit before lunch.
14. Assume the disclosure-to-exploit window is hours. Operationally, this means your patch SLAs (Tier 1) and your detection posture must both be sized for a same-day threat. The grace period in which "it's disclosed but no exploit exists yet" used to be your buffer. Plan as though that buffer is gone.
15. Invest in behavioral and anomaly detection, not just signatures. Signature-based detection catches the exploit you already have a rule for. Behavioral detection catches the consequence — the unexpected outbound connection, the process spawning a shell it never spawns, the lateral movement, the privilege escalation, the data egress. When the specific vulnerability is novel, the post-exploitation behavior is often still recognizable. That is where AI-speed exploitation is most detectable.
16. Tighten telemetry and shorten detection MTTR. Comprehensive logging from endpoints, network, identity, and cloud control planes — centralized and actually queried — is the substrate everything else runs on. Measure mean-time-to-detect alongside MTTR and drive both down: a fast remediation pipeline is wasted if you learn about the compromise weeks late.
The firehose is as much an organizational problem as a technical one. Tooling without the relationships and rehearsed processes to act on it just grows a backlog you cannot clear.
17. Build maintainer and vendor relationships before you need them. When you find — or are told about — a serious bug in an upstream dependency, your speed-to-fix depends on a working channel to the people who maintain it. Know how to reach your critical vendors' security teams. For the open-source libraries you depend on, having a relationship (and, where you can, contributing back) is the difference between a fix in days and a fix that never comes — open-source maintainers, in Anthropic's Glasswing framing, have historically been left to figure out security on their own, and our read is that industrial-scale discovery turns that thin safety margin into thousands of newly found flaws landing on the desks of often under-resourced maintainers.
18. Get your disclosure window ready in both directions. Coordinated disclosure runs on a clock — Anthropic describes a 90-plus-45-day window before a vulnerability's details become public. You are on both ends of that clock: as a consumer, you may get advance notice and must be able to act inside the window; as a producer of software, you need a published security contact, an intake process, and a standard for handling reports you receive. A security.txt file and a monitored security inbox are the minimum.
19. Tabletop the firehose. Run the exercise explicitly: "Tomorrow we receive 500 valid, high-severity findings against our stack. Walk through what happens." You will discover where the pipeline jams — triage capacity, deploy approvals, test coverage, the emergency lane — in a conference room instead of during a breach. Rehearse the volume scenario, not just the single-incident one, because volume is the new shape of the problem.
If you do only three things this week: measure your MTTR for critical issues so you know your true starting line; turn on automated dependency PRs across every repository; and check your environment against the CISA KEV catalog, patching any matches immediately. Small, concrete, and they buy down the risk that hurts first.
None of this is exotic — it is the security discipline most teams already know they should have. The shift Anthropic describes does not change what good security looks like; it changes how expensive it is to keep deferring it. The teams that come through the transition well will be the ones that treated remediation throughput, not vulnerability discovery, as the thing worth getting fast at.
Is industrial-scale vulnerability discovery actually here, or is this hype? The capability is demonstrated, not hypothetical. Anthropic's Frontier Red Team reported autonomous discovery of real vulnerabilities in decades-old software, including a 17-year-old FreeBSD flaw it exploited end-to-end. On the cost side, the headline "under $50" figure is the cost of a single winning discovery run (the OpenBSD TCP SACK bug), and Anthropic cautions that it only makes sense with full hindsight — the real cost across roughly 1,000 runs was about $20,000, and the more complex end-to-end exploit ran closer to ~$1,000 over about half a day. The model behind it is not publicly released, but Anthropic forecasts comparable capability across the industry within 6 to 12 months. The prudent planning assumption is that attackers will have tools of this class soon, even if they do not yet.
Why fix remediation before buying more scanning tools? Because finding is no longer your constraint. Anthropic reports that fewer than 1% of the vulnerabilities it has discovered so far have been fully patched, and frames the bottleneck as human capacity to triage, report, and deploy fixes. Adding more discovery to a slow pipeline just lengthens a backlog you already cannot clear. Fix the throughput first, then turn up the volume of findings.
Should we stop using CVSS? No — use it as one input, not the verdict. CVSS describes intrinsic severity but says nothing about whether a vulnerability is reachable in your code, exposed to the internet, or being exploited right now. Layer CISA KEV (actively exploited), EPSS (exploit likelihood), reachability analysis, and exposure on top of the base score. The goal is a ranking by real-world exploitability, with CVSS as the tiebreaker.
How fast do we really need to patch? Fast enough to assume the window from public disclosure to a working exploit is hours, not weeks — and shrinking. That does not mean every patch ships in an hour; it means your critical and actively-exploited path must, and you need a documented emergency-patch lane plus staged rollout so that speed does not cause outages. Set severity-tiered SLAs and measure yourself against them.
We are a small team without a security org. What is the minimum? Three things move the needle most for the least effort: turn on automated dependency update PRs (Dependabot or Renovate) across all repositories; generate an SBOM per build so you can answer "are we affected?" in minutes; and monitor the CISA KEV catalog so the genuinely urgent items surface above the noise. These are mostly configuration, not headcount.
What does this mean for the open-source libraries we depend on? It raises both the risk and your responsibility. The same discovery tools that find bugs in foundational libraries hand thousands of newly disclosed flaws to maintainers who, in our assessment, are often under-resourced — Anthropic's Glasswing framing notes that open-source maintainers have historically been left to figure out security on their own. Inventory which foundational libraries you actually depend on, prioritize the unmaintained and end-of-life ones, and where you can, contribute back — funding, fixes, or maintainer time. Your supply chain is only as patched as the upstream that feeds it.
Discover more content:
