← Back to Blog

AI Security Patch Triage Agent: Survive the 10,000 CVE Deluge

Anthropic's Project Glasswing found 10,000+ critical vulnerabilities in open-source software in its first month. The bottleneck is no longer finding bugs — it's deciding which ones to patch first. Here's how to build an AI agent that does the triage for you.

Published by GetClawCloud · May 23, 2026

BREAKING Project Glasswing: AI vulnerability discovery hits industrial scale (May 2026): Anthropic's Project Glasswing — a collaborative effort with ~50 partners to secure the world's most critical software — has found more than 10,000 high- or critical-severity vulnerabilities in its first month. Cloudflare alone found 2,000 bugs (400 critical-severity) across their critical-path systems. Mozilla found 271 vulnerabilities in Firefox 150 — over 10x more than they found in the previous version with Claude Opus 4.6. The UK's AI Security Institute reports Mythos Preview is the first model to solve both of their cyber ranges end to end. (Anthropic, Cloudflare, Mozilla)

This is a breakthrough for software security — and a crisis for every team that has to decide what to patch.

For years, security teams struggled with a scarcity problem: there weren't enough vulnerabilities being found to keep up. The average team might see 50–100 new CVEs per week affecting their stack. Painful, but manageable with a good triage process.

Glasswing just inverted that equation. If AI can find 10,000 critical vulnerabilities in a month across a subset of open-source projects, imagine what it finds when scaled to every npm package, every Docker image, every Linux kernel module, every embedded library. The scarcity problem is now an overload problem. Your team doesn't have 10x more engineers to triage 10x more vulnerabilities.

The new bottleneck: Not finding vulnerabilities & — triaging them. The team that wins in the AI era isn't the one that finds the most bugs. It's the one that fastest identifies which bugs actually matter to their specific stack, their specific exposure, their specific risk profile.

Why Manual Patch Triage Is Broken at AI Scale

Traditional patch triage follows a simple process: check CVSS score, check if it affects your version, check if there's active exploitation, schedule the patch. That process assumes a human can personally review each CVE. At 10,000 critical findings per month — and accelerating — that assumption is dead.

Here's what breaks first:

  1. CVSS score becomes meaningless — A critical-severity vulnerability in a library you don't use is irrelevant. A medium-severity bug in your authentication middleware is an emergency. CVSS doesn't know your architecture.
  2. Version matching requires context — Does the vulnerability affect your pinned version? What about transitive dependencies? What if the fix introduces a breaking change that blocks your deployment pipeline?
  3. Business impact is invisible — A vulnerability in an internal admin tool matters less than one in your public-facing API gateway. But your vulnerability scanner doesn't know which is which.
  4. Patch urgency is dynamic — A CVE listed yesterday as "no known exploit" could have a PoC published today. Your weekly patch cycle misses it.

The math doesn't work: If AI finds 10,000 vulnerabilities per month, and your security team reviews 200 per week, you need 12.5 weeks to process a single month's findings. By then, the next 30,000 have arrived. You're not catching up — you're falling behind faster every month.

The Prompt: AI Security Patch Triage Agent

This prompt turns any OpenClaw-powered Telegram bot into an automated patch triage system. It ingests the CVE firehose, filters against your exact stack, assesses real-world exploitability, and produces a prioritized patch schedule — not a firehose of alerts.

You are a Security Patch Triage Agent. Your job is to filter the global vulnerability firehose down to only what matters for the user's stack, and deliver a prioritized action plan — not an endless alert list. ## Workflow ### Phase 1: Inventory the Stack Ask the user for: - **Core stack**: languages, frameworks, runtimes, databases, message queues, CDNs - **Direct dependencies**: specific packages with pinned versions (package.json, requirements.txt, go.mod, Cargo.toml, Gemfile) - **Transitive dependency depth**: do you want alerts for libraries-of-libraries? - **Critical services**: which services are customer-facing? which handle auth, payments, PII? which are internal-only? - **Deployment zones**: production / staging / dev — each may have different patch urgency - **Alert preference**: 🔴 Patch immediately / 🟠 Patch this sprint / 🟡 Patch next sprint / ⚪ Review when convenient - **Recency window**: scan last 24h / 48h / 7d / since last report ### Phase 2: Triage Pipeline For every new or updated CVE / advisory / disclosure, run this pipeline: 1. **Relevance filter** — Does it touch ANY dependency (direct or transitive, per scope) in the user's stack? - Yes → Continue - No → Discard silently 2. **Version check** — Is the user's pinned version in the affected range? - Yes → Continue - No → Check if it's an adjacent range (e.g., user is on 2.0, advisory affects 2.1+) — flag as pre-patch advisory 3. **Exploitability assessment** — Check for: - Active exploitation in the wild (CISA KEV, Google TAG reports, vendor advisories) - Published PoC (exploit-db, GitHub security advisories) - AI-assisted discovery (was this found by an automated scanner or LLM?) - Attack complexity (network-adjacent vs. local vs. authenticated vs. unauthenticated) 4. **Business impact scoring** — Does this affect: - A customer-facing service? (+3 urgency) - Auth, payments, or PII handling? (+3 urgency) - Internal/admin tooling? (+1 urgency) - Dev-only dependency? (+0 urgency) 5. **Patch complexity assessment**: - Is a fix available? (patch release / hotfix / workaround / none) - Does the fix introduce breaking changes? (major version bump, API changes) - Can it be hot-patched (e.g., npm audit fix, go get -u)? 6. **Recommendation generation** — Combine all signals into: - 🔴 **PATCH NOW** — Active exploitation or AI-discovered + affecting critical service + fix available - 🟠 **PATCH THIS SPRINT** — High CVSS + affecting important service + fix available - 🟡 **PATCH NEXT SPRINT** — Low/medium severity + internal service only + fix available - ⚪ **MONITOR** — Adjacent version only / no fix yet / dev-only dependency ### Phase 3: Deliver Triage Report Format as a clean Telegram message: ``` 📋 PATCH TRIAGE — [DATE] 🔴 PATCH NOW • [Pkg] vX.Y → vX.Z — [Brief description] Reason: PoC published + affects production auth service Action: npm update [pkg] 🟠 THIS SPRINT • [Pkg] vA.B → vA.C — [Brief description] Reason: Critical CVSS + customer-facing API 🟡 NEXT SPRINT • [Pkg] vD.E → vD.F — [Brief description] ⚪ MONITORING • [Pkg] — adjacent version only, no PoC yet 📊 Scan summary: [X] of [Y] CVEs affect your stack ``` ### Phase 4: Weekly Deep Dive (optional) On request or weekly schedule, produce: - Trend analysis: vulnerability discovery rate in your ecosystem - Most common vulnerability types affecting your stack - Dependencies approaching end-of-life - Recommended version pinning strategy changes - Emerging threat vectors (new AI-assisted attack patterns, supply chain risks) ## Rules - Never send unfiltered CVE lists. Every output must be triaged. - Always distinguish "confirmed exploit" from "theoretical vulnerability." - Never fabricate CVEs, advisory details, or patch versions. - If nothing affects the user's stack in the scan period, say: "✅ All clear — no new vulnerabilities affecting your stack in the last [period]." - Flag dependencies that are end-of-life or past their security support window. - Cross-reference CVSS with EPSS (Exploit Prediction Scoring System) when available. - If a vulnerability has no fix yet, say so explicitly and suggest mitigations (WAF rules, feature flags, access restriction). ## Start User has provided their technology stack. Begin Phase 1: inventory the stack.

💡 Requires web_search tool access. Works out of the box with any OpenClaw agent on GetClawCloud.

Real-World Triage Scenarios

🔴 Node.js SaaS Platform
"My stack: Node.js 22, Express 4.21, Next.js 15, React 19, Prisma 6, PostgreSQL 16. Production on AWS ECS. Customer-facing API + internal admin panel. Scan daily, alert on anything with active exploitation hitting production services within 4 hours."

🔴 Python Data Pipeline
"Stack: Python 3.12, FastAPI, Celery, Redis 7, PostgreSQL 15, Pandas, NumPy. All internal tools, no customer-facing endpoints. Scan weekly. Flag anything that's actively exploited OR was discovered by an AI scanner."

🔴 Go Microservices on Kubernetes
"Stack: Go 1.23, Gin, gRPC, etcd, Prometheus, Grafana, Kubernetes 1.30, Docker. 12 microservices, 3 customer-facing. Scan daily. Separate alerts by service tier — production gets immediate Telegram, staging gets a daily digest."

🔴 Full-Stack Rails Application
"Stack: Ruby 3.4, Rails 8.0, Sidekiq, Redis 7, MySQL 8.4, TailwindCSS, Hotwire. Also audit all transitive Ruby gems. Scan weekly. Don't alert on dev/test-only gems."

How to Use It

  1. Deploy OpenClaw on GetClawCloud — one-click launch, no server setup, no credit card required
  2. Paste the prompt above into your agent configuration — describe your stack, dependencies, and patch urgency preferences
  3. Send to test — run "Triage the last 48 hours of CVEs for my stack" and review your first prioritized patch plan

Why Glasswing Changes the Patch Triage Game

Before Glasswing, the CVE pipeline was gated by human effort. A security researcher would find a bug, write it up, and eventually it would flow into your vulnerability scanner. The rate was bounded by the number of researchers in the world and their available hours.

Glasswing's Mythos Preview model changed that in two ways:

  1. Volume shock: 10,000+ critical findings in one month from 50 partners means the global CVE rate just jumped by an order of magnitude — and it's accelerating as more organizations join the program.
  2. AI-discovered ≠ AI-exploitable: Not every AI-discovered vulnerability is exploitable in the real world. The false positive rate matters, but even at Cloudflare's "better than human" rate, the raw number of true positives is overwhelming without automated triage.
The strategic insight: In the pre-Glasswing world, patch triage was a weekly meeting. In the Glasswing world, it's a real-time stream. The teams that automate triage will have a 24-hour response time. The teams that don't will have a 12-week backlog.

Automating Your Patch Triage Pipeline

OpenClaw's cron system turns this from a manual scan into an autonomous security operation:

Daily triage scan (8 AM your time):

  1. Create a Cron Job in your OpenClaw dashboard
  2. Schedule: 0 8 * * *
  3. Message: "Triage the last 24 hours of vulnerability disclosures against my stack. Only 🔴 and 🟠 findings. If nothing urgent, say '✅ All clear.'"
  4. Deliver to your Telegram chat

Weekly deep dive (Saturday 10 AM):

  1. Second cron job: 0 10 * * 6
  2. Message: "Run a full weekly patch triage for the last 7 days. Include all severity levels, trend analysis, and any dependencies approaching end-of-life."

Two cron jobs. Zero ongoing effort. Every morning you wake up to a patch plan — not a firehose of alerts.

⚠️ Important caveat: This agent is a triage and prioritization tool. It helps you decide what to patch and in what order. It does not apply patches automatically — always test patches in staging before production deployment. For critical zero-days with active exploitation, follow your incident response process, not a cron job.

Deploy Your Patch Triage Agent

Start on GetClawCloud in 60 seconds. No servers, no DevOps, no credit card required to try.

Deploy on GetClawCloud →

Related Articles

© GetClawCloud