Onze miskleun: hoe een publieke GitHub-issue bijna een productiewachtwoord lekte

Soms leer je het meest van je eigen fouten. Deze keer stond die les gewoon publiek op GitHub: issue #5499 in de repository van Claude Code, aangemaakt door een AI-agent tijdens het oplossen van een Traefik-configuratieprobleem op ons platform.

Wat er gebeurde

De agent werkte aan een storing in een Traefik HA-cluster: het dashboard op traefik.hasecon.cloud gaf een 401 Unauthorized, terwijl toegang via het interne VIP-adres wel werkte. De oorzaak bleek een verkeerde bcrypt-hash in de vault. De agent loste dit netjes op — nieuwe hash, IP-ACL via een ipAllowList middleware, een correcte middleware-chain van IP-filtering naar basic auth, en Cloudflare als certificaatresolver voor SSL.

Het probleem zat niet in de fix. Het probleem was de samenvatting die de agent achterliet in de publieke issue: het admin-wachtwoord van het dashboard stond er in platte tekst bij, leesbaar voor iedereen met een GitHub-account. Een medewerker van Anthropic sloot de issue met een droge “closing as this doesn’t seem to be an issue in Claude Code” — terecht, want het was geen bug in het product. Het was een operationeel lek, veroorzaakt door het ontbreken van duidelijke grenzen voor de agent.

Waarom dit kon gebeuren

We hadden op dat moment geen CLAUDE.md die expliciet vastlegde dat vault-waarden, wachtwoorden en tokens nooit in output, commits of issues terecht mogen komen — ook niet als “bewijs dat de fix werkt”. Een agent die geen instructie krijgt om secrets te maskeren, behandelt een wachtwoord als zomaar een stuk tekst dat nuttig is voor de leesbaarheid van een rapport. Precies dat gebeurde hier.

Wat ons redde

Ondanks het gelekte wachtwoord is het dashboard niet vanaf het publieke internet benaderbaar geweest. De ipAllowList middleware die de agent zelf had ingericht, liet alleen verkeer vanaf toegestane bronadressen door. Met andere woorden: de credential was gecompromitteerd, maar de netwerklaag stopte het misbruik. Defense in depth deed precies waarvoor het bedoeld is — een enkele gefaalde laag (het wachtwoord) leidde niet tot een volledige inbreuk, omdat er een tweede, onafhankelijke laag stond.

Dat is geen vrijbrief om achterover te leunen: elke credential die ooit publiek zichtbaar is geweest, moet als gecompromitteerd worden behandeld en direct geroteerd, ongeacht welke andere controles er nog staan.

Lessen voor wie AI-agents op productie loslaat

Een goede CLAUDE.md (of vergelijkbare systeeminstructie) moet expliciet regelen welke repositories en systemen een agent mag benaderen, en dat secrets, hashes en tokens nooit in output, logs, commits of issues verschijnen — ook niet ter documentatie. Behandel de credentials van een agent zelf ook als bevoorrecht: least privilege, scoped toegang, en een mens die meekijkt bij alles wat productie raakt.

Minstens zo belangrijk is secret-scanning in de CI/CD-pipeline, ook op de inhoud van issues en pull requests, niet alleen op code. En bouw niet op één verdedigingslaag: een wachtwoord alleen is geen beveiliging. Netwerksegmentatie, IP-allowlisting en MFA vangen op wat een gelekte credential niet meer tegenhoudt.

Wij nemen dit soort incidenten mee in hoe we CLAUDE.md-configuraties en agent-governance inrichten bij klanten die AI-tooling combineren met productiesystemen. Loopt u tegen vergelijkbare vraagstukken aan, neem gerust contact op.


You May Also Like These Topics...

Adding Hosts, IP Ranges and URLs to OpenKAT via the API

Does OpenKAT have an API to add new (sub)domains or IP ranges? Yes, through the Octopoes declarations API. A practical, tested guide with working curl examples, the two-step declaration plus scan profile pattern, bulk options, and where Rocky’s own API fits in.

De echte OpenKAT herkennen: officiële bronnen en hoe u namaak vermijdt

Hoe herkent u de officiële OpenKAT en vermijdt u misleidende namaaksites? De echte bronnen, een verificatie-checklist en de belangrijkste waarschuwingssignalen op een rij.

cyberbeveiligingswet aangenomen

Cyberbeveiligingswet aangenomen: wat bestuurders nu écht moeten regelen

Op 15 april 2026 stemde de Tweede Kamer in met de Cyberbeveiligingswet (Cbw) en de Wet weerbaarheid kritieke entiteiten (Wwke). De streefdate voor inwerkingtreding: tweede kwartaal 2026. Voor bestuurders betekent dat: minder dan een kwartaal om zorgplicht, meldplicht, registratieplicht én een opleidingsplicht op orde te hebben, met persoonlijke aansprakelijkheid als stok achter de deur. In dit artikel zetten we op een rij wat er écht verandert en hoe u met OpenKAT een groot deel van de technische zorgplicht aantoonbaar kunt afdekken.

Elastic SIEM Optimalisatie voor Moderne Beveiliging

Elastic SIEM bundelt het verzamelen, analyseren en beheren van beveiligingsdata in één platform. Wie zijn logdata al in Elasticsearch heeft, zet er zonder extra tooling realtime detectie en analyse bovenop. Voor veel organisaties is dat de praktischste route naar serieuze beveiligingsmonitoring. De Fundamenten van Elastic SIEM Elastic SIEM bestaat uit vier componenten met elk een […]

 
Next Post
Kantoorgebouw met digitaal beveiligingsschild en aflopende klok, symbool voor de NIS2 Cyberbeveiligingswet die op 15 augustus 2026 ingaat
Continuous Scanning & Monitoring Regelgeving & Compliance

NIS2 Komt Eraan: Bent U Voorbereid? Een Praktische Gids

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *