TUE, SEPTEMBER 29, 2026
Independent · In‑Depth · Practitioner‑Tested
Claude Productivity

Five Prompts to Redo Your Patch Maths After Astra

OpenAI says Astra scored 100% on ExploitBench and found two previously unknown zero-days during evaluation - the first model to meet the Critical cybersecurity threshold in its Preparedness Framework. Most patch policies were written when discovering a novel vulnerability was slow and expensive. These five prompts surface where your timelines quietly depend on that assumption.

⌨️ 5 prompts 🕐 Updated Sep 29, 2026
💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.
1
Find Where Your Policy Assumes Discovery Is Hard
Most policies never state this assumption, which is exactly why it survives unexamined.
Below is our vulnerability management policy.<br/><br/>Identify every place it depends, explicitly or implicitly, on the assumption that finding a novel vulnerability in our software is slow, expensive or requires a specialist.<br/><br/>For each one, quote the line and state the assumption underneath it.<br/><br/>Then rewrite that line for a world where an automated system can find a working zero-day in a hardened target.<br/><br/>Do not soften anything to be reassuring. If a timeline no longer makes sense, say it does not.<br/><br/>POLICY:<br/>[paste]
2
Map the Real Exposure Window
The segment people optimise is rarely the longest one.
Here is our deployment and patching process, with typical timings.<br/><br/>Calculate our actual exposure window from the moment a vulnerability exists in our stack to the moment it is patched everywhere in production.<br/><br/>Break it into: time to public disclosure, time to our awareness, time to triage, time to patch availability, time to full rollout.<br/><br/>Tell me which segment is longest, which is most within our control, and what the window becomes if disclosure and exploitation both compress to days.<br/><br/>PROCESS:<br/>[paste]
3
Audit What You Cannot Patch Quickly
The bottom two categories are the whole risk. Everything else is scheduling.
Below is our inventory of systems and dependencies.<br/><br/>Sort everything by how fast we could actually patch it, not how fast we would like to:<br/>- same day<br/>- within a week<br/>- requires a maintenance window<br/>- requires vendor action we do not control<br/>- effectively cannot be patched (end of life, embedded, contractual)<br/><br/>For the bottom two groups, tell me what compensating control stands between a known exploit and that system, and whether it would survive the exploit being public.<br/><br/>INVENTORY:<br/>[paste]
4
Stress-Test the Defender Advantage Argument
This argument underpins every access decision the labs are making. Worth holding rather than accepting.
The argument for releasing capable vulnerability-discovery models is that defenders gain more than attackers, because defenders can fix what they find and attackers already have working methods.<br/><br/>Argue both sides properly.<br/><br/>First the strongest case that this holds, with the conditions it needs to be true.<br/><br/>Then the strongest case against, especially where those conditions fail - organisations without security teams, software nobody maintains, and the gap between finding a bug and shipping a fix.<br/><br/>End by telling me which side my own organisation falls on, given this context: [describe your team size, stack and patch capability].
5
Write the Decision Before the Incident
Question 1 is the one that catches teams off guard - the report arrives and nobody has decided whether the method matters.
Draft our position, in advance, on three situations we will eventually face:<br/><br/>1. A vulnerability in our software is reported by someone using an AI system to find it. How do we treat the report, and does the reporter's method change anything?<br/><br/>2. We want to use such a tool on our own code. Who approves it, what do we do with findings we cannot fix, and what is our disclosure obligation if we find something in a dependency?<br/><br/>3. A critical vulnerability in a dependency goes public with a working exploit the same day. What are the first four hours?<br/><br/>Keep each answer short enough that someone can follow it at 2am.<br/><br/>CONTEXT:<br/>[paste]