Defense Factory: OpenAI Maps Runtime Evidence to a Verified Patch, But Missing Mitigation

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

‍
OpenAI’s approach to continuous, evidence-based defense aligns closely with Miggo’s runtime-first strategy, with one important piece missing: mitigation.

You know what they say about great power and great responsibility? AI handed both sides more of it. Attackers are moving at machine speed, and the window between a disclosed vulnerability and a deployed patch is where they win. AI-assisted security has to cover that window, following vulnerabilities from discovery through mitigation to remediation.

OpenAI’s newly released Defense Factory is its playbook for putting that into practice. Following Anthropic’s security guidance release earlier this year, OpenAI’s playbook reinforces the same move toward continuous, evidence-based defense. Built from a security sprint that mobilized more than 250 people across hundreds of systems, Defense Factory uses agents across a code-and-repo-centric loop, with findings dynamically reproduced before remediation and fixes verified after deployment.

That emphasis on evidence closely aligns with Miggo’s approach. OpenAI’s inventory provides a statement of intent about what should be deployed, and its dynamic validation establishes exploitability before remediation begins. By sourcing data from the production systems, Miggo already instills these principles and more with a statement of fact, continuously proving what is running and whether vulnerable code is present, reachable, and exploitable. That is the sequence Miggo’s mitigate-first approach is built on: Know what is deployed, Prove what is exploitable, and Shield what cannot be patched yet. The Defense Factory does the first two, but it has no Shield.

How the Defense Factory’s Stages Map to Miggo’s

1. Build an inventory

“Agents reconcile cloud records, deployment configuration, and service ownership data into an asset inventory. They connect exposed endpoints to code and owners, preserving evidence and gaps so discovery starts with a clearer scope.”

Miggo users can skip this one, because they already have it. OpenAI’s inventory says what was declared; Miggo’s says what is a real risk. AppDNA derives inventory directly from running processes and deployed images, building a runtime SBOM that reflects the software actually present in each application instance. For AI applications, that visibility extends to the models and AI components identified through Miggo’s AI Footprint and AI-BOM. Internet exposure is mapped against that observed environment, so security teams KNOW what exists and where it is exposed before they spend human time or costly AI compute investigating vulnerabilities that may not affect what is running.

2. Discover vulnerabilities

“Agents use an asset inventory, source code, a threat model, and security policy to guide security scans and explore attack paths. Findings are combined with existing vulnerability reports into a broad pool of candidate vulnerabilities.”

A broad pool of candidates is one of the problems we built Miggo to drain. Discovery alone leaves security teams with a growing pool of findings to investigate, which is why Miggo applies per-environment impact analysis to determine which of those findings warrant attention. Miggo does not replace the scanners, CNAPPs, and exposure management tools already doing that basic discovery. It ingests what they find and settles the question they cannot answer, which is whether any of it is running. Miggo continuously scans newly disclosed CVEs through Miggo Pulse, which tracks exploitation as it emerges rather than waiting for a catalog to catch up, while vulnerability prioritization uses runtime reachability to trace affected code through the application and identify the root cause. This moves teams from understanding which vulnerabilities are present to which ones actually pose real risk in their environment.

3. Validate findings

“Given candidate findings and a runnable application, agents inspect code, reassess exposure, and attempt to reproduce suspected vulnerabilities in a controlled environment. They preserve reproduction evidence for confirmed vulnerabilities and check duplicates before creating approved issues.”

Proving it in a controlled environment is a good start. Production is the exam. While OpenAI validates exploitability in a controlled environment, Miggo shows the existence and reachability continuously in production, at fleet scale. Reachable means the vulnerable function actually executes in a running instance. Exploitable means an attacker can drive that path from outside. Miggo proves the first continuously and uses it to qualify the second, then scores what is left with MVSS Miggo’s runtime-aware severity score. Runtime reachability correlates each finding to the loaded library and traces the full execution path to determine whether the vulnerable function is executed in a specific application instance. Thus, risk and exploitability are determined from real running code and not static analysis, eliminating false positives from flow analysis. Findings are enriched with CVSS, EPSS, KEV, and SSVC, while instance-level binding makes deduplication inherent. Roughly 95% of the findings can then be identified as benign because the vulnerable code is unreachable, rather than incorrectly dismissed as false positives.

4. Assign validated findings

“Agents use company-specific skills to connect validated findings with company context, ownership records, and issue trackers, producing assigned issues with named owners and evidence.”

Miggo’s AppDNA maps each validated vulnerability to the service where it was observed, so the finding already carries the runtime context needed to identify where remediation belongs. Security teams can move from a vulnerable function to the affected service without reconstructing that relationship across separate systems. Miggo will soon add automated routing and issue labeling that carries that service-level attribution directly into remediation workflows, so the evidence gathered in production follows the finding to the team responsible for fixing it. Cloud-to-code mapping and business-unit assignment are the next part of the Miggo path.

5. Verify remediation

“Agents prepare and independently check a fix, review remediation pickup, and propose security hardening. After human review and authorized deployment, a proposed custom integration retests the deployed fix and records verification evidence.”

For production vulnerabilities, remediation ends with evidence from the running application. Miggo continuously scans the runtime SBOM as new code reaches production, tracking whether the vulnerable component is still present and whether the affected code remains reachable. That runtime evidence lets Miggo show when remediation has taken effect and automatically resolve the finding, giving security teams verification against the application state they are responsible for protecting.

The Missing Stage: Mitigation as Compensatory Controls

Every stage of the Defense Factory moves a vulnerability toward a patch. None of them protect the application while that patch is being written, reviewed, and deployed. That gap is the exposure window, and it is where attacks actually land.

Mitigation is what closes it: blocking exploitation of a known vulnerability in production before the fix ships. It belongs inside the loop, not after it.

The moment dynamic validation confirms a finding is real and reachable, mitigation should go up, and it should stay up until verified remediation proves the fix is deployed and the vulnerable code is no longer reachable.

Two layers in this stage do the work. At the edge, the organization’s existing WAF is tuned with exploit-specific rules that block the attack without touching legitimate traffic. Inside the application, in-app blocking detects and stops the exploit if an attacker gets past the edge.

This gives teams mitigation and protection through the exposure window. Remediation is the cure. Mitigation is the tourniquet. The two are not interchangeable, and you need both.

What OpenAI’s Defensive Loop Makes Clear

OpenAI’s Defense Factory, aligning with Miggo’s foundation of inventory first, the ability to correlate data from multiple sources, and a ‘trust-but-verify’ ethos, describes a continuous security architecture designed to carry vulnerabilities through to a verified patch in production.

Runtime evidence belongs at the center of continuous defense, from knowing what is deployed to proving remediation in production.

Miggo’s Defense-in-Depth provides the coverage and protection needed while the patch loop is spinning. Miggo WAF Copilot protects at the edge while in-app blocking holds the line inside the application, giving teams runtime mitigation through the exposure window. This buys time for teams to implement their typical patch process without worrying about an attack.

Miggo Security provides the runtime truth and mitigation capabilities a Defense Factory needs. See it in action.

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>