Een CodeAuditAgent-rapport lezen en ernaar handelen

Een beveiligingsrapport is alleen nuttig als het uitmondt in gemergde fixes. CodeAuditAgent-rapporten zijn daaromheen ontworpen: elke bevinding is specifiek genoeg om snel te verifiëren en komt met een patch die je kunt aanpassen. Deze gids legt elk onderdeel van een rapport uit, hoe je het triageert zonder eigen securityengineer, en hoe je bevestigt dat je fixes hebben gewerkt.

Wat er wordt geauditeerd

Een audit draait op een openbare GitHub-repository of op een codefragment dat je plakt. Bij repository’s leest CodeAuditAgent de standaardbranch. Privérepository’s kunnen niet via een URL worden geauditeerd, en reviewopmerkingen bij pull requests bestaan nog niet; resultaten staan in het dashboard en in exports.

Hoeveel van een repository wordt gelezen, hangt af van je abonnement. Het Free-abonnement dekt 1 repository, 3 audits per maand en maximaal 20 bestanden per audit. Starter, voor $49 per maand, dekt 5 repository’s, 50 audits en 40 bestanden per audit. Pro, voor $199 per maand, dekt onbeperkt repository’s, 500 audits en 80 bestanden per audit. Losse bestanden groter dan 60 KB worden overgeslagen. De maandelijkse audittellers worden aan het begin van elke kalendermaand (UTC) gereset. Een geplakt codefragment is ook een snelle manier om één bestand te controleren waar je je zorgen over maakt, voordat je de hele repository auditeert.

Worden er bestanden weggelaten door deze grenzen, dan wordt het rapport als gedeeltelijke snapshot gemarkeerd. Neem dat label serieus. Een schoon gedeeltelijk rapport betekent dat de gelezen bestanden er schoon uitzien, niet dat de repository dat is. Is juist de code die je het meest aangaat weggelaten, auditeer die dan als geplakt codefragment of op een abonnement dat meer bestanden dekt.

De risicoscore

Bovenaan elk rapport staat een risicoscore van 0 tot 100; de Markdown-export vermeldt daarnaast de algehele ernst. Hoger betekent meer risico. Het is een samenvatting van de bevindingen in die audit, en nuttig voor twee dingen: bepalen hoe dringend je naar een repository moet kijken, en volgen of het er met de tijd beter op wordt.

Lees niet te veel in kleine verschillen tussen ongerelateerde repository’s. Een score is altijd relatief aan wat er is geauditeerd, en een gedeeltelijke snapshot ziet minder code. Dezelfde repository vóór en na fixes vergelijken is waar het getal het meest zegt.

Ernst en betrouwbaarheid

Elke bevinding heeft een ernst en een betrouwbaarheid. Ze beantwoorden verschillende vragen: ernst is hoe erg het zou zijn als de bevinding echt is, en betrouwbaarheid is hoe zeker de reviewer is dat ze echt is.

• Kritiek: direct exploiteerbaar met ernstige impact, zoals injectie op een openbaar endpoint, omzeiling van authenticatie of blootgestelde productiecredentials.
• Hoog: een echte kwetsbaarheid die een voorwaarde nodig heeft, of met aanzienlijke maar beperkte impact.
• Gemiddeld: een zwakte die ertoe doet in combinatie met andere bugs, of met matige impact.
• Laag: hardeningkwesties en gaten in de verdediging in de diepte.
• Info: observaties die goed zijn om te weten maar op zichzelf geen kwetsbaarheid zijn.

De betrouwbaarheid is hoog, gemiddeld of laag. Een bevinding met hoge betrouwbaarheid heeft duidelijk bewijs in de gelezen code. Een bevinding met lage betrouwbaarheid hangt meestal af van iets wat de audit niet kon zien, zoals middleware in een ander bestand, een databasebeleid of een configuratiewaarde die bij het deployen wordt gezet. Lage betrouwbaarheid betekent niet negeren; het betekent dat een mens de ontbrekende context moet controleren voordat er wordt gefixt.

Anatomie van een bevinding

Elke bevinding volgt dezelfde structuur, zodat je ze in een vaste volgorde kunt verifiëren.

• Titel en CWE: de klasse van de zwakte, zoals CWE-639 voor een omzeiling van autorisatie via een door de gebruiker bestuurde sleutel. De CWE vertelt je wat voor fix je kunt verwachten.
• Locatie: het bestand en de regel, zodat je de code meteen kunt openen.
• Bewijs: de relevante code, geciteerd uit het bestand. Controleer of het citaat overeenkomt met je huidige code; is de regel al gewijzigd, dan kan de bevinding verouderd zijn.
• Exploitscenario: hoe een aanvaller de zwakte daadwerkelijk zou gebruiken, stap voor stap. Dit is de snelste manier om te beoordelen of het in jouw context echt is.
• Herstelpatch: een voorgestelde wijziging in de stijl van de omringende code.

Zie de patch als een sterk startpunt, niet als een merge-klare commit. Hij is geschreven vanuit de code die de audit heeft gelezen, dus hij kent misschien je helperfuncties, je ORM-conventies of een aanroeper elders in de codebase niet. Een typische patch is klein en gericht:

--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
-  const invoice = await db.invoice.findUnique({ where: { id } });
+  const invoice = await db.invoice.findFirst({
+    where: { id, userId: session.user.id },
+  });
   if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });

Positieve observaties en vervolgstappen

Rapporten noemen ook wat er goed gaat: consequent geparametriseerde queries, secrets die uit de omgeving worden geladen, een strikte cookieconfiguratie. Die zijn het lezen waard. Ze vertellen je welke patronen je moet behouden en naar nieuwe code moet kopiëren, en ze zijn nuttig als je de staat van een codebase aan iemand anders uitlegt.

Het onderdeel met aanbevolen vervolgstappen maakt van de bevindingen een geordend plan. Het groepeert vaak verwante bevindingen, bijvoorbeeld meerdere ontbrekende eigenaarscontroles die het best met één gedeelde helper worden opgelost in plaats van met vijf aparte patches.

Een triageproces voor kleine teams

Zonder securityengineer is het risico niet dat je een rapport negeert; het is dat je een dag aan lage bevindingen besteedt terwijl een kritieke wacht. Een eenvoudige volgorde werkt goed:

• Lees eerst elke kritieke en hoge bevinding. Lees bij elk het exploitscenario en beslis: echt, niet echt, of context nodig.
• Los echte kritieke bevindingen dezelfde dag op. Kost een fix tijd, voeg dan een tijdelijke maatregel toe, zoals het endpoint uitschakelen of een controle aanscherpen.
• Controleer bij bevindingen die context nodig hebben het ontbrekende stuk: is er middleware, een beleid op rijniveau of een configuratie die het al voorkomt? Schrijf het antwoord op.
• Plan hoge bevindingen in de huidige sprint, gemiddelde in de backlog, en bundel lage en info-items in een hardeningronde.
• Is een bevinding niet echt, leg dan vast waarom. Die notitie bespaart de volgende persoon een nieuw onderzoek.

Wijs elke bevinding aan één eigenaar toe. Bevindingen die van het hele team zijn, blijken meestal van niemand te zijn.

Het bevindingenoverzicht en exports

Zodra je meerdere audits hebt, werkt het bevindingenoverzicht prettiger dan losse rapporten. Het toont bevindingen over audits heen en filtert ze op ernst, CWE en repository. Filteren op CWE is bijzonder nuttig: komt dezelfde zwakte in drie repository’s voor, dan wijst dat meestal op een gedeeld patroon of een ontbrekende helper, en het patroon oplossen is goedkoper dan elk geval afzonderlijk.

Bevindingen kunnen vanuit het overzicht als CSV worden geëxporteerd, wat handig is om ze in een issuetracker of spreadsheet te importeren. Losse rapporten kunnen als Markdown worden geëxporteerd, wat goed leest in de beschrijving van een pull request, een interne wiki of een bericht aan een contractor die de fix uitvoert.

Heraudit om de fix te bevestigen

Een fix is pas af als je hem hebt gecontroleerd. Draai na het mergen een nieuwe audit op dezelfde repository. Elk rapport kan met de vorige audit worden vergeleken, zodat je ziet welke bevindingen weg zijn, welke blijven en of er iets nieuws is bijgekomen. De risicoscore hoort te dalen als echte problemen zijn opgelost; gebeurt dat niet, kijk dan in de vergelijking waarom.

Houd de vergelijking eerlijk. Was de eerste audit een gedeeltelijke snapshot en las de tweede andere bestanden, dan weerspiegelt het verschil ook de dekking en niet alleen de fixes. Audits gaan van je maandelijkse budget af, dus het loont meestal om meerdere fixes te bundelen voordat je opnieuw auditeert, in plaats van na elke commit opnieuw te draaien.

Wat een rapport niet afdekt

De grenzen kennen helpt je de gaten te vullen. Audits lezen je broncode; ze scannen dependencies niet op bekende kwetsbare versies, dus houd daarnaast een dependency-scanner draaien, zoals die in je packagemanager of in GitHub. Audits zien geen configuratie die bij het deployen wordt gezet, geen infrastructuur buiten de repository en geen overgeslagen bestanden. En zoals elke reviewer, mens of AI, kan de audit zich vergissen: bewijs en betrouwbaarheidsniveaus staan er juist zodat je het snel kunt controleren in plaats van het op vertrouwen aan te nemen.

Zo gebruikt wordt een rapport een korte, geprioriteerde lijst met wijzigingen, met bewijs erbij. Los de kritieke op, controleer de onzekere, auditeer opnieuw en kijk de score bewegen.