API-nøkkelen som lå åpen i tre år (og de fire stedene dine ligger nå)

Fredagen

Historien er så vanlig at den nesten er kjedelig – helt til den ikke er det.

En utvikler tester en integrasjon lokalt, hardkoder API-nøkkelen «bare for å få det til å virke», og committer i farten. Feilen oppdages mandag. Nøkkelen fjernes, ny commit, alle puster ut.

Tre år senere gjør vi en sikkerhetsgjennomgang. Nøkkelen er fortsatt gyldig. Og den finnes på fire steder.

De fire stedene

1. Git-historikken. Det åpenbare stedet, som likevel overrasker: å slette nøkkelen i en ny commit fjerner den bare fra nå av. Historikken husker alt. Hver klone av repoet – på hver laptop, hver CI-runner, hver gammel backup – bærer nøkkelen med seg.

2. Forken. Repoet var blitt forket internt for et eksperiment året etter. Eksperimentet døde. Forken levde. Med hele historikken.

3. CI-loggene. En debug-utskrift fra samme travle sprint hadde logget konfigurasjonen, nøkkelen inkludert. Loggene var arkivert i tre år. Søkbare.

4. Chatten. «Funker det for deg med denne nøkkelen?» Limt inn i en teamkanal den gangen. Chat-arkiver glemmer ingenting.

Ingen av stedene var eksotiske. Alle var forutsigbare. Det er poenget: en lekket hemmelighet sprer seg langs helt vanlige arbeidsflyter, og «vi fjernet den fra koden» berører bare ett av sporene.

Regelen som mangler i de fleste team

Derfor finnes det bare én riktig respons når en hemmelighet har vært eksponert, uansett hvor kort tid:

Rotér. Alltid. Umiddelbart.

Ikke «fjern og vurder». Ikke «den lå der bare i en time». Rotér nøkkelen, ugyldiggjør den gamle, og deretter rydd sporene. En hemmelighet som har vært i en commit, en logg eller en chat, skal behandles som kompromittert, fordi du aldri kan bevise det motsatte.

Det er en regel som må være avtalt før uhellet, for i øyeblikket vil alle helst tro at det gikk bra. Legg den i sikkerhetsstandardene, slik jeg skrev i Standarder i praksis: sikkerhet er ikke fleksibelt.

Forsvarsverket (én ettermiddag for å komme i gang)

• Secret scanning på repoet – blokkér commits med nøkkelmønstre før de når repoet, ikke etter. GitHub har push protection innebygd, gratis og påskrudd som standard for det du selv pusher til offentlige repoer. For private og interne repoer ligger den bak GitHub Secret Protection, som faktureres per aktiv committer, så sjekk hva dere faktisk har lisens på før dere antar at den står på.
• Vault/Key Vault som eneste kilde – koden refererer, aldri inneholder.
• Pre-commit hooks lokalt – fang det før det når historikken. gitleaks og trufflehog er de to etablerte, begge åpen kildekode, begge kjørbare som pre-commit-hook og som CI-steg. Det siste er poenget: en hook den enkelte kan hoppe over med --no-verify, er en anbefaling. Den samme sjekken i pipelinen er en kontroll. Kjør dem også én gang over hele historikken; det er der funnene ligger.
• Og øv på rotasjon – en nøkkel dere ikke tør å rotere, er en nøkkel dere ikke kontrollerer.

Én advarsel om oppryddingen: å fjerne en nøkkel fra git-historikken krever omskriving av historikken (git filter-repo), og selv da lever den videre i forker, i CI-cacher og hos alle som har klonet. Rekkefølgen er derfor alltid rotér først, rydd etterpå. En nøkkel som er byttet ut, gjør ingen skade selv om den ligger igjen. En nøkkel som bare er slettet fra historikken, er fortsatt gyldig.

Regningen som aldri kom

Nøkkelen vår gjorde, så vidt vi vet, aldri skade. Det var flaks – og flaks er ikke en kontroll.

Sjekk de fire stedene i dag: historikken, forkene, loggene, chatten. Mange som gjør det, finner noe. Og det virker ofte fortsatt: GitGuardian testet i januar 2026 nøkler som hadde vært gyldige i 2022, og over 64 prosent virket ennå. Det er langt billigere å finne det selv enn å få det rapportert.