When AI Finds Your OSS Vulnerability First: Coordinating AI-Discovered Disclosures

The Problem

The traditional vulnerability disclosure timeline is built around human researchers working at human speed. A researcher finds a bug, reports it to the maintainer, the maintainer has ninety days to develop a fix before the researcher publishes, a CVE is assigned, the patch is released, and downstream organisations have weeks or months to apply it before active exploitation typically begins. This model is already under stress from the professionalization of bug bounty programmes and organised exploit broker markets. AI-assisted vulnerability discovery breaks it entirely.

In October 2024, Google’s Project Zero published the first publicly confirmed case of an AI system — their Project Big Sleep LLM agent — independently discovering a previously unknown stack buffer underflow vulnerability in SQLite (CVE-2024-12345-analogue) before any human researcher had identified it. The AI system was specifically guided to look at patterns that matched historical vulnerability classes in similar codebases and found a real, exploitable memory corruption bug. The disclosure went through standard coordinated channels, a patch was issued, and the world did not end.

What the SQLite case established as precedent: AI systems are now capable agents in the vulnerability discovery ecosystem, not merely tools wielded by human researchers. Google’s Big Sleep, Microsoft’s AI-augmented fuzzing infrastructure, and research systems from academic groups are running continuously against high-value OSS targets including curl, OpenSSL, the Linux kernel, glibc, and widely-deployed language runtimes. The rate of discovery will increase, not decrease, as these systems improve.

For defenders, the disclosure dynamics change in several ways that the traditional CVE workflow does not handle well. First, AI systems can generate functioning proof-of-concept exploit code alongside the bug report, compressing the time between “vulnerability known to the discoverer” and “weaponised exploit available.” In the traditional flow, converting a vulnerability report into a working exploit takes weeks for a skilled researcher; the AI that found the bug may already have the PoC. Second, AI discoverers may run the same analysis continuously against the same targets, meaning that if your organisation’s AI-augmented security programme and an attacker’s AI system are both targeting the same library, the race condition between patch availability and exploitation is tighter than it has ever been. Third, OSS maintainers who are already under capacity pressure now receive complex, AI-generated bug reports with detailed technical analysis that they must evaluate and respond to, sometimes without the background to rapidly understand what the AI found.

This is distinct from the AI-generated exploit problem (using AI to weaponise known CVEs). The threat discussed here is AI discovering genuinely new zero-days — and what your organisation needs to do when one of those zero-days affects a library you depend on.

Threat Model

Patch gap during AI-sourced disclosure window. An AI system discovers a critical vulnerability in a library your organisation uses — for example, a memory corruption bug in libcurl or an authentication bypass in OpenSSL. The AI discoverer initiates coordinated disclosure with a 90-day window. The maintainer issues a patch on day 60. Your organisation’s standard patch SLA is 30 days for critical vulnerabilities. The patch was disclosed publicly on day 60 with a detailed write-up and, in an AI-sourced disclosure, potentially an AI-generated PoC. Active exploitation begins on day 65 from organisations running automated exploit delivery against the CVE. Your patch is applied on day 90. You were exposed for 25 days after a working exploit was publicly available.

Parallel independent discovery by an attacker. The same AI techniques that Google’s Big Sleep uses are available, in less refined form, to well-resourced attackers. A state-sponsored attacker running their own LLM-guided vulnerability discovery programme independently discovers the same vulnerability in the same library. There is no coordinated disclosure; the attacker simply begins exploiting the vulnerability while the legitimate discoverer is still in their 90-day window. Your organisation has no indication that a zero-day in this library is being actively exploited because no CVE has been assigned yet. This is the nightmare scenario: the coordinated disclosure timeline assumes a single discoverer in good faith; parallel AI discovery eliminates that assumption.

Maintainer capacity overwhelm delays patch. A small OSS project — three maintainers, volunteer work — receives an AI-generated vulnerability report describing a complex memory safety issue with a detailed technical analysis. The maintainers do not have the background to rapidly evaluate the report. The AI’s technical explanation is accurate but written at a level that assumes deep familiarity with the code’s internal invariants. The maintainers request clarification. The disclosure clock continues. The patch is delayed. The vulnerability window extends because the discoverer’s report, while correct, was not structured for the maintainers’ context.

Hardening Configuration

Subscribing to AI-Sourced Disclosure Channels

The first step is ensuring your organisation has visibility into AI-sourced disclosures as early as possible. This means subscribing to the channels where these disclosures appear before or alongside public CVE assignment:

# oss-security mailing list — primary channel for coordinated OSS disclosures
# Subscribe at: https://oss-security.openwall.org/wiki/mailing-lists/oss-security
# Many AI-sourced disclosures from Google and Microsoft appear here first

# GitHub Advisory Database with RSS (includes AI-discovered vulns tagged by source)
curl -s "https://api.github.com/advisories?ecosystem=pip&per_page=100" \
  | jq '[.[] | {ghsa_id, summary, severity, published_at, cve_id}]'

# OSV (Open Source Vulnerability) database — comprehensive, machine-readable
# Fetch all vulnerabilities affecting a specific package ecosystem
curl -X POST "https://api.osv.dev/v1/query" \
  -H "Content-Type: application/json" \
  -d '{"package": {"name": "curl", "ecosystem": "OSS-Fuzz"}}' \
  | jq '.vulns[] | {id, published, summary}'

# CERT/CC Vulnerability Note Database
# Subscribe to email alerts at: https://www.kb.cert.org/vuls/subscribing/

# Google OSS-Fuzz — findings from continuous AI-augmented fuzzing
# Your OSS project can enrol at: https://github.com/google/oss-fuzz
# Private disclosure notifications available for enrolled projects' dependents

Configure an automated feed aggregator that monitors multiple sources and normalises into a common schema:

#!/usr/bin/env python3
"""
disclosure_monitor.py — Monitor AI-sourced vulnerability disclosure channels.

Polls OSV, GitHub Advisories, and NVD for new disclosures, flags those
originating from automated/AI discovery systems, and triggers SBOM-based
impact assessment for your dependency inventory.
"""

import json
import time
import sqlite3
import hashlib
import requests
import anthropic
from datetime import datetime, timedelta, timezone
from pathlib import Path

GITHUB_TOKEN = ""  # Set via environment variable in production
OSV_API = "https://api.osv.dev/v1"
GITHUB_ADVISORY_API = "https://api.github.com/advisories"
NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"

# Known AI discovery programme identifiers in CVE descriptions and advisories
AI_DISCOVERY_MARKERS = [
    "big sleep", "project big sleep", "oss-fuzz", "ai-assisted",
    "llm-guided", "automated fuzzing", "ai fuzzing", "machine learning",
    "google deepmind", "msrc ai", "copilot autofix",
]


def is_ai_sourced(description: str, references: list[str]) -> bool:
    """Heuristically identify AI-sourced vulnerability disclosures."""
    text = (description + " ".join(references)).lower()
    return any(marker in text for marker in AI_DISCOVERY_MARKERS)


def fetch_osv_recent(ecosystem: str = None, days: int = 7) -> list[dict]:
    """Fetch recent OSV entries for a given ecosystem."""
    cutoff = (datetime.now(timezone.utc) - timedelta(days=days)).isoformat()
    payload = {"modified_since": cutoff}
    if ecosystem:
        payload["package"] = {"ecosystem": ecosystem}

    resp = requests.post(f"{OSV_API}/query", json=payload, timeout=30)
    resp.raise_for_status()
    return resp.json().get("vulns", [])


def fetch_github_advisories(ecosystem: str = "pip", days: int = 7) -> list[dict]:
    """Fetch recent GitHub Security Advisories."""
    cutoff = (datetime.now(timezone.utc) - timedelta(days=days)).strftime(
        "%Y-%m-%dT%H:%M:%SZ"
    )
    headers = {
        "Accept": "application/vnd.github+json",
        "X-GitHub-Api-Version": "2022-11-28",
    }
    if GITHUB_TOKEN:
        headers["Authorization"] = f"Bearer {GITHUB_TOKEN}"

    params = {"ecosystem": ecosystem, "published": f">{cutoff}", "per_page": 100}
    resp = requests.get(GITHUB_ADVISORY_API, headers=headers, params=params, timeout=30)
    resp.raise_for_status()
    return resp.json()


def load_sbom_packages(sbom_path: str) -> dict[str, set[str]]:
    """
    Load an SPDX-format SBOM and return a mapping of
    {normalised_package_name -> {version, ...}}.
    """
    sbom = json.loads(Path(sbom_path).read_text())
    packages: dict[str, set[str]] = {}
    for pkg in sbom.get("packages", []):
        name = pkg.get("name", "").lower()
        version = pkg.get("versionInfo", "")
        if name:
            packages.setdefault(name, set()).add(version)
    return packages


def check_sbom_impact(vuln: dict, sbom_packages: dict[str, set[str]]) -> list[dict]:
    """
    Cross-reference a vulnerability against the SBOM to identify
    all affected package instances in your inventory.
    """
    affected = []
    for affected_pkg in vuln.get("affected", []):
        pkg_name = affected_pkg.get("package", {}).get("name", "").lower()
        if pkg_name in sbom_packages:
            installed_versions = sbom_packages[pkg_name]
            affected_ranges = affected_pkg.get("ranges", [])
            # Simplified: flag all installed versions for manual check
            # Production: implement proper semver range evaluation
            affected.append({
                "package": pkg_name,
                "installed_versions": list(installed_versions),
                "vuln_id": vuln.get("id", ""),
                "severity": vuln.get("severity", [{}])[0].get("score", "unknown"),
            })
    return affected


def store_disclosure(conn: sqlite3.Connection, vuln_id: str, data: dict,
                     ai_sourced: bool, impact: list[dict]):
    """Store disclosure and impact assessment in local SQLite database."""
    conn.execute("""
        INSERT OR REPLACE INTO disclosures
        (vuln_id, data_json, ai_sourced, impact_json, first_seen, last_updated)
        VALUES (?, ?, ?, ?, ?, ?)
    """, (
        vuln_id,
        json.dumps(data),
        int(ai_sourced),
        json.dumps(impact),
        datetime.now(timezone.utc).isoformat(),
        datetime.now(timezone.utc).isoformat(),
    ))
    conn.commit()


def init_db(db_path: str = "disclosures.db") -> sqlite3.Connection:
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS disclosures (
            vuln_id TEXT PRIMARY KEY,
            data_json TEXT,
            ai_sourced INTEGER DEFAULT 0,
            impact_json TEXT,
            first_seen TEXT,
            last_updated TEXT
        )
    """)
    conn.commit()
    return conn

Accelerated Patching Workflow for AI-Sourced Disclosures

When a disclosure is identified as AI-sourced, trigger an accelerated response workflow. The standard 30-day critical patch SLA is too slow when AI-generated PoC code is bundled with the disclosure:

import os
import subprocess
from github import Github

# SLAs in hours
PATCH_SLAS = {
    "standard": {
        "CRITICAL": 720,   # 30 days
        "HIGH": 2160,      # 90 days
    },
    "ai_sourced": {
        "CRITICAL": 72,    # 3 days — PoC likely available at disclosure
        "HIGH": 168,       # 7 days
    },
}


def compute_patch_deadline(severity: str, ai_sourced: bool,
                           disclosure_time: datetime) -> datetime:
    """Calculate the patch deadline based on disclosure type and severity."""
    sla_map = PATCH_SLAS["ai_sourced"] if ai_sourced else PATCH_SLAS["standard"]
    hours = sla_map.get(severity.upper(), 2160)
    return disclosure_time + timedelta(hours=hours)


def create_accelerated_patch_ticket(impact: list[dict], vuln_id: str,
                                    severity: str, ai_sourced: bool,
                                    disclosure_time: datetime):
    """Create a high-urgency GitHub issue with patch deadline for AI-sourced vulns."""
    gh = Github(os.environ["GITHUB_TOKEN"])
    repo = gh.get_repo(os.environ["GITHUB_REPO"])

    deadline = compute_patch_deadline(severity, ai_sourced, disclosure_time)
    sla_label = "ai-sourced-disclosure" if ai_sourced else "standard-disclosure"

    for item in impact:
        title = (
            f"[{'AI-SOURCED ' if ai_sourced else ''}CRITICAL] "
            f"{vuln_id} in {item['package']} — "
            f"patch by {deadline.strftime('%Y-%m-%d %H:%M UTC')}"
        )
        body = f"""## Accelerated Patch Required

**Vulnerability:** {vuln_id}
**Affected package:** `{item['package']}`
**Installed versions in inventory:** {', '.join(item['installed_versions'])}
**Severity:** {severity}
**AI-sourced disclosure:** {'YES — PoC code may already be public' if ai_sourced else 'No'}
**Disclosure time:** {disclosure_time.strftime('%Y-%m-%d %H:%M UTC')}
**Patch deadline:** {deadline.strftime('%Y-%m-%d %H:%M UTC')}

## Why the Accelerated SLA

AI-sourced vulnerability disclosures frequently include functional proof-of-concept
exploit code generated by the same AI system that discovered the vulnerability.
Exploitation timeline after AI-sourced disclosure is typically days, not weeks.
Standard 30-day patch SLA is not appropriate.

## Immediate Actions

- [ ] Identify all services using `{item['package']}` from SBOM inventory
- [ ] Apply virtual patch (WAF rule) if exploit PoC is public — see below
- [ ] Prioritise package update in current sprint
- [ ] Verify patch in staging within 24h of availability
- [ ] Deploy to production within deadline

## Virtual Patch (WAF Interim Mitigation)

While the patch is being applied, consider whether the vulnerability is exploitable
via an HTTP attack vector that can be blocked at the WAF layer. See virtual patching
runbook: [link to runbook].
"""
        repo.create_issue(
            title=title,
            body=body,
            labels=["security:critical", sla_label, "patch-required"],
        )

Virtual Patching with WAF Rules as Interim Mitigation

For vulnerabilities with network-accessible attack vectors, deploy WAF rules while the patch is being applied. This script generates a ModSecurity rule template from a CVE description:

VIRTUAL_PATCH_PROMPT = """You are a WAF security engineer. Given the following CVE description,
generate a ModSecurity 3.x compatible virtual patch rule that blocks the most likely exploitation
vectors at the HTTP layer.

CVE: {cve_id}
Description: {description}
Affected component: {package}

Requirements:
1. Only block requests matching specific exploitation patterns, not all traffic
2. Include a comment explaining what the rule blocks
3. Use ModSecurity syntax (SecRule directives)
4. If the vulnerability is not exploitable via HTTP, state this explicitly

Output only the ModSecurity rule(s) and a brief comment, no prose."""


def generate_virtual_patch(cve_id: str, description: str,
                            package: str) -> str:
    """Generate a WAF virtual patch rule using LLM analysis."""
    client = anthropic.Anthropic()
    message = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=512,
        messages=[{
            "role": "user",
            "content": VIRTUAL_PATCH_PROMPT.format(
                cve_id=cve_id,
                description=description[:1000],
                package=package,
            ),
        }],
    )
    return message.content[0].text


def write_waf_rule_file(cve_id: str, rule_content: str,
                        output_dir: str = "/etc/modsecurity/virtual-patches"):
    """Write the generated rule to the WAF rules directory."""
    safe_id = cve_id.replace("-", "_").lower()
    rule_path = Path(output_dir) / f"vp_{safe_id}.conf"
    rule_path.write_text(f"# Virtual patch for {cve_id}\n# Auto-generated — review before deployment\n\n{rule_content}\n")
    print(f"Virtual patch written to {rule_path}")
    # Test rule syntax before deploying
    result = subprocess.run(
        ["nginx", "-t", "-c", "/etc/nginx/nginx.conf"],
        capture_output=True, text=True
    )
    if result.returncode != 0:
        print(f"WAF config test failed: {result.stderr}")
        rule_path.unlink()  # Remove invalid rule
        raise ValueError(f"Generated WAF rule failed syntax check: {result.stderr}")

Registering with AI Vulnerability Discovery Programmes

Enrol your OSS dependencies with OSS-Fuzz to receive early notifications when the fuzzer finds a bug in a project you depend on:

# Check if a project you depend on is enrolled in OSS-Fuzz
# (enrolled projects receive private disclosure notifications to listed contacts)
curl -s "https://api.github.com/repos/google/oss-fuzz/contents/projects" \
  | jq -r '.[].name' | grep -i "your-dependency-name"

# If you maintain an OSS project, enrol it in OSS-Fuzz by opening a PR:
# https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md

# GitHub's Copilot Autofix and secret scanning notification registration:
# Configure security advisories for your repositories
gh api repos/{owner}/{repo} --method PATCH \
  -f security_and_analysis='{"dependabot_security_updates":{"status":"enabled"}}'

# Subscribe to Dependabot security update notifications via GitHub Notifications API
gh api user/notification_threads \
  --jq '.[] | select(.reason == "security_advisory") | {id, subject}'

SBOM-Based Impact Assessment Automation

Integrate impact assessment into a GitHub Actions workflow that triggers on new CVE publications:

# .github/workflows/cve-impact-assessment.yml
name: CVE Impact Assessment

on:
  schedule:
    - cron: '0 */4 * * *'  # Every 4 hours
  workflow_dispatch:
    inputs:
      cve_id:
        description: 'Specific CVE to assess (optional)'
        required: false

jobs:
  assess-impact:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: current-sbom.spdx.json

      - name: Run impact assessment
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python scripts/disclosure_monitor.py \
            --sbom current-sbom.spdx.json \
            --days 1 \
            --create-issues \
            --accelerate-ai-sourced

Expected Behaviour After Hardening

With this pipeline operational, your organisation receives automated notification of new disclosures affecting your SBOM inventory within four hours of publication to OSV or the GitHub Advisory Database. AI-sourced disclosures are automatically flagged and routed to an accelerated 72-hour SLA for critical-severity findings, rather than the standard 30-day window.

Virtual patch rules are generated and staged for review within minutes of identifying a network-exploitable vulnerability with a public PoC. Security engineers review and deploy the WAF rule as an interim measure while the full patch is processed through the standard change pipeline.

SBOM-based impact assessment runs automatically, so the question “which of our services use this package?” has an answer within minutes rather than requiring a manual inventory search across dozens of repositories.

The false assumption that AI-sourced disclosures are rare events that can be handled by the existing process disappears. With AI discovery programmes running continuously against high-value OSS targets, your organisation will receive AI-sourced disclosures monthly or more frequently as these programmes scale.

Trade-offs and Operational Considerations

Failure Modes

Related Articles

• AI-Assisted Vulnerability Discovery
• AI Code Scanning and Autofix
• Zero-Day Response Playbook
• AI-Assisted Patch Prioritisation
• SBOM and VEX Exploitability