Een AI-beveiligingsreview is nuttig wanneer een ingenieur zijn redenering kan reproduceren. Een lange lijst van verontrustende bevindingen helpt een team niet om te beslissen welke release te stoppen, welke wijziging aan te brengen of welke claim te verwerpen. De interessante ontwikkeling in Cloudflare’s security-audit-skill is de structuur rond die beslissing.
Cloudflare beschreef het bredere werk aan kwetsbaarheden in juni 2026. De openbare repository is een startpunt voor het auditen van één codebase. De huidige workflow doorloopt verkenning, dekking-geleide jacht, validatie van kandidaten, gestructureerde bevindingen, onafhankelijke verificatie en rapportage. Bevindingen hebben aparte bevestigde, onopgeloste en afgewezen staten. Een beoordelaar die de kandidaat niet heeft ontdekt, controleert het bewijs.
Ik zou dit evalueren als een manier om het beoordelingsproces te verbeteren, met een specifieke repository en een engineering eigenaar. Alleen het installeren van de vaardigheid garandeert niet dat een applicatie veilig is.
Begin met de vraag waarop de release afhankelijk is
Overweeg een hypothetische SaaS-release die het schakelen tussen organisaties toevoegt. Een brede aanvraag om elke kwetsbaarheid te vinden, kan een indrukwekkend rapport opleveren, terwijl de ene vraag die ertoe doet, mogelijk wordt gemist: kan een gebruiker de gegevens van een andere organisatie lezen na het wisselen van context?
Voor die release zou ik eerst de routes, caches, achtergrondtaken en exports opsommen die de organisatie-identiteit gebruiken. De beoordeling zou hetzelfde bedrijfsobject door die paden moeten volgen. Een bevinding over één controller is onvolledig als een eerdere controle het voorgestelde verzoek onmogelijk maakt. Evenzo legt een correcte controller niet uit wat een vertraagde taak later zal lezen.
Dit is waarom dekking een betekenis nodig heeft. Een geopend bestand is bewijs van aandacht, niet bewijs dat elk relevant gedrag is onderzocht. Ik wil dat het rapport de gecontroleerde grens identificeert en wat buiten de beoordeling blijft.
Een bevinding moet een gewone technische conversatie overleven
Voordat ik code wijzig, zou ik verwachten dat een bevinding vier vragen beantwoordt: welke invoer is gecontroleerd, welk pad accepteert het, welke bescherming faalt en welk resultaat is waargenomen? Die antwoorden moeten verwijzen naar de gecontroleerde revisie. Een link naar een functie die sindsdien is veranderd, is niet genoeg om de discussie te sluiten.
| Claim in een rapport | Bewijs dat ik zou vragen om |
|---|---|
| Een record kan een organisatiegrens overschrijden. | De belleridentiteit, relevante records en de reactie die de kruising aantoont. |
| Een ontbrekende controle creëert een blootstelling. | Bevestiging dat een andere laag dezelfde regel niet al afdwingt. |
| Een oplossing sluit het probleem af. | Een gerichte controle die faalt vóór de wijziging en erna slaagt. |
Deze standaard maakt ook meningsverschillen goedkoper. Een onopgeloste claim kan een klein onderzoek worden met een gedefinieerd ontbrekend feit. Het hoeft geen noodsituatie of een discussie te worden over de vraag of het model over het algemeen betrouwbaar is.
Gebruik een beperkte pilot voordat je het een releasepoort maakt
Mijn voorgestelde eerste uitvoering zou een kleine, representatieve module dekken. Houd productie-inloggegevens buiten de uitvoeringsomgeving en gebruik synthetische records. De repository zelf vereist een besturingssysteem-sandbox voor het uitvoeren van doelgerichte code. Een prompt die zegt “wees voorzichtig” is geen gelijkwaardige controle.
De pilot moet de beoordelingsinspanningen meten, evenals de geaccepteerde bevindingen. Hoe lang besteedt een ingenieur aan het verifiëren van elke kandidaat? Kan een tweede ingenieur het belangrijke resultaat reproduceren? Onderscheidt de output het werk dat is voltooid van het werk dat niet kon worden uitgevoerd? Deze vragen maken de waarde van de tool waarneembaar zonder succespercentages van iemands anders codebase te lenen.
Onafhankelijke beoordeling is ook belangrijk vóór de implementatie. Mijn artikel over Claudex Loop en cross-model plan beoordeling kijkt naar dat eerdere beslissingspunt. Voor teams die diensten aan agents blootstellen, voegt het veranderende MCP transportmodel een andere integratiegrens toe die het waard is om in de beoordeling op te nemen.
Zet het rapport om in eigen werk
Een nuttige overdracht verbindt elke geaccepteerde bevinding met een eigenaar, een nauwkeurig afgebakende wijziging en een verificatieresultaat. Houd afgewezen kandidaten bij met hun redenering, zodat de volgende ronde dezelfde misverstanden niet opnieuw ontdekt. Plan vervolgwerk rond veranderd gedrag in plaats van een willekeurig aantal schone scans.
Als uw team een AI-assistent of agentintegratie toevoegt aan een bestaande applicatie, kan mijn AI-integratiewerk het definiëren van deze beoordelingsgrenzen en het bewijs dat nodig is voor de release omvatten.
Bronnen gecontroleerd op 7 oktober 2026: de gelinkte repository README en het artikel van Cloudflare over harness. Dit is een documentatie-gebaseerde beoordeling; er is geen benchmark of beveiligingsaudit van een klantensysteem uitgevoerd voor dit artikel.