GitHub lar LLM-er rydde i secret-varslene

GitHub angriper støyen i sikkerhetsarbeidet

GitHub tar LLM-er inn i verifikasjonsleddet for secret scanning. Målet er ikke å finne flere mulige hemmeligheter. Målet er å gjøre varslene mer til å stole på. I en ny teknisk gjennomgang skriver GitHub at samarbeidet med Microsoft Security & AI’s Agents Offense-team har redusert falske positiver med 75,76 prosent i tester på hundrevis av kundebekreftede falske varsler. Målet var 65 prosent.

Det høres smalt ut. Det er det ikke. Secret scanning er en av de mest praktiske sikkerhetskontrollene i moderne utvikling. Den skal fange API-nøkler, tokens, passord og andre hemmeligheter før de blir til hendelser. Problemet er at store organisasjoner drukner i varsler. Når utviklere møter for mye støy, begynner de å behandle sikkerhetsvarsler som bakgrunnslyd. Da taper både sikkerhetsteamet og utviklerne.

GitHub beskriver dagens system som en kombinasjon av mønstergjenkjenning og AI-basert deteksjon. Kjente leverandørmønstre kan fange tokens og API-nøkler med tydelig format. Generisk AI-basert deteksjon kan finne mer ustrukturerte hemmeligheter, som passord som ikke følger et kjent mønster. Det øker dekningen, men gjør også presisjon vanskeligere. En tilfeldig UUID, en testverdi eller en opaque string kan se farlig ut uten å være det.

Det nye grepet ligger i verifikasjonen. Først genererer deteksjonsleddet kandidater. Deretter bruker GitHub LLM-basert kontekstuell vurdering for å skille reelle eksponeringer fra verdier som bare ligner på hemmeligheter. Ifølge GitHub skjer dette uten å endre den underliggende deteksjonslogikken eller redusere dekningen.

Bedre kontekst, ikke mer kode

Det interessante er hva GitHub ikke gjør. Selskapet skriver at løsningen ikke handler om å sende hele filer eller hele repositorier til modellen. Det ville gitt mer støy, høyere kostnad og mer latenstid. I stedet trekker systemet ut et lite sett med signaler som sier noe om hvordan verdien brukes.

Eksemplene er konkrete. Hvis en verdi blir satt i en variabel og senere sendt til en API-forespørsel, en autentiseringsheader, en databaseklient eller en cloud-SDK, er det et sterkere signal enn om den bare ligger ubrukt i en testfil. Mønstergjenkjenning kan si at noe ser ut som en secret. Brukskonteksten kan si om verdien faktisk fungerer som en secret.

Det er en moden bruk av LLM-er i sikkerhetsarbeid. Ikke en agent som får frie tøyler. Ikke en chatbot som forklarer et funn. Ikke et nytt dashboard med glansbilder. LLM-en får en avgrenset oppgave i en eksisterende pipeline: vurder en kandidat med bedre kontekst enn regex alene kan gi.

For CISO-er er dette et godt eksempel på hvor AI faktisk kan løfte sikkerhetsoperasjoner de neste 12 månedene. Ikke ved å erstatte kontrollene, men ved å forbedre signalkvaliteten i kontrollene som allerede finnes. Det er der mange sikkerhetsteam har mest å hente. Mindre støy betyr raskere triage, færre unødvendige avbrudd og mer tillit til de varslene som faktisk krever handling.

Praktisk betydning for utviklingsorganisasjoner

Dette treffer en øm nerve i DevSecOps. De fleste virksomheter har allerede for mange skannere. SCA, SAST, secret scanning, IaC-policy, container scanning og runtime-varsler kjemper om oppmerksomheten. Når alt roper, blir ingenting prioritert.

GitHubs tall er derfor mer interessante enn en vanlig produktlansering. En reduksjon på 75,76 prosent i falske positiver, dersom den holder i bred produksjon, endrer arbeidsflyten for utviklere og AppSec-team. Den gjør det lettere å kreve raskere respons på faktiske funn. Den gjør også sikkerhetsprogrammet lettere å forsvare internt, fordi færre mennesker må bruke tid på varsler som ikke betyr noe.

Det betyr ikke at LLM-verifikasjon skal stoles blindt på. Den må måles som alle andre sikkerhetskontroller: presisjon, recall, feilklassifisering, responstid, kostnad og sporbarhet. Den må også håndteres med dataminimering. GitHubs poeng om fokusert kontekst er derfor viktig. Sikkerhets-AI som krever at hele kodebasen sendes rundt, vil møte både kostnads-, personvern- og IP-spørsmål. Sikkerhets-AI som klarer seg med små, høysignalutdrag, har en langt bedre sjanse til å bli tatt i bruk.

For CIO og CTO er læringen enkel: AI i utviklingsplattformen bør vurderes som en del av kontrollmiljøet, ikke bare som produktivitet. De samme agent- og modellmekanismene som skriver kode, kan også styrke portvakter og kvalitetssikring. Men de må plasseres der de kan måles. En LLM som reduserer falske varsler i en kjent pipeline er lettere å styre enn en generell agent med uklare fullmakter.

Fra mer deteksjon til bedre signal

De siste årene har sikkerhetsmarkedet solgt mer deteksjon som løsning på nesten alt. Resultatet er ofte flere funn enn organisasjonen klarer å behandle. GitHubs grep peker i en annen retning: bedre signal. Det er mindre spektakulært, men mer verdifullt.

Hvis AI skal bli nyttig i sikkerhetsdrift, må den kutte friksjon uten å kutte kontroll. Secret scanning er et godt sted å starte fordi konsekvensene er konkrete. En ekte lekket nøkkel kan bli en hendelse. Et falskt varsel kan bli ti minutter tapt tid. I stor skala blir begge deler dyrt.

Neste spørsmål er om samme mønster kan flyttes til andre sikkerhetskontroller: sårbarhetsprioritering, IaC-policy, dependency-risiko og kodegjennomgang. Svaret er trolig ja, men bare hvis AI-en får riktig ramme. Den må jobbe i etablerte prosesser, bruke minst mulig relevant kontekst og levere målbare forbedringer. Der har GitHub nå vist en mer edruelig vei enn mye av agent-hypen.

Kilder og medier

Primærkilde: GitHub Blog, “Making secret scanning more trustworthy: Reducing false positives at scale”, 11. juni 2026. https://github.blog/security/making-secret-scanning-more-trustworthy-reducing-false-positives-at-scale/

Relatert produktdokumentasjon: GitHub Docs, Secret scanning. https://docs.github.com/en/code-security/secret-scanning

Thumbnail: OpenAI Image 2 / hogby.ai