GitHub: 86 pct. kortere scanning, push protection i preview

GitHubs tekniske gennemgang fra 13. oktober 2026 opgør 86 pct. kortere medianudførelsestid ved scanning efter push, 11,5 pct. højere ejer-vægtet accept af alarmer og over 98 pct. lavere omkostninger ved at køre den nye klassifikator sammenlignet med den tidligere LLM-pipeline. Hastigheden gør det også praktisk at vurdere generiske hemmeligheder, før et push accepteres. Tallet for scanningstid er målt efter push; det er ikke en måling af, hvor hurtigt et push bliver godkendt.

Udrulningen har to forskellige statusser: GitHubs produktmeddelelse oplyser, at kunder med AI-detekterede Password-alarmer automatisk er flyttet til modellen, mens AI-detektion i push protection er i privat forhåndsvisning. Hvor funktionen er tilgængelig og aktiveret, kan den standse en mistænkelig ændring, før den kommer ind i repositoryets historik. Den nye model i efterfølgende scanning betyder derfor ikke, at alle repositories allerede har AI-baseret blokering ved push.

Regex finder kandidaterne, ModernBERT bedømmer konteksten

Scanneren deler arbejdet mellem mønstergenkendelse og klassifikation. Regex gennemgår kode og tekst for strenge, der kunne være tokens, nøgler eller adgangskoder. En finjusteret ModernBERT-model vurderer derefter kandidaterne sammen med deres filsti, type, variabelnavne og omgivende kode. Kandidater med høj sandsynlighed for at være reelle hemmeligheder går videre som fund, mens sandsynlige efterligninger sorteres fra.

Det er især relevant for generiske adgangsoplysninger uden et karakteristisk præfiks eller et fast tokenformat. En adgangskodelignende værdi ved en produktionsdatabase kan ligne en testværdi, når man kun ser på tegnene. Placeringen i filen og teksten omkring værdien kan ændre vurderingen. Det samme gælder forbindelsesstrenge i en konfigurationsfil over for eksempler i en vejledning samt lange strenge, der i virkeligheden er kontrolsummer eller build-id'er.

Regex-trinnet skal stadig udpege en streng som kandidat, før modellen kan bedømme den. En værdi, som falder uden for kandidatmønstrene, når ikke frem til ModernBERT. Den kompakte model er til gengæld trænet til den snævre beslutning, som følger: om en udpeget streng ligner en brugbar hemmelighed i sin konkrete sammenhæng. Træningsmaterialet omfatter fund fra repositories, menneskeligt vurderede kandidater og konstruerede eksempler på vanskelige grænsetilfælde som pladsholdere og testfixtures.

Præcision, recall og accepterede alarmer måler forskellige ting

Blockchain.News' samtidige omtale beskriver en evaluering på den samme offentlige trafik, hvor den samlede nye pipeline opnåede 13 pct. højere præcision og 19 pct. højere recall ved scanning efter push end den tidligere LLM-pipeline. Præcision angiver, hvor stor en andel af udpegede fund der faktisk er hemmeligheder. Recall angiver, hvor stor en andel af de reelle hemmeligheder scanneren finder. Resultaterne gælder kombinationen af kandidatfinding og klassifikation, ikke ModernBERT vurderet alene.

Højere præcision betyder færre harmløse værdier blandt de fund, som nogen skal behandle. Højere recall betyder færre oversete hemmeligheder i den evaluerede trafik. Begge mål er nødvendige: En scanner kan få færre falske alarmer ved at være mere tilbageholdende, men den gevinst er ringe, hvis den samtidig overser flere brugbare nøgler. Den rapporterede forbedring på begge mål peger på, at filtreringen i denne evaluering ikke blot flyttede støjen over i oversete fund.

Accept af alarmer er et andet mål. Det viser, om repositoryejere i praksis accepterer de fund, de får præsenteret, og er vægtet efter ejer, så behandling af store mængder alarmer hos én kunde ikke dominerer gennemsnittet. Et fund kan stadig kræve undersøgelse, selv når mønstret og modellen er enige. De relative forbedringer fortæller heller ikke, hvor mange alarmer eller oversete hemmeligheder et bestemt repository havde før og efter ændringen.

Blokering før push kræver adgang og aktivering

Forskellen mellem de to kontrolpunkter er tidspunktet for indgrebet. Push protection vurderer ændringen, inden GitHub accepterer den i repositoryets historik, så udvikleren kan fjerne en fundet hemmelighed. Scanning efter push gennemgår kode, der allerede er modtaget, og opretter en alarm til videre behandling. En hurtigere klassifikator gør den første kontrol mulig for flere generiske hemmeligheder, men giver ikke automatisk alle teams den nye push-kontrol.

Den private forhåndsvisning retter sig mod GitHub Team og GitHub Enterprise Cloud med betalt dækning gennem GitHub Secret Protection eller GitHub Advanced Security. En administrator skal aktivere funktionen inden for organisationens politikker; både offentlige, private og interne repositories kan være kvalificerede. Eksisterende AI-detekterede alarmer efter push er derimod inkluderet for berettigede kunder uden særskilt tilmelding til den nye push-kontrol.

Der er også forskel på GitHubs driftsomkostning og kundens betaling. Besparelsen ved at køre klassifikatoren sammenligner tekniske pipelines og lover ingen tilsvarende lavere regning. For de nye tilvalgte kontroller er GitHub AI Credits varslet som betalingsmodel, mens eksisterende AI-detekterede alarmer fortsat er inkluderet i Secret Protection eller Advanced Security. En kontrol kan bruge credits, selv hvis den ikke ender med at blokere et push.

Hvilke ændringer mærker et team i egne repositories?

De offentliggjorte målinger afgør ikke, hvilke af et teams egne tokenformater der bliver fanget før push. Den konkrete dækning afhænger både af, om kontrollen er slået til, og om en mulig hemmelighed overhovedet bliver udpeget som kandidat. En lokal gennemgang kan derfor skelne mellem bedre klassifikation af fund, der allerede ligner en hemmelighed, og bredere dækning af de værdier, teamet faktisk bruger.

Kontrollér for hvert relevant repository, om licensdækningen er på plads, om AI-baseret push protection er tilgængelig for organisationen, og om en administrator har aktiveret den.
Brug ugyldige testværdier til både genkendelige tokenformater og generiske, adgangskodelignende strenge i de filtyper, teamet anvender. Registrér særskilt en blokering ved push og en alarm efter push.
Medtag harmløse pladsholdere og testfixtures, som tidligere har udløst alarmer. Undersøg samtidig, om relevante kandidater forsvinder, når støjen falder.
Følg, hvilke alarmer repositoryejerne accepterer eller afviser, og afklar organisationens politik for tilvalg og AI Credits, før kontrollen udbredes.

Hvis en brugbar nøgle alligevel når ind i historikken, er en senere alarm stadig vigtig: sletning af committen fjerner ikke nødvendigvis risikoen for misbrug. For teams i forhåndsvisningen bliver den afgørende forskel, hvilke af deres egne generiske hemmeligheder kontrollen standser, før ændringen accepteres.

Læs også: