Kan AI-baserad säkerhetstestning ersätta SAST, DAST och penetrationstester?

Den användbara frågan är var en agent förtjänar förtroende. Jag litar på att den kan bredda gransknings­täckningen, koppla ihop ledtrådar mellan filer, skapa riktade tester och göra en svårtolkad skannerlogg till en åtgärd som utvecklaren förstår. Jag litar inte på att den kan härleda företagets behörighetsregler från routenamn, bevisa att varje tenantgräns håller eller avgöra att ett märkligt ekonomiskt arbetsflöde är missbruk utan att en människa först har formulerat regeln. Se agenten som en aktiv granskare i ett lagerindelat testprogram, inte som hela programmet.

En agentgranskning är en tolk, inte en ny testklass

En AI-agent förändrar hur bevis samlas in och förstås. Den skapar inte en ny sorts bevis. Om den läser källkod utan att köra applikationen utför den en flexibel form av statisk granskning. Om den skickar anrop till ett körande mål utför den dynamisk testning. Om den utforskar mål, ändrar taktik och följer oväntat beteende liknar den en penetrationstestare, men likheten ger den varken testarenes mandat eller affärssammanhang.

Skillnaden spelar roll när en leverantör säger att agenten «ersätter skannrar». Fråga vad systemet faktiskt kan observera. Får det hela kodbasen, genererad kod, byggflaggor, infrastrukturpolicy och låsfiler för beroenden? Kan det autentisera som flera användare och kontrollera databastillståndet efter varje anrop? Vet det vilka åtgärder som förbjuds av policyn, i stället för att bara se vad som saknas i gränssnittet? En välskriven förklaring kan inte kompensera för saknade indata.

Agenter är verkligen bra på att koppla ihop svaga signaler. En vanlig regel kan flagga att en parameter når en frågebyggare. En agent kan granska omslutningen, upptäcka att ett anrop saknar tenantpredikatet, skapa ett testanrop och förklara varför den påstått säkra hjälpfunktionen är osäker i just den vägen. Den kan också avfärda ett fynd när värdet passerar genom ett riktigt parametriserat API. Det ger bättre triage, men bevisar inte att statisk eller dynamisk analys har blivit överflödig.

Den tydliga gränsen går mellan granskning och verifiering. Granskning frågar: «Ser implementationen osäker ut utifrån materialet jag kan se?» Verifiering frågar: «Kan den här aktören under angivna villkor orsaka ett förbjudet resultat?» AI hjälper till med båda, men en säkerhetsgrind bör ange vilket påstående den gör. Team får problem när en välformulerad granskningsobservation upphöjs till en verifierad exploatering, eller när ett misslyckat exploateringsförsök behandlas som bevis på säkerhet.

Modellens beteende skapar ytterligare en skillnad: förmåga är inte repeterbarhet. En agent kan upptäcka en subtil väg i en körning och missa den efter att en modell, prompt, sökindexering eller verktygspolicy har ändrats. Spara promptar, verktygsbehörigheter, hämtade filer, genererade anrop och modellidentifierare när ett resultat är viktigt. Gör sedan bekräftade upptäckter till tester där godkänt resultat inte beror på att modellen hittar samma idé igen.

SAST står fortfarande för repeterbar källkodstäckning

SAST är fortfarande det billigaste sättet att tillämpa stabila kontroller på varje ändring i en stor kodbas. Det kan räkna upp källor och sinks, förbjuda API:er, granska dataflöden och rapportera exakt vilken revision som analyserades. En deterministisk regel ger samma resultat i morgon, vilket är viktigt när en releasegrind behöver ett granskningsbart skäl att godkänna eller stoppa en release.

En agent tillför sammanhang som regelmotorer ofta saknar. Den kan följa projektspecifika omslutningar, läsa kommentarer kritiskt, jämföra en hanterare med närliggande hanterare och föreslå en fråga för ett nytt mönster. Den kan upptäcka misstänkta utelämnanden, till exempel när nio endpoints anropar authorizeProject() medan en tionde läser posten direkt. Den är också användbar när genererad kod eller ett okänt ramverk gör att ett standardpaket av regler inte räcker.

Men agentens källkodstäckning är oftast svårare att bevisa. Kontextfönster, sökrankning, ignorerade filer, genererade artefakter och tidsgränser för verktyg kan lämna kod oläst. Att be den «granska den här kodbasen efter injektion» visar inte att varje sink nåddes. En SAST-rapport kan åtminstone ange vilka filer, regler och revisioner som analyserades. En agent behöver en motsvarande täckningslogg innan den kan ta över en obligatorisk grind.

NIST SP 800-218 ger här en rimlig rekommendation: använd kodanalys tidigt och verifiera säkerhetsfunktioner och åtgärder manuellt. Värdet ligger i kombinationen. Stabiler regler fångar kända felmönster vid varje commit. Agenten utreder undantag, skriver fokuserade regressionstester och hjälper till att finjustera regler när samma mönster återkommer. Att ta bort SAST för att agenten har hittat några kluriga buggar byter mätbar bredd mot imponerande anekdoter.

SAST ser också kod som ett körande test kanske aldrig når: felvägar, featureflaggor, migreringsverktyg, vilande admin-endpoints och plattformsspecifika grenar. Det kan inte avgöra om den distribuerade miljön aktiverar dessa vägar. Osäkerheten är ett skäl att lägga till körningsbevis, inte att kasta bort statisk täckning.

Det finns gränser för vad som bör vara en blockerande SAST-regel. Ett exakt mönster för ett förbjudet kryptografiskt primitiv kan stoppa bygget direkt. En bred heuristik som frågar om en behörighetskontroll «ser tillräckligt nära ut» bör vanligtvis skapa en granskningsuppgift tills teamet har mätt precisionen. Agenter kan hjälpa till att göra en heuristik till en regel genom att samla sanna exempel, motexempel och vanliga omslutande funktioner i kodbasen. Då förblir grinden strikt utan att utvecklarna lär sig ignorera den.

Genererade korrigeringar kräver samma granskning som fynd. En modell kan tysta en taint-logg genom att lägga valideringen på fel lager, fånga ett undantag och fortsätta på ett osäkert sätt eller ersätta ett farligt anrop samtidigt som beteendet ändras. Kör det ursprungliga beviset mot patchen, kör vanliga funktionstester och granska den nya kontrollen där förtroendet etableras. En ren omskanning bevisar bara att den ursprungliga regeln inte längre matchar.

DAST bevisar beteende som kodbasen inte kan visa

DAST observerar den applikation som faktiskt körs, inklusive proxiregler, headers, serialisering, autentiseringsmiddleware, ramverkets standardinställningar och fel i distributionen. En källkodsgranskning kan säga att en endpoint verkar skyddad. Ett dynamiskt test kan visa att produktionsrouten kringgår middleware eftersom en gateway skriver om dess sökväg.

Här kan en agent göra dynamisk testning betydligt mindre trubbig. Ge den en API-beskrivning, testidentiteter, tillåtna behörigheter och en isolerad miljö, så kan den bygga anropssekvenser i stället för att sprida generiska payloads. Den kan föra ett resurs-ID från ett svar till nästa anrop, förnya en session, jämföra två roller och kontrollera om en skrivning förändrade senare läsningar. Traditionell DAST har ofta svårt med sådana tillståndsberoende flöden.

Agenten behöver fortfarande strikta driftsgränser. En crawler vet inte om det är säkert att skicka e-post, skapa en leverans eller anropa en betald integration. Även en testmiljö kan vara ansluten till riktiga tjänster. Definiera tillåtna värdar, konton, anropshastigheter, destruktiva åtgärder och stoppvillkor utanför modellens prompt och verkställ dem i körmiljön. En mening som säger «undvik farliga åtgärder» är ingen kontroll.

Behåll en konventionell dynamisk baslinje för välkända kontroller som säkerhetsheaders, exponerade filer, reflekterad indata, vanliga injektionsförsök och TLS-konfiguration. De kontrollerna är billiga, jämförbara mellan releaser och enkla att följa över tid. Låt agenten använda sin budget på autentiserade vägar och kedjat beteende. Om båda systemen täcker samma enkla test, behåll det som har tydligare bevis och lägre variation.

DAST kan också skapa en falsk känsla av fullständighet eftersom den bara rapporterar det som nåddes. Spara routetäckning, använda identiteter, featureflaggor och testdata tillsammans med resultatet. En ren skanning mot ett nästan tomt konto säger mycket lite om en applikation vars farliga grenar först uppstår efter godkännande, inbjudan, fakturering eller dataimport.

Autentiseringskonfigurationen behöver egna bevis. Dokumentera hur testet fick varje session, vilka andrafaktorer eller enhetskontroller som kringgicks i testmiljön och om tokens har samma claims och livslängd som produktionstokens. En manuellt skapad administratörstoken kan ge bra täckning men hoppa över de sessioner och behörighetsövergångar som faktiskt behöver testas. Gör sådana genvägar synliga i rapporten.

Dynamisk omtestning bör börja med den sparade anropssekvensen, inte med en ny autonom crawl. Spela upp det bekräftade beviset mot den korrigerade bygget, verifiera att den förbjudna effekten har upphört och variera sedan närliggande indata för att upptäcka ett smalt filter. Låt därefter agenten utforska. Den ordningen skiljer «korrigeringen blockerar den kända exploateringen» från det bredare påståendet att hela felklassen är borta.

Behörighetstester behöver identiteter och förbjudna resultat

Behörighet är inte att «endpointen returnerade 403 en gång». Ett användbart test anger vem som agerar, vilket objekt som nås, vilken åtgärd som försöks och vilket resultat som måste förbli omöjligt. En agent kan skapa kombinationerna, men produktägaren och säkerhetsgranskaren måste tillhandahålla policyn.

OWASP ASVS säger att applikationer bör verkställa åtkomstkontroll i ett betrott tjänstelager och tillämpa minsta privilegium på funktioner och data. Jag håller med om kravet på tjänstelager, men team verifierar det ofta för snävt. De testar den synliga HTTP-hanteraren och glömmer bakgrundsjobb, exporter, sökindex, websocket-prenumerationer och direkta URL:er till objektlagring. Samma policy måste överleva varje väg till objektet.

En liten körbar matris avslöjar mer än den vaga instruktionen «testa IDOR». Följande shellfragment förutsätter en isolerad miljö, två bearer-tokens och ett dokument som ägs av användare A. Det kontrollerar både status och att A:s hemliga markör saknas i B:s svar:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

Förväntat resultat är tystnad och exitstatus noll. Ett CI-fel bör spara status, sanerad body, agerande identitet, målens ägare, route och byggrevision. Spara inte aktiva inloggningsuppgifter eller orelaterade svarsdata.

Variera sedan en dimension i taget: läsning jämfört med uppdatering, direkt ID jämfört med sökning, aktiv jämfört med återkallat medlemskap, normal route jämfört med export samt användartoken jämfört med tjänstetoken. Agenten kan skapa och köra fallen effektivt. En människa måste granska om matrisen motsvarar policyn och om 404, 403, tomt resultat eller ett maskerat objekt är det avsedda resultatet. Annars kan agenten hylla ett beteende som verksamheten betraktar som ett intrång.

Negativa bevis kräver omsorg. En nekad uppdatering kan ändå avslöja att ett objekt finns genom svarstid, feltext eller en versionsräknare. En nekad läsning kan öka en visningsräknare eller skriva en auditpost med hemlig metadata. Bestäm vilka sidoeffekter som är tillåtna och gör sedan påståenden om dem. Säkerhetstester som bara granskar svaret kan missa en användbar kanal för uppräkning eller en skadlig skrivning.

Testa också policyändringar under en session. Ta bort en användare från ett projekt, flytta ägarskap, inaktivera ett konto eller begränsa en tjänsteroll och använd sedan gamla tokens och öppna anslutningar igen. Förväntad återkallningstid måste komma från produktpolicyn. «Så småningom» går inte att testa, och omedelbar återkallning kan vara onödig, men teamet måste välja en gräns och verifiera den för API-anrop, köat arbete, nedladdningar och aktiva prenumerationer.

Tenantisolering fallerar utanför den uppenbara anropsvägen

Tenantisolering behöver tester vid lagring, cache, köer, sökning, filer, analys och administrativa gränser. Det vanliga felet är inte att tenant_id saknas i huvudendpointen. Det är en sekundär väg som kopierar, indexerar, cachar eller exporterar data utan att föra med tenantkontexten.

Börja med två tenants som innehåller avsiktligt liknande poster och varsin omisskännlig markör. Använd separata användare, separata sessioner och, där arkitekturen tillåter, separata tjänsteuppgifter. Testa skapa, läsa, uppdatera, ta bort, lista, söka, exportera, importera, bifoga filer, leverera aviseringar och köra bakgrundsprocesser. Efter varje åtgärd granskar ni både det användarsynliga svaret och det bestående tillståndet. Ett nekat anrop som ändå lägger ett tenantöverskridande jobb i kön är ett fel.

Agenter är användbara eftersom de kan följa en identifierare genom flera lager och skapa varianter som människor tycker är tråkiga. De kan upptäcka att cache-nyckeln använder document_id medan databasfrågan använder både tenant_id och document_id. De kan jämföra en exportarbetare med den interaktiva hanteraren och fråga varför bara den ena sätter radnivåkontext. Det är värdefulla granskningssteg.

De gör också ett farligt antagande: namn innebär gränser. En funktion som heter getTenantDocument kan ta emot ett godtyckligt tenantargument från anropet. En datapolicy kan finnas i migreringar men saknas i en ny tabell. Ett sökfilter kan tillämpas efter att resultaten räknats och därmed läcka en annan tenants aktivitet. Verifieringen måste granska det verkställda predikatet och sedan försöka läsa och skriva över tenantgränsen.

Låt inte agenten skapa sin egen facitkälla genom att läsa samma kod som den testar. Härled förväntad åtkomst från en oberoende policymatris som underhålls tillsammans med produktkraven. Om implementationen och testet missförstår samma regel kommer de att överensstämma perfekt samtidigt som data exponeras.

Asynkrona vägar behöver fördröjda påståenden. Starta ett export-, meddelande-, miniatyr- eller indexeringsjobb som tenant A, ändra ägarskap eller medlemskap innan arbetaren körs och granska var resultatet hamnar. Bestäm om arbetaren ska använda behörigheten från anropstillfället eller kontrollera aktuell behörighet igen vid körning. Båda valen kan vara korrekta för en viss åtgärd, men en oavsiktlig blandning skapar läckor och trasiga auditspår.

Administrativa verktyg behöver separata identiteter och loggkontroller. Supportåtkomst går ofta över tenantgränser avsiktligt, vilket gör regeln «en annan tenant måste nekas» felaktig. Testa att operatören har rätt roll och ärendekontext, att kundpolicyn följs, att åtkomsten upphör och att auditposten identifierar operatören i stället för att utge sig för att vara kunden.

Affärslogik kräver en berättelse om missbruk

Testning av affärslogik börjar med en förbjuden berättelse: en användare får ett värde, en behörighet eller ett tillstånd som hen inte ska få genom att utföra giltiga åtgärder i fel ordning eller kombination. Generiska sårbarhetsnamn räcker inte. Testaren behöver veta hur inbjudningar, godkännanden, kvoter, återbetalningar, krediter, ägarbyten och avbokningar ska samverka.

OWASP Web Security Testing Guide ber testare försöka hoppa över arbetsflödessteg, upprepa funktioner, förfalska anrop, ändra timing och missbruka giltiga funktioner. Den äldre introduktionen till affärslogik säger rakt ut att skannerautomatisering inte kan tillhandahålla den applikationsspecifika kunskap eller kreativitet som krävs. Moderna agenter förbättrar automatiseringen, men tar inte bort kunskapsluckan. En modell kan föreslå att en kupong kan återanvändas. Den kan inte veta om det är en kampanj eller bedrägeri innan någon anger regeln.

Ge agenten en tillståndsmodell med tillåtna övergångar och invariants. För ett godkännandeflöde kan en invariant vara: «En beställare får inte godkänna sin egen betalning, inte heller efter ett ägarbyte.» Be den sedan skapa sekvenser med rolländringar, dubbla anrop, avbokning, återförsök, samtidighet och gamla sessioner. Agenten kan utforska långt fler sekvenser än en person kommer att köra manuellt.

De svåra fallen handlar om konsekvenser utanför HTTP-svaret. Två samtidiga inlösenanrop kan båda returnera framgång samtidigt som en senare avstämning tar bort det ena. En avbokning kan stoppa det synliga jobbet men inte återkalla en signerad nedladdning. En inbjudan som accepteras efter att inbjudaren har förlorat åtkomst kan skapa ett övergivet medlemskap. Tester måste observera liggare, köer, objektbehörigheter och senare tillstånd, inte bara statuskoder.

Mänskliga testare behövs eftersom de ifrågasätter den angivna modellen. De frågar om supportpersonal kan kombinera ofarliga funktioner, om en operatör kan påverka sitt eget auditspår eller om ett «utgånget» objekt fortfarande kan användas via en annan kanal. En agent arbetar inom de mål och verktyg den får. En människa kan se att målen utelämnar den farliga delen av verksamheten.

Beroenderisk är mer än en sårbar version

Beroendetestning innehåller fyra separata frågor: vilka paket som finns, om deras kända versioner har rapporterade sårbarheter, om bygget hämtade avsedda artefakter och om applikationen faktiskt exponerar det sårbara beteendet. Software composition analysis (SCA) och kontroller av proveniens besvarar de tre första mer tillförlitligt än enbart en konversationsbaserad granskning.

En agent är användbar när inventeringen finns. Den kan granska hur ett beroende anropas, avgöra om den berörda funktionen är nåbar, hitta en kompenserande kontroll och skapa en uppgraderingspatch med regressionstester. Den kan också flagga riskfyllt paketbeteende utan sårbarhets-ID, till exempel att ett installationsskript får nätverksåtkomst eller att ett nytt bibliotek får hemligheter i sin miljö.

Be inte modellen minnas aktuell sårbarhetsinformation. Ge den en tidsstämplad rådgivningskälla, den upplösta låsfilen och en inventering av byggartefakter. Modellminne är ingen sårbarhetsdatabas, och ett paketmanifest bevisar inte vad som faktiskt levererades. SLSA-proveniens gör en närliggande skillnad: proveniens beskriver var, när och hur en artefakt skapades. Den förklarar inte att artefakten är säker.

Nåbarhet kan sänka prioriteten i triage, men bör inte ta bort ägarskapet. Featureflaggor ändras, död kod återkommer och indirekta beroenden börjar användas på oväntade sätt. Dokumentera varför ett fynd sköts upp, vilken version och anropsväg som bedömdes och vilken händelse som ska öppna det igen. Agenten kan underhålla resonemanget medan en deterministisk inventering bevakar händelsen.

Paketnamn skapar också identitetsfällor. Ett beroende med rätt namn kan komma från fel register, en låsfil kan peka på en föränderlig plats eller ett byggsteg kan ladda ner kod som saknas i manifestet. Kontrollera upplösta källor, hashvärden, signaturer där ekosystemet stöder dem och byggnätverkets åtkomst. En agent kan förklara avvikelser, men byggsystemet måste verkställa vilka källor det accepterar.

Uppgraderingar är inte automatiskt säkra ändringar. En säkerhetsrelease kan ändra parsning, standardbehörigheter eller serialisering på sätt som bryter applikationen. Skapa en minimal reproduktion för rådgivningen, tillämpa uppgraderingen i en isolerad gren och kör både säkerhetsbeviset och funktionstesterna. Bevisen stöder ett beslut. Att en modell säger att den nya versionen «bör vara kompatibel» gör det inte.

Falska positiva resultat är ett problem med bevisdesign

Ett fynd förtjänar utvecklarens tid först när det innehåller ett påstående, bevis, påverkan och en reproducerbar väg. AI-genererade rapporter kan låta fullständiga samtidigt som en av delarna saknas. Flytande åtgärdstext gör svaga bevis svårare att upptäcka.

Kräv att varje agentfynd anger analyserad revision och miljö, berörd komponent, angriparförutsättningar, passerad säkerhetsgräns, observerat eller härlett resultat, reproduktionssteg och osäkerhet. Markera härledda källkodsfynd annorlunda än körda exploateringar. Om agenten inte kunde köra applikationen ska det stå i fyndet, inte döljas i en övergripande skanningsnotis.

Använd sedan en enkel uppsättning statusar: bekräftat, sannolikt, behöver sammanhang, kan inte reproduceras, accepterad risk eller åtgärdat. «Falskt positivt» bör betyda att säkerhetspåståendet är fel, inte att teamet ogillar allvarlighetsgraden eller har valt att skjuta upp arbetet. Om besluten blandas ihop går återkopplingen förlorad. Agenten kan inte lära sig vilken regel som misslyckades om varje oönskat ärende får samma etikett.

AI kan minska brus genom att gruppera dubbla spår, kontrollera saneringar och testa igen efter en korrigering. Den kan också förstärka bruset genom att skapa tio övertygande varianter av en svag misstanke. Deduplikera efter grundorsak och gräns, inte efter URL. En saknad ägandekontroll som används av åtta endpoints är ett tekniskt fel med åtta exponeringspunkter.

Följ precisionen per kategori och testkälla. Om agentgenererade XSS-rapporter oftast är giltiga men påståenden om race conditions sällan kan reproduceras, ska de hanteras olika. Minska inte resultatet till ett enda mått över orelaterade feltyper. En grind bör fallera på bevis och policy, inte på modellens adjektiv för säkerhet.

Ägarskap sluter kretsen. Varje accepterat fynd behöver en ansvarig person eller grupp, en förväntad omtestningsmetod och ett sparat bevis som en annan testare kan köra. Om rapporten bara finns i en agentkonversation försvinner den när konversationen, modellen eller leverantören ändras. Säkerhetsarbete blir hållbart när bevisen överlever verktyget som skapade dem.

Integritet spelar också roll under triage. Källkod, anropskroppar, loggar och databasprover kan innehålla lösenord eller kunddata. Begränsa vad agenten får, maska sparade transkript, skilj testdata från produktionsdata och följ organisationens regler för datahantering hos modellleverantören och dess verktyg. Bättre upptäckt motiverar inte att en hel produktionsincident kopieras in i en okontrollerad prompt.

Ett mänskligt penetrationstest granskar antagandena bakom testet

En erfaren penetrationstestare ändrar planen när applikationen motsäger uppdraget. Det är den del som agenter ännu inte har ersatt. Personen intervjuar ägare, löser otydliga regler, upptäcker operativa genvägar, ber om en annan identitet och avgör när ett märkligt beteende förtjänar en längre kedja av experiment.

Människor kan också ta ansvar för bedömningar när bevisen är ofullständiga. De kan skilja en tekniskt möjlig åtgärd från en trovärdig attackväg, förklara en sammansatt brist för ledning och ingenjörer och förhandla fram ett säkert bevis när exploatering kan skada data. En autonom agent måste stanna vid den gräns som operatören har satt. Om den tyst utvidgar gränsen har den blivit en ny säkerhetsrisk.

Det betyder inte att varje release kräver ett veckolångt externt uppdrag. Använd mänsklig testning där förändring och konsekvens möts: en ny behörighetsmodell, tenantarkitektur, betalnings- eller kreditflöde, administrativ yta, känslig integration, större migrering eller offentlig lansering. Planera bredare återkommande arbete utifrån risk och testa allvarliga korrigeringar igen. Även rutinreleaser behöver automatiserad täckning.

Ge testaren agentens resultat, SAST-spår, DAST-täckning, arkitekturnoteringar, testkonton och olösta antaganden. Agenten kan hantera rekognosering och upprepade variationer medan testaren följer upp överraskande beteenden. Det gör den mänskliga tiden mer produktiv utan att låtsas att den är onödig.

Var försiktig med påståenden om «autonom penetrationstestning» som mäts i antal fynd. Tio välkända injektionsfynd motsvarar inte en demonstrerad väg genom rolltilldelning, gammal behörighet och exportlagring. Bedöm arbetet efter testade gränser, bevisens kvalitet och viktiga ifrågasatta antaganden.

Bestäm vem som ansvarar för städning innan uppdraget börjar. Testkonton, uppladdade filer, köade meddelanden, tillfälliga roller och ändrade featureflaggor kan överleva skanningen. En mänsklig ansvarig bör godkänna destruktiva bevis, hålla kontakt med driften och kontrollera återställningen. Agenten kan följa ett städschema, men kan inte avgöra om ett oförklarat produktionstillstånd är säkert att ta bort.

En bra testare rapporterar också vad som inte kunde testas. Saknade mobilbyggen, otillgängliga roller, hastighetsbegränsningar, callbacks från tredje part och instabila miljöer minskar säkerheten i slutsatsen. Agenter fortsätter ofta att arbeta runt hinder och visar bara vägarna de slutförde. Slutrapporten måste göra undantagen tydliga så att ett rent resultat inte misstas för fullständig täckning.

Bygg en grind av flera sorters bevis

Det rätta programmet ger varje metod ett uppdrag och låter resultaten mötas mot samma säkerhetskrav. Använd SAST för deterministiska källkodsmönster och bred täckning av ändringar. Använd SCA och proveniens för fakta om beroenden och byggen. Använd DAST för distribuerat beteende och grundläggande körningskontroller. Använd agenter för att koppla ihop bevis, utforska autentiserade flöden, skapa tester och förbättra triage. Använd människor för att definiera policy, utmana affärsantaganden och utreda ändringar med stora konsekvenser.

En releasepolicy kan då vara specifik. Stoppa ett bygge när en deterministisk regel med hög allvarlighetsgrad matchar en ej godkänd väg, när en obligatorisk behörighetsinvariant bryts, när en tenantmarkör exponeras eller när en bekräftad exploatering fortfarande är öppen. Skicka osäkra agentfynd till granskning med en tidsgräns baserad på exponeringen. Låt inte modellens egen bedömning av säkerhet avgöra om produktionen lanseras.

Behåll bevisen portabla. Exportera fynd, genererade tester, anropstranskript, verktygsversioner, revisioner, identiteter, täckning och beslut i format som teamet kan granska utan agenten. Det är viktigt vid revisioner, incidentgranskning, leverantörsbyten och den vanliga dagen då en modelluppdatering ändrar beteendet.

För applikationer som skapas genom chatt gäller samma uppdelning. Koder.ai kan generera webb-, server- och mobilapplikationer och exportera deras källkod, men genererad programvara behöver fortfarande uttryckliga säkerhetskrav och oberoende tester mot det distribuerade resultatet. Snabb skapandetakt gör en tydlig grind mer användbar eftersom arkitektur och kod kan ändras snabbt.

Kör agenten kontinuerligt, men gör de bästa upptäckterna till deterministiska regressionstester. Varje bekräftat behörighetsbypass ska bli ett policyfall. Varje tenantläcka ska lägga till en invariant vid den gräns som fallerade. Varje brusig regel ska få ett dokumenterat beslut. Med tiden bör agenten lämna testsystemet mer precist än det var från början.

Fråga inte vilket enskilt verktyg som vinner. Fråga om varje viktigt påstående har oberoende bevis: kodvägen granskades, det distribuerade beteendet testades, affärsregeln kom från en ansvarig ägare och en människa utmanade antagandena där ett fel skulle få stora konsekvenser. Om någon av dessa rader är tom fyller ett AI-genererat «allt ser bra ut» inte luckan.