Betterleaks geheimenscanner: architectuur en sleutels
Het opsporen van geheimen in repositories is de afgelopen jaren aanzienlijk veranderd. Voorheen was het voldoende om te zoeken naar verdachte tekenreeksen of sleutels met een hoge entropie in de code. Tegenwoordig is de situatie anders: grotere repositories, snellere CI/CD-pipelines en, bovenal, een toenemende hoeveelheid code die wordt gegenereerd door geautomatiseerde tools of AI-modellen.
Dit heeft een praktisch gevolg: het probleem is niet langer alleen het vinden van geheimen, maar het onderscheiden van wat werkelijk gevaarlijk is van wat slechts gevaarlijk lijkt. Veel teams ontdekken dat de werkelijke kosten van deze scanners niet zozeer in de analyse zelf zitten, maar in het beoordelen van honderden valse positieven.
Detectiearchitectuur: wat verandert er met Betterleaks?
Betterleaks verschijnt precies in deze context. Het probeert niet om het scannen van geheimen volledig opnieuw uit te vinden, maar het daagt wel een wijdverbreide aanname uit: dat het detecteren van patronen voldoende is.
In veel moderne archieven is dat niet het geval.
Het project, ontwikkeld door Zach Rice en onderhouden met steun van Aikido, stelt iets anders voor. In plaats van zich uitsluitend te richten op het detecteren van overeenkomsten, probeert het te valideren of de bevinding logisch is voordat deze als waarschuwing wordt doorgegeven.
Dit lijkt misschien een klein detail, maar het verandert de dynamiek in grote teams aanzienlijk. Wanneer een scansysteem te veel irrelevante waarschuwingen genereert, is de natuurlijke reactie van het team om ze te negeren. En in de beveiliging kan een genegeerde waarschuwing erger zijn dan helemaal geen waarschuwing.
Om dit probleem aan te pakken, introduceert Betterleaks twee interessante technische onderdelen: validatie met behulp van CEL (Common Expression Language) en een meeteenheid genaamd "Token Efficiency", gebaseerd op BPE-tokenisatie.
Het idee is dat niet alles wat geheim lijkt te zijn, dat ook daadwerkelijk is. Sommige strings met een hoge entropie zijn simpelweg hashes, identificatoren of automatisch gegenereerde fragmenten. Het doel van het systeem is om die ruis te verminderen.
In de projectdocumentatie wordt een vergelijking genoemd waarbij BPE-tokenisatie een recall-percentage van 98,6% behaalt, vergeleken met de 70,4% die met entropie in de CredData-dataset wordt verkregen. Zoals bij elke benchmark zijn deze cijfers indicatief. Ze dienen goed als referentiepunt, maar vervangen geen testen in echte repositories.
Bron: GitHub
Onderdelen die het verschil maken
Bij het bekijken van de projectkenmerken komt een duidelijke richting naar voren: de implementatie in praktijksituaties vergemakkelijken zonder al te veel technische complexiteit toe te voegen.
Tot de meest prominente elementen behoren:
- Regelgebaseerde validatie met behulp van CEL (Common Expression Language)
- Token Efficiency Scanning, gebaseerd op BPE-tokenisatie in plaats van entropie, behaalde een recall van 98,6% versus 70,4% met entropie op de CredData-dataset.
- Pure Go-implementatie (geen afhankelijkheid van CGO of Hyperscan)
- Automatische verwerking van dubbel/drievoudig gecodeerde geheimen
- Uitgebreidere regels voor meer aanbieders
- Parallelle Git-scanning voor snellere repository-analyse
Hoewel deze lijst op het eerste gezicht slechts een opsomming van technische verbeteringen lijkt, is het interessant om te zien hoe ze het dagelijks gebruik beïnvloeden.
Een volledige Go-implementatie zonder native afhankelijkheden vereenvoudigt bijvoorbeeld de integratie in CI/CD-pipelines aanzienlijk. In veel teams bepalen dit soort kleine details of een tool uiteindelijk wel of niet gebruikt wordt in een repository.
BPE-tokenisatie introduceert ook een andere aanpak. In plaats van simpelweg de willekeurigheid van een keten te meten, analyseert het tokenpatronen die beter weergeven hoe moderne referenties daadwerkelijk zijn opgebouwd.
Wat gebeurt er als de scanner iets detecteert?
Als Betterleaks een potentieel geheim detecteert, is het proces daarmee nog niet afgerond.
Eerst wordt de context geëvalueerd aan de hand van regels die zijn gedefinieerd in CEL. Dit maakt het mogelijk om extra voorwaarden toe te voegen: bijvoorbeeld controleren of het formaat overeenkomt met de verwachte provider of patronen negeren die vaak voorkomen in voorbeelden of fictieve gegevens.
Deze stap lijkt misschien onbelangrijk, maar heeft een aanzienlijke praktische impact. Valse meldingen kosten niet alleen tijd, maar verminderen ook het vertrouwen van het team in het waarschuwingssysteem.
Een ander interessant aspect is de automatische verwerking van geheimen die meerdere malen gecodeerd zijn. In sommige repositories lijken inloggegevens getransformeerd te zijn met behulp van base64 of andere coderingsschema's, wat de detectie ervan bemoeilijkt.
Toch is het goed om iets te onthouden dat soms over het hoofd wordt gezien: geen enkele scanner kan menselijke controle volledig vervangen. Het detecteren van een geheim is slechts het begin; de beslissing wat ermee te doen (intrekken, rouleren, negeren of onderzoeken) blijft een contextuele afweging.
Bestuur en mensgerichte aanpak/AI
Betterleaks wordt gepubliceerd onder de MIT-licentie en bevat bijdragen van externe organisaties zoals Royal Bank of Canada, Red Hat en Amazon.
Het project probeert zich ook aan te passen aan een realiteit die steeds vaker voorkomt in moderne repositories: de mix van code geschreven door ontwikkelaars en code gegenereerd door geautomatiseerde tools.
In deze context is het de bedoeling dat de tool goed functioneert in zowel door mensen uitgevoerde workflows als geautomatiseerde systemen die complete repositories doorzoeken. Dit sluit aan bij het toenemende gebruik van automatisering en tools die code analyseren of automatische reviews genereren.
De routekaart bevat ook interessante ideeën: integratie met gegevensbronnen buiten GitTaalmodelondersteuning voor het classificeren van bevindingen en automatische intrekkingsmechanismen via API's van aanbieders.
Dit leidt tot een interessante discussie. Het automatiseren van het intrekken van inloggegevens kan de reactietijd bij een incident verkorten, maar het betekent ook dat men afhankelijk is van de nauwkeurigheid van het classificatiesysteem.
Als een automatische intrekking mislukt of per ongeluk wordt geactiveerd, kunnen de operationele gevolgen aanzienlijk zijn.
Praktische implicaties en beperkingen
Vanuit operationeel oogpunt is Betterleaks aantrekkelijk voor teams die het aantal valse positieven willen verminderen en implementaties willen vereenvoudigen.
Maar het is ook belangrijk om bepaalde grenzen in gedachten te houden:
- De recall-statistieken zijn afhankelijk van de gebruikte dataset en kunnen aanzienlijk verschillen tussen repositories.
- Het automatiseren van acties zoals het intrekken van sleutels vereist extra controles en auditlogboeken.
- Geheime scanners vormen slechts één verdedigingslinie binnen een bredere strategie.
In veel gevallen hangt de beslissing om zo'n tool te gebruiken niet zozeer af van de theoretische juistheid ervan, maar van iets eenvoudigers: of het goed integreert in de workflow van het team.
Een zeer nauwkeurige scanner die te veel wrijving veroorzaakt, wordt meestal afgedankt. Een redelijk nauwkeurige scanner die gemakkelijk te integreren is, wordt meestal behouden.
In die zin probeert Betterleaks een evenwicht te vinden. Het belooft niet alle valse positieven te elimineren of bestaande beveiligingsprocessen te vervangen, maar het streeft er wel naar om ruis te verminderen en integratie in moderne pipelines te vergemakkelijken.
Het project is beschikbaar op GitHub. Het wordt gepresenteerd als een evolutie van de aanpak die door Gitleaks wordt gebruikt, met de bedoeling zich aan te passen aan repositories waar automatisering, analyseagents en code gegenereerd door taalmodellen een vast onderdeel vormen van het ontwikkelingsproces.
