Every development team knows the feeling of opening a vulnerability export on Monday morning and staring at a spreadsheet with 1,000 "CRITICAL" rows. The Product Owner dumps all the findings into the backlog and assigns them to developers for the next sprint.
A backlog is not a security strategy.
Even if you manage to find the twenty vulnerabilities that actually matter, a second problem stops remediation: fear of breaking production. Nobody wants an automated script running blind apt or yum upgrades across live Compute Engine workloads, restarting critical daemons, or triggering unexpected reboots in the middle of the day.
I built PatchAdvisor to solve both halves of that problem. It is an open-source multi-agent system built with Google's Agent Development Kit (ADK) and hosted on the GCP Agent Platform. It cuts through CVE backlog noise by correlating OS Config telemetry with Security Command Center (SCC) v2 attack paths and LLM reasoning, then executes self-verifying patch jobs.
To understand why I designed the agent this way, look at the numbers that broke traditional vulnerability management in the first place.
The Math Problem: Why CVSS Alone Fails
Quarterly CVE volume has tripled. Compared to the same three-month window last year, new CVE disclosures jumped 315%, rising from 12,000 to 37,000 new CVEs in a single quarter.
No engineering team scales its patching capacity by 315% year over year.
When teams try to filter that flood, almost everyone defaults to the CVSS Base Score. The catch is that CVSS Base Metrics only measure intrinsic, constant properties of a flaw: theoretical exploitability and direct impact on Confidentiality, Integrity, and Availability.
Look at the gap between disclosed vulnerabilities and exploited vulnerabilities across NVD and CISA KEV data:
- 72,000 CVEs published
- 850 KEVs (Known Exploited Vulnerabilities) confirmed exploited in the wild
Only 1.17% of new CVEs are actively exploited.
Smart Prioritization: KEV and EPSS Over CVSS
What happens when you replace raw CVSS thresholds with Known Exploited Vulnerabilities (KEV) and the Exploit Prediction Scoring System (EPSS), which scores the probability that a vulnerability will be exploited within 30 days?
Filtering by KEV and EPSS instead of raw CVSS thresholds eliminates 86% of backlog noise while covering 95% of actively attacked CVEs (compared to just 53% coverage when you only patch CVSS 9+).
When you combine that exploitability intelligence with Google Cloud Security Command Center (SCC) v2 attack paths, you move from theoretical risk to concrete exposure. You see which weaponized vulnerabilities sit on reachable VMs with open firewall rules, public IPs, or exposed service account keys.
How I Built PatchAdvisor on ADK and GCP Agent Platform
Cutting a backlog by 86% only helps if engineers can ship the remaining patches safely. I built PatchAdvisor around three layers:
- Ingestion and Smart Scoring: Pulls live Compute Engine inventory (
compute_v1), OS Config vulnerability reports (osconfig_v1), and SCC v2 findings, exploitability intelligence, and attack exposure (securitycenter_v2) to rank risk by operational blast radius. - ADK Multi-Agent Orchestration: Separates read-only investigation, infrastructure remediation, and post-patch health validation into dedicated sub-agents.
- Managed Execution on GCP Agent Platform: Deploys with a single command (
adk deploy agent_engine) to Agent Platform, running server-side as a stateless data-plane runtime with native IAM governance, Memory Bank, and full observability.
Combining ADK Workflow Patterns
A single free-form LLM prompt should never have unchecked control over infrastructure mutations. In ADK, you can combine dynamic tool routing with deterministic workflow loops. Here is the core agent structure from remediation_agent/agent.py:
safe_remediation_pipeline = LoopAgent(
name="safe_remediation_pipeline",
description="Confirmation-gated remediation and verification loop: executes confirmed canary or production OS patching, firewall containment, VM metadata hardening, SCC finding mutes, or snapshot rollbacks, then verifies runtime and log health.",
sub_agents=[remediator_agent, validator_agent],
max_iterations=2,
)
root_agent = Agent(
name="remediation_agent",
description="Root orchestrator for read-only vulnerability/SCC triage and confirmation-gated remediation.",
model=MODEL,
instruction=ROOT_AGENT_INSTR,
tools=[preload_memory],
sub_agents=[investigator_agent, safe_remediation_pipeline],
)
Each agent pattern in ADK handles a distinct job:
- Multi-Tool Agent (
investigator_agent): Uses dynamic routing to select and execute read-only GCP tools based on the user's query. It correlates OS Config CVEs with SCC v2 issues, then classifies everything into three operational blast-radius tiers:- Tier 1: Low-risk user-space libraries.
- Tier 2: Packages that restart active daemons or network services.
- Tier 3: Kernel and core system updates that require a host reboot.
- Sequential and Loop Workflow Agents (
safe_remediation_pipeline): While ADK'sSequentialAgentruns sub-agents in a strict linear order sharingInvocationContext, safe patching demands an iterative verification cycle. Wrappingremediator_agentandvalidator_agentinside aLoopAgent(max_iterations=2) creates a bounded, self-healing remediation pipeline.
Canary-First Execution and Self-Healing Rollbacks
When you choose Patch Tier 1 or Patch Tier 2, PatchAdvisor never starts with production.
First, remediator_agent identifies a non-production canary VM running the same OS family from instance labels and tags. Before touching a single package, it calls create_boot_disk_snapshot to snapshot the VM's boot disk. Then it triggers an OS Config patch job with reboot_policy=NEVER (production reboots sit behind a separate Approve Prod Reboot confirmation gate).
As soon as the patch job finishes, the LoopAgent passes control to validator_agent. The validator checks the VM's serial port console output and queries Cloud Logging (logging_v2) for systemd errors or daemon crashes. If the canary stays healthy, you get a 1-click button to promote those verified packages to production; if a service breaks, the pipeline automatically swaps the VM back to the pre-patch boot disk snapshot and logs the failure in Memory Bank.
From 1,000 Issues to a Single Prompt
Instead of dragging 1,000 raw CVE tickets into the next sprint, your team tags @PatchAdvisor in Slack, sees the handful of findings that sit on real attack paths, and patches them with a built-in canary safety net.
The full source code, ADK agent implementation, and deployment instructions for ADK and Cloud Run (for the Slack Gateway) are available on GitHub:
Member discussion