Betterleaks hemlighetsskanner jämfört med Gitleaks

Betterleaks hemlighetsskanner: arkitektur och nycklar

Detekteringen av hemligheter i repositories har förändrats avsevärt under senare år. Tidigare räckte det med att leta efter misstänkta strängar eller nycklar med hög entropi i koden. Idag är situationen annorlunda: större repositories, snabbare CI/CD-pipelines och framför allt en ökande mängd kod genererad av automatiserade verktyg eller AI-modeller.

Detta har en praktisk konsekvens: problemet är inte längre bara att hitta hemligheter, utan att skilja det som verkligt är farligt från det som bara verkar vara det. Många team upptäcker att den verkliga kostnaden för dessa skannrar inte ligger i att köra analysen, utan i att granska hundratals falska positiva resultat.

Detektionsarkitektur: vad som förändras med Betterleaks

Betterleaks dyker upp just i detta sammanhang. Det försöker inte helt återuppfinna hemlig skanning, men det utmanar ett utbrett antagande: att det räcker med att upptäcka mönster.

I många moderna arkiv är det inte.

Projektet, som utvecklats av Zach Rice och underhålls med stöd från Aikido, föreslår något något annorlunda. Istället för att enbart fokusera på att upptäcka matchningar försöker det validera om fyndet är logiskt innan det eskaleras som en varning.

Det här kan verka som en liten detalj, men det förändrar dynamiken i stora team avsevärt. När ett skanningssystem genererar för många irrelevanta varningar är teamets naturliga reaktion att ignorera dem. Och inom säkerhet kan en ignorerad varning vara värre än ingen varning alls.

För att åtgärda detta problem introducerar Betterleaks två intressanta tekniska delar: validering med hjälp av CEL (Common Expression Language) och ett mått som kallas "Token Efficiency", baserat på BPE-tokenisering.

Tanken är att inte allt som verkar vara en hemlighet faktiskt är det. Vissa strängar med hög entropi är helt enkelt hashkoder, identifierare eller automatiskt genererade fragment. Systemets mål är att minska det bruset.

Projektdokumentationen nämner en jämförelse där BPE-tokenisering uppnår en återkallningsfrekvens på 98,6 % jämfört med de 70,4 % som erhållits med entropi i CredData-datasetet. Precis som med alla riktmärken är dessa siffror vägledande. De fungerar bra som referenspunkt, men ersätter inte testning i riktiga databaser.

Komponenter som gör skillnaden

En granskning av projektets egenskaper visar en tydlig riktning: att underlätta driftsättning i verkliga miljöer utan att lägga till för mycket teknisk komplexitet.

Bland de mest framträdande elementen är:

• Regeldefinierad validering med CEL (Common Expression Language)
• Tokeneffektivitetsskanning baserad på BPE-tokenisering snarare än entropi, vilket uppnår 98,6 % återkallelse jämfört med 70,4 % med entropi på CredData-datasetet.
• Pure Go-implementering (inget CGO- eller Hyperscan-beroende)
• Automatisk hantering av dubbelt/trippelt kodade hemligheter
• Utökad regeluppsättning för fler leverantörer
• Parallelliserad Git-skanning för snabbare databasanalys

Även om den här listan kan verka som bara en uppsättning tekniska förbättringar, är det intressanta hur de påverkar den dagliga användningen.

Till exempel förenklar en fullständig Go-implementering utan nativa beroenden integrationen i CI/CD-pipelines avsevärt. I många team avgör små detaljer som det om ett verktyg används eller glöms bort i ett repository.

BPE-tokenisering introducerar också en annan metod. Istället för att bara mäta slumpmässigheten i en kedja analyserar den tokenmönster som bättre återspeglar hur moderna autentiseringsuppgifter faktiskt är strukturerade.

Vad händer när skannern hittar något?

När Betterleaks upptäcker en potentiell hemlighet slutar processen inte där.

Först utvärderas kontexten med hjälp av regler definierade i CEL. Detta möjliggör tillägg av ytterligare villkor: till exempel kontroll av om formatet matchar den förväntade leverantören eller att ignorera mönster som ofta förekommer i exempel eller fiktiva data.

Det här steget kan verka trivialt, men det har en betydande praktisk inverkan. Falska positiva resultat slösar inte bara bort tid utan minskar också teamets förtroende för varningssystemet.

En annan intressant aspekt är den automatiska hanteringen av hemligheter som kodats flera gånger. I vissa databaser verkar inloggningsuppgifterna transformerade med base64 eller andra kodningsscheman, vilket komplicerar deras detektering.

Ändå är det värt att komma ihåg något som ibland förbises: ingen skanner kan helt ersätta mänsklig granskning. Att upptäcka en hemlighet är bara början; att bestämma vad man ska göra med den (återkalla, rotera, ignorera eller utreda) förblir ett kontextuellt beslut.

Styrning och människocentrerat tillvägagångssätt/AI

Betterleaks publiceras under MIT-licensen och innehåller externa bidrag från organisationer som Royal Bank of Canada, Red Hat och Amazon.

Projektet försöker också anpassa sig till en verklighet som blir alltmer synlig i moderna databaser: blandningen av kod skriven av utvecklare och kod genererad av automatiserade verktyg.

I detta sammanhang syftar verktyget till att fungera väl i både mänskligt styrda arbetsflöden och automatiserade system som granskar hela arkiv. Detta överensstämmer med den växande användningen av automatisering och verktyg som analyserar kod eller genererar automatiska granskningar.

Färdplanen innehåller även intressanta idéer: integration med datakällor bortom GitSpråkmodellhjälp för klassificering av fynd och automatiska återkallningsmekanismer via leverantörs-API:er.

Detta öppnar upp för en intressant debatt. Att automatisera återkallelse av autentiseringsuppgifter kan minska tiden det tar att reagera på en incident, men det innebär också att man måste förlita sig på att klassificeringssystemet är korrekt.

Om en automatisk återkallelse misslyckas eller utlöses av misstag kan den operativa påverkan bli betydande.

Praktiska konsekvenser och begränsningar

Ur ett operativt perspektiv är Betterleaks attraktivt för team som vill minska falska positiva resultat och förenkla implementeringar.

Men det är också viktigt att ha vissa begränsningar i åtanke:

• Återkallelsesmått beror på vilken datauppsättning som används och kan variera avsevärt mellan databaser.
• Att automatisera åtgärder som att återkalla nyckel kräver ytterligare kontroller och granskningsloggar.
• Hemliga skannrar är bara ett försvarslager inom en bredare strategi.

I många fall beror beslutet att använda ett sådant verktyg inte så mycket på dess teoretiska noggrannhet som på något enklare: om det integreras väl i teamets arbetsflöde.

En mycket noggrann skanner som genererar för mycket friktion överges vanligtvis. En någorlunda noggrann som är lätt att integrera behålls vanligtvis.

I den meningen försöker Betterleaks hitta en balans. Det lovar inte att eliminera alla falska positiva resultat eller ersätta befintliga säkerhetsprocesser, men det syftar till att minska brus och underlätta integration i moderna pipelines.

Projektet finns tillgängligt på GitHub och presenteras som en utveckling av den metod som används av Gitleaks, med avsikten att anpassa sig till repositories där automatisering, analysagenter och kod genererad av språkmodeller är en regelbunden del av utvecklingsflödet.