Secrets Management in 2026: Sprawl, Non-Human Identities en de Keuze tussen Vault en Workload Identity

Elke engineering-organisatie heeft een secrets-managementbeleid op papier. De meeste verliezen er toch terrein mee. GitGuardian's vijfde jaarlijkse scan van publieke GitHub-repositories vond 28,6 miljoen nieuwe gelekte secrets in 2025, een stijging van 34% ten opzichte van het jaar ervoor - en dat is alleen wat publiekelijk uitlekte, niet wat verkeerd geconfigureerd blijft staan in private repos, CI-logs en containerlagen (GitGuardian, State of Secrets Sprawl 2026). Voor engineering directors bij gereguleerde Benelux-organisaties is de vraag niet langer "hebben we een secrets-scanner" - het is of de architectuur nog steunt op langlevende statische secrets, of dat ze zijn overgestapt op iets dat niet op dezelfde manier kan lekken.

Een serverrack in een datacenter met bekabeling en netwerkswitches - het soort infrastructuur waar API-sleutels, tokens en credentials leven en, bij een lek, worden misbruikt. — Foto: Tony Webster, CC BY 2.0, via Wikimedia Commons

Waarom groeit secrets sprawl nog steeds?

Het voor de hand liggende antwoord is "meer repositories, meer code" - maar de scherpere oorzaak is dat AI-ondersteunde ontwikkeling verandert hoe snel credentials worden vastgelegd. Het 2026-rapport van GitGuardian zag AI-service-secrets - API-sleutels voor Copilot, Claude en vergelijkbare tools - met 81% groeien op jaarbasis naar 1,27 miljoen blootgestelde sleutels, en constateerde dat commits die mede door AI-assistenten zijn geschreven ongeveer twee keer zo vaak secrets lekken als gewone commits (GitGuardian, 2026). Het mechanisme is geen raadsel: een assistent bouwt snel een werkende integratie, een developer plakt een echte sleutel erin om te testen, en de commit gaat de deur uit voordat iemand eraan denkt om hem naar een vault te verplaatsen. Volume aan wijzigingen is altijd al de vijand van credential-hygiëne geweest; AI heeft alleen het volume opgevoerd zonder de discipline gelijke tred te laten houden.

Hoe lang blijven gelekte secrets daadwerkelijk gevaarlijk?

Langer dan de meeste incident-responseplannen aannemen. Van de secrets die GitGuardian voor het eerst detecteerde in 2022, was 64% vier jaar later nog steeds geldig en bruikbaar (GitGuardian, 2026). Die statistiek is het echte argument tegen statische, langlevende credentials: een lek is geen momentopname met een begrensde impact, het is een openstaande deur die openblijft totdat iemand er actief naar zoekt en hem sluit - wat bij de meeste organisaties nooit volledig gebeurt, omdat niemand de inventaris bezit van wat er al buiten ligt. Dit is ook waarom "we scannen op secrets in CI" nodig maar niet voldoende is. Scannen vangt nieuwe lekken vanaf nu; het doet niets voor de jaren aan geschiedenis die al in git-logs, Slack-exports en oude containerimages staan.

Welke rol spelen gestolen credentials echt bij datalekken?

Een grote, en een tamelijk stabiele. Verizon's 2025 Data Breach Investigations Report vond dat gecompromitteerde credentials het initiële toegangsvector waren bij 22% van de onderzochte datalekken - een van de belangrijkste toegangswegen, naast het misbruiken van kwetsbaarheden en phishing (Verizon, 2025 DBIR-onderzoek). Dat cijfer omvat zowel menselijke logins als gestolen API/service-credentials, en dat is relevant om een simpele reden: de meeste organisaties investeren zwaar in het beschermen van menselijke wachtwoorden (MFA, SSO, conditionele toegang), terwijl machine-credentials - de API-sleutels, database-connectiestrings en service-tokens die in elke moderne cloudomgeving ruimschoots de menselijke accounts in aantal overtreffen - als bijzaak worden behandeld. OWASP's Non-Human Identities-project maakt hetzelfde punt structureel: in de top-10-lijst van 2025 krijgt secret leakage een classificatie van ernstige impact, precies omdat gelekte secrets "doorgaans credentials bevatten voor NHI's met hoge impact", met 31% van de NHI-gerelateerde incidenten herleid tot slecht secrets-beheer en 37% van de organisaties die secrets nog steeds opslaan in environment variables of hardcoded in applicatiecode (OWASP NHI Top 10, 2025).

Waar lekken credentials daadwerkelijk in de pipeline?

OWASP's CI/CD Top 10 benoemt dit specifiek als CICD-SEC-6, Insufficient Credential Hygiene, en somt de faalmodi op in een volgorde die bekend zal voorkomen voor iedereen die ooit een incident-retro heeft geleid: credentials die worden gecommit naar broncode en die blijven bestaan in de geschiedenis, ook na verwijdering; pipeline-credentials die veel breder zijn geschaald dan de job die ze gebruikt; build-time secrets die achterblijven in containerimage-lagen; secrets die "bewust of onbewust" naar console-output worden geprint; en credentials die jarenlang niet worden geroteerd, waardoor stilletjes uitbreidt wie en wat ze kan gebruiken (OWASP Top 10 CI/CD Security Risks, CICD-SEC-6). Elk van deze is een procesgat, geen tooling-gat - precies waarom het kopen van een secret-scanner zonder de onderliggende architectuur te veranderen alleen het symptoom bestrijdt.

Vault-rotatie of workload identity: wat is het antwoord voor 2026?

Twee geloofwaardige architecturen strijden om het antwoord op "hoe moeten services elkaar authenticeren", en het eerlijke antwoord is dat de meeste gereguleerde organisaties beide nodig hebben, elk op de juiste plek toegepast.

Vault-rotatie - HashiCorp Vault of een cloud-native equivalent (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) centraliseert secret-opslag, versleutelt in rust, en kan dynamische, kortlevende credentials uitgeven in plaats van statische - een databasewachtwoord dat per sessie wordt aangemaakt in plaats van voor altijd gedeeld. Kubernetes-native tooling zoals External Secrets Operator synchroniseert die waarden volgens een schema naar cluster-secrets, zodat de credential in etcd nooit de langlevende bron van waarheid is. Dit is het juiste model overal waar een echt geheim moet bestaan - een API-sleutel van een derde partij, een legacysysteem dat alleen een wachtwoord accepteert.
Workload identity federation - in toenemende mate het voorkeursantwoord overal waar het beschikbaar is. In plaats van een statische credential te verspreiden, bewijst een workload wie hij is via een kortlevende, cryptografisch verifieerbare identiteit (OIDC-token, SPIFFE/SPIRE-identiteit, cloud-native workload identity) en wisselt die identiteit on demand in voor tijdelijke toegang. Er is geen staand geheim dat kan lekken, omdat de credential die normaal in een configbestand of environment variable zou staan nooit als statisch artefact bestaat. CI/CD-pipelines die via OIDC authenticeren bij cloudproviders in plaats van via langlevende access keys zijn het duidelijkste, inmiddels mainstream voorbeeld.

De keuzetest die audit-bestendig is: vraag voor elke credential in de omgeving of hij kan worden vervangen door een gefedereerde identity-exchange. Waar het antwoord ja is - CI/CD naar cloud, service naar service binnen een mesh, workload naar cloud secret store - stap over op workload identity en elimineer het staande geheim volledig. Waar het antwoord nee is - een SaaS-leverancier die alleen API-sleutels ondersteunt, een database die alleen wachtwoordauthenticatie doet - zet het in een vault, geef het dynamisch uit, roteer agressief, en beperk het tot minimale rechten. Wat niet zou moeten overleven tot in 2026 is de standaard die de OWASP- en GitGuardian-data beschrijven: een statisch, breed geschaald, zelden geroteerd geheim dat in een environment variable staat omdat niemand de keuze heroverwoog nadat het live ging.

Wat betekent dit voor gereguleerde Benelux-teams

Onder DORA, NIS2 en interne auditregimes die steeds vaker om bewijs vragen in plaats van beleidsverklaringen, is "we hebben een secrets-beleid" geen antwoord dat een auditor accepteert als de omgeving nog draait op ongeroteerde statische sleutels. De praktische checklist: inventariseer elk statisch geheim en zijn leeftijd; verschuif CI/CD naar OIDC-gebaseerde workload identity overal waar de provider dat ondersteunt; zet alles wat een statisch geheim moet blijven achter een vault met automatische rotatie en minimale rechten; en behandel "we hebben een gelekt geheim gevonden in een scan" als een intrekkingsgebeurtenis, niet als een ticket - want de GitGuardian-data zegt dat de credential die je vandaag niet roteert een reële kans heeft om over vier jaar nog steeds geldig, en bruikbaar, te zijn.