AI-gegenereerde infrastructuurcode reviewen: waar je écht naar moet kijken

Applicatiecode die fout is, gaat meestal stuk. Infrastructuurcode die fout is, werkt.

Dat is het hele probleem in één zin. Vraag je een AI-agent om een bucket, een database en de rechten ertussen, dan krijg je iets terug dat plan haalt, dat apply haalt en dat vervolgens netjes draait. Alles groen. En of het veilig is, zie je nergens aan. Wij reviewen dit soort code regelmatig. Dit is waar we naar kijken, in de volgorde waarin het misgaat.

Even eerlijk zijn over wat er wél werkt, want dat bepaalt waar je je aandacht níét aan moet verspillen. Agents zijn sterk in de vorm: correcte syntax, redelijke modulestructuur, consistente naamgeving, providerversies die kloppen, resources die netjes aan elkaar gekoppeld zijn. Ook het saaie werk (variabelen, outputs, tags) komt er doorgaans beter uit dan wanneer een mens het onder tijdsdruk typt.

Daar hoef je dus niet je reviewtijd aan te besteden. Die besteed je aan de dingen waar een model geen zicht op heeft: wat er in jouw organisatie al bestaat, en wat er gebeurt als iemand dit misbruikt. Dit is waar het bijna altijd misgaat, en het is zelden zichtbaar. Een agent wil dat je code werkt. De snelste route naar werkende code is ruimere rechten. Dus krijg je een rol die net iets meer mag dan nodig, met een wildcard waar een lijstje had gemoeten, en het werkt. En omdat het werkt, kijkt niemand er nog naar.

Waar we specifiek naar kijken:

• Wildcards in acties of resources. s3:* of Resource: "*" is bijna nooit wat je bedoelde. Vraag welke drie acties er echt nodig zijn.
• Rollen die door meerdere services gedeeld worden. Handig bij het opzetten, en meteen een breed aanvalsoppervlak zodra er één ding misgaat.
• Rechten die impliciet zijn overgenomen. Erft de nieuwe rol van iets bestaands? Dan is de vraag niet wat er in de diff staat, maar wat die parent allemaal mag.
• Langlevende credentials. Als er een access key wordt aangemaakt in plaats van een rol met kortlevende tokens, is dat een bewuste keuze die iemand moet nemen, niet iets wat een agent voor je invult.

Hetzelfde patroon, andere laag. 0.0.0.0/0 is de snelste weg naar “het werkt”, en het is bijna nooit het antwoord. Let vooral op security groups die inkomend verkeer op een beheerpoort toestaan, op regels die verwijzen naar een CIDR-blok in plaats van naar een andere security group, en op resources die per ongeluk een publiek IP krijgen omdat dat in de meeste voorbeelden op internet zo staat.

Dat laatste is een terugkerend thema: een model is getraind op publieke voorbeelden, en publieke voorbeelden zijn geschreven om te demonstreren, niet om in productie te draaien.

Drie dingen die we standaard controleren omdat ze stilletjes fout gaan:

• Waar staat de state, en wie kan erbij? Terraform state bevat vaak gevoelige waarden in platte tekst. Een backend zonder encryptie of met te ruime toegang is een lek dat nergens als lek voelt.
• Staan er secrets in variabelen met een default? Een default = "changeme" haalt het opvallend vaak tot productie.
• Wordt er iets gelogd wat je niet wilt loggen? Debug-output op een resource die credentials bevat, is een klassieker.

Dit is het lastigste deel van zo’n review, en het deel dat het meeste oplevert. Een agent ziet wat je hem geeft. Hij ziet niet je bestaande landing zone, je naamgevingsafspraken, de policy die je vorig jaar hebt ingevoerd of het feit dat er al een vergelijkbare resource bestaat die je had kunnen hergebruiken.

Dus vraag bij elke wijziging: bestaat dit al ergens? Past het in de structuur die we hebben? Doorbreekt het een grens die we bewust hebben getrokken? Die vragen kun je niet aan het model stellen, want het antwoord staat niet in de context die het gekregen heeft.

Wat wij aanhouden, in deze volgorde:

1. Draai plan en lees hem, niet de code. De code beschrijft de bedoeling; het plan beschrijft wat er werkelijk gaat gebeuren. Let op alles wat vervangen of vernietigd wordt.
2. Zoek op wildcards. Letterlijk grepen op * in policies. Elke treffer moet verantwoord worden.
3. Loop de netwerkregels na op 0.0.0.0/0 en op poorten die niet publiek horen te zijn.
4. Controleer je state-backend en encryptie.
5. Vraag wat er al bestaat. Dit is de stap die een tool niet voor je doet.
6. Laat automatische scanners het herhaalbare werk doen. tfsec, checkov of de policy-tooling van je provider vangen het bekende patroon, zodat jouw aandacht naar de context kan.

Die laatste combinatie is de kern: laat de machine controleren wat zich laat controleren, en zet je mensen op wat alleen mensen weten. Naarmate er meer code binnenkomt, wordt dat onderscheid het verschil tussen snelheid en risico. AI-gegenereerde infrastructuurcode is doorgaans goed geschreven en regelmatig te ruim bemeten. De fouten zitten niet in de syntax maar in de rechten, de netwerkgrenzen en in alles wat het model niet kon weten over jouw omgeving. Ze breken niets, ze werken juist, en daarom komen ze door de review heen.

Mijn advies is daarom simpel: laat de scanner de syntax doen en zet je eigen reviewtijd op IAM, het netwerk en de vraag of dit hier eigenlijk wel hoort. Wie het andersom doet, keurt straks tienduizend regels goed die allemaal werken. Hoe je die grenzen vooraf in je cloudomgeving vastlegt, zodat een agent er niet overheen kan, is precies het werk van onze cloud-consultancy.