Gitleaks: Stoppa API-nycklar i Git i 13 Steg [2026]

En läckt API-nyckel i en Git-historik kostar mer att städa upp än de flesta team tror. Nyckeln ligger kvar i varje commit den någonsin rörde vid, även efter att filen raderats, och den går att hitta med ett enda git log -p-kommando om ingen håller koll. Gitleaks är det verktyg flest säkerhetsteam i Norden nu bygger in i sina pipelines för att fånga sådana läckor innan de blir ett dataintrång. I den här guiden installerar du Gitleaks 8.30, bygger en egen regeluppsättning, sätter upp pre-commit-hooks och kopplar in verktyget i både GitHub Actions och GitLab CI. Du får också en komplett incidentrunbook för dagen en hemlighet trots allt läcker.

Guiden är byggd för utvecklare, DevOps-ingenjörer och säkerhetsansvariga som redan har grundläggande vana av terminalen och Git, men som ännu inte har en systematisk process för att fånga hemligheter innan de checkas in. Du behöver inte ha jobbat med hemlighetsskanning tidigare. Varje steg innehåller de faktiska kommandon du kör, exempel på hur utskriften ser ut, och en förklaring till varför steget behövs, inte bara vad du ska skriva. Om du redan har läst vår genomgång av säkerhet och dataintrång känner du säkert igen mönstret: billiga misstag i vardagen orsakar oftare skada än avancerade attacker.

Vad är Gitleaks och varför är läckta hemligheter plötsligt affärskritiska?

Gitleaks är ett öppen källkod-verktyg skrivet i Go som letar efter hårdkodade hemligheter, API-nycklar, lösenord och tokens i Git-repor. Verktyget skannar inte bara den senaste versionen av koden utan går igenom hela commit-historiken, vilket är exakt där de flesta läckor gömmer sig. En utvecklare tar bort en nyckel i nästa commit och tror att problemet är löst, men nyckeln finns fortfarande kvar i historiken och går att plocka fram av vem som helst med klon-åtkomst.

Verktyget skapades ursprungligen av Zach Rice och drivs i dag som ett community-projekt med bidrag från säkerhetsteam på flera stora teknikbolag. Det körs som en fristående binär utan några externa beroenden, vilket gör det enkelt att installera på en byggserver som saknar internetåtkomst till annat än det som redan krävs för själva bygget. Den egenskapen är en stor del av varför verktyget spridit sig så snabbt bland både startups och myndigheter: det finns inget licenskrav, inget konto att skapa och ingen data som lämnar er egen infrastruktur under skanningen.

Alternativet till automatiserad skanning är manuell kodgranskning, och den metoden fungerar dåligt mot just den här typen av fel. En granskare som läser en pull request med femtio ändrade filer missar lätt en enskild rad med en hårdkodad nyckel mitt i en konfigurationsfil, särskilt om granskningen sker snabbt sent på en fredag. Ett verktyg som Gitleaks tröttnar aldrig, läser varje rad i varje fil på samma sätt varje gång, och kostar bara några sekunders väntetid i pipelinen.

Att detta inte är ett teoretiskt problem visade sig tydligt 2024, då Mercedes-Benz upptäckte att en GitHub-token lämnats kvar i ett publikt repo. Token gav i praktiken åtkomst till bolagets interna GitHub Enterprise Server, med källkod, molnåtkomstnycklar, API-nycklar, SSO-lösenord och designdokument exponerade. Mercedes beskrev det som ett mänskligt fel, återkallade token och tog bort repot. Samma år bekräftade New York Times att en exponerad GitHub-token använts för att komma åt bolagets kodrepor och att intern källkod senare dök upp offentligt, även om tidningen inte hittade tecken på att de egna interna systemen påverkats.

2026 fick incidenttypen ett nytt, mer allvarligt exempel: en underleverantör till den amerikanska myndigheten CISA lämnade ett publikt GitHub-repo öppet i ungefär sex månader. Det innehöll AWS GovCloud-nycklar, användarnamn och lösenord i klartext, SSH-nycklar, Entra ID SAML-certifikat och API-tokens, sammanlagt omkring 844 MB intern data som låg sökbar på nätet tills repot städades bort. Enligt Verizon 2026 Data Breach Investigations Report var sårbarhetsutnyttjande den vanligaste initiala inbrottsvägen i 31 procent av alla dataintrång, medan stulna eller läckta inloggningsuppgifter låg på 13 procent som första steg och förekom någonstans i attackkedjan i hela 39 procent av fallen. Kopplingen till Verizons genomgång av 22 000 dataintrång är tydlig: en läckt hemlighet i kod är sällan den mest sofistikerade attackvektorn, men den är en av de billigaste för en angripare att utnyttja.

Det finns också en regulatorisk sida av samma problem. OWASP Top 10 listar hantering av hemligheter under kategorier som kryptografiska brister och felkonfiguration, med rekommendationen att hemligheter aldrig ska ligga i källkoden utan i en separat hemlighetshanterare. För bolag som omfattas av NIS2 räknas en läckt produktionsnyckel som gav faktisk åtkomst till system eller personuppgifter ofta som en säkerhetsincident som ska bedömas för anmälan, inte bara ett internt utvecklingsmisstag att fixa i tysthet. Att kunna visa exakt när en hemlighet infördes i koden, hur länge den var exponerad och när den upptäcktes blir därför en del av bolagets bevisbörda, inte bara en teknisk detalj.

Så fungerar hemlighetsskanning: regler, entropi och historik

Gitleaks bygger på två kompletterande metoder. Den första är regelbaserad matchning: verktyget levereras med en inbyggd regeluppsättning av reguljära uttryck som känner igen mönstret hos vanliga nyckeltyper, till exempel AWS-access-nycklar, Slack-tokens, Stripe-nycklar och privata SSH-nycklar. Den andra metoden är entropianalys, som flaggar strängar med ovanligt hög slumpmässighet även när mönstret inte matchar en känd regel. Det fångar upp egna interna hemligheter och nygenererade tokens som ingen ännu skrivit en specifik regel för.

Allt styrs via en konfigurationsfil som normalt heter .gitleaks.toml. Där definierar du vilka regler som ska vara aktiva, vilka filer som ska ignoreras och vilka fynd som är kända falska positiva. Skanningsläget avgör hur djupt verktyget letar: du kan begränsa dig till arbetskatalogen, till en enskild commit, eller be Gitleaks gå igenom varje commit som någonsin gjorts i repot. Den sista varianten är långsammare men är den enda som verkligen bekräftar att ett repo är rent, eftersom en borttagen rad kod fortfarande finns kvar i tidigare commit-objekt.

I praktiken kombinerar de flesta team tre lager: en pre-commit-hook som stoppar hemligheter innan de ens hamnar i en commit, en CI-kontroll som blockerar en pull request om något ändå slinker igenom, och en periodisk full historikskanning som fångar gamla synder från innan Gitleaks infördes. Den arkitekturen liknar hur ni redan jobbar med containerskanning eller SBOM-verktyg i leveranskedjan, bara flyttat ett steg tidigare i processen, till själva källkoden.

Gitleaks jämfört med andra sätt att fånga hemligheter

Gitleaks är inte det enda alternativet, och det är bra att förstå var det passar in innan du bygger hela strategin runt ett enda verktyg. GitHub Advanced Security har en inbyggd secret scanning-funktion som körs direkt i plattformen utan extra installation, men den är begränsad till repor som ligger på GitHub och kräver i vissa fall en betald licensnivå för privata repor. Kommersiella tjänster som GitGuardian erbjuder ett centralt dashboard, historik över alla fynd i organisationen och inbyggd riskvärdering, men kostar per utvecklare och per repo. TruffleHog är den närmaste öppna konkurrenten till Gitleaks och lägger extra vikt vid att verifiera om ett fynd faktiskt är en giltig, aktiv nyckel genom att testa den mot leverantörens API, medan Gitleaks fokuserar på snabb, bred detektion utan att göra externa anrop.

Skälet att så många team ändå landar på Gitleaks som förstahandsval är kombinationen av att det är gratis, körs lika bra lokalt som i CI oavsett om koden ligger på GitHub, GitLab eller ett eget Git-nav, och att konfigurationen är enkel att versionshantera tillsammans med resten av koden. Det gör det till ett naturligt förstalager, som sedan kan kompletteras med en betaltjänst för organisationer som behöver ett centralt dashboard över flera hundra repor.

För mindre Nordiska bolag och offentliga verksamheter med begränsad säkerhetsbudget är kostnadsfrågan sällan bara en detalj. Att kunna sätta upp ett fullgott första skyddslager utan licenskostnad gör det möjligt att prioritera pengarna till annat, till exempel penetrationstester eller en betald tjänst för just de mest kritiska produktionsrepona, snarare än att behöva välja mellan hemlighetsskanning och andra säkerhetsinvesteringar.

Så prioriterar du fynd: allvarlighetsgrad och triage

Ett repo som aldrig skannats tidigare kan generera överraskande många fynd på en gång, särskilt vid den första fullständiga historikskanningen. Att försöka åtgärda allt samtidigt är ofta ogenomförbart och leder till att teamet ger upp halvvägs. Sortera istället fynden efter faktisk risk innan ni börjar rotera nycklar.

Allvarlighetsgrad	Exempel	Åtgärd och tidsram
Kritisk	Aktiv produktionsnyckel till databas, molnkonto eller betaltjänst	Rotera inom timmar, behandla som pågående incident
Hög	Giltig nyckel till en intern tjänst utan direkt internetexponering	Rotera inom samma arbetsdag
Medel	Testmiljö-nyckel med begränsad behörighet	Rotera inom en vecka, dokumentera i backloggen
Låg	Utgången eller redan återkallad nyckel	Städa bort från historiken vid nästa planerade tillfälle
Falsk positiv	Exempeldata i dokumentation eller testfixtur	Lägg till i allowlist, ingen ytterligare åtgärd

Den här typen av triage fungerar bäst om ni bestämmer kriterierna innan skanningen körs, inte efteråt när listan med fynd redan ligger på bordet och stressen gör att alla vill klassa allt som lågt. Utse gärna en ansvarig person eller ett litet team som äger processen, snarare än att låta den som råkar hitta fyndet avgöra allvarlighetsgraden själv.

Förutsättningar: verktyg, versioner och behörigheter

Innan du börjar behöver du ett par verktyg installerade och rätt behörigheter i de repor du ska skydda. Gitleaks CLI ligger i skrivande stund på version 8.30.1, släppt 21 mars 2026, och det officiella GitHub Actions-integrationen gitleaks-action har enligt GitHub Marketplace nått version 3.0.0. Det är värt att hålla båda dessa uppdaterade snarare än att låsa fast en gammal version, eftersom nyare utgåvor löpande lägger till detektionsregler för nya token-format från molnleverantörer, som annars skulle missas helt av en äldre installation. Tabellen nedan sammanfattar vad du behöver innan du sätter igång.

Verktyg	Version som används i guiden	Syfte
Gitleaks CLI	8.30.1	Kärnverktyget för hemlighetsskanning
Git	2.43 eller senare	Krävs för historik-skanning
pre-commit	3.7 eller senare	Kör Gitleaks lokalt före varje commit
Docker	25.0 eller senare	Kör Gitleaks utan lokal installation
gitleaks-action	3.0.0	Integration i GitHub Actions
Node.js	20 LTS	Exempelprojektet i slutet av guiden

Du behöver även skriv-behörighet till repots inställningar om du vill lägga in en branch-regel som blockerar merge vid fynd, samt admin-åtkomst till hemligheter (secrets) i GitHub eller GitLab om du senare ska rotera nycklar. Räkna med att hela guiden, från installation till en fungerande pipeline, tar omkring 75 minuter.

Om ni jobbar i en organisation med central IT-säkerhet är det värt att stämma av med dem innan ni rullar ut Gitleaks brett. Vissa organisationer vill samla alla fynd i ett gemensamt system snarare än att låta varje team hantera sina egna larm, och det är enklare att komma överens om det innan hundra repor redan har fått sin egen lokala konfiguration.

Steg 1–3: Installation och din första skanning

Steg 1: Installera Gitleaks

På macOS är Homebrew snabbast. På Linux hämtar du binären direkt från GitHub-releasen eller bygger den med Go. Alla tre metoderna installerar samma gitleaks-binär. Välj Homebrew om du bara vill testa verktyget snabbt på din egen dator, välj den nedladdade binären om du bygger en Docker-avbildning eller en byggserver från grunden, och välj Go-installationen om ni redan har en standardiserad Go-toolchain i CI-miljön och vill undvika ett extra nedladdningssteg.

# macOS
brew install gitleaks

# Linux (binär, x86_64)
curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz -o gitleaks.tar.gz
tar -xzf gitleaks.tar.gz
sudo mv gitleaks /usr/local/bin/

# Med Go (kräver Go 1.22+)
go install github.com/gitleaks/gitleaks/v8@latest

Steg 2: Verifiera installationen

Kontrollera att binären hittas och att versionen stämmer med den du tänkt använda.

gitleaks version
# gitleaks version 8.30.1

Steg 3: Kör din första skanning

Gå till roten av ett Git-repo och kör en skanning mot arbetskatalogen. Flaggan -v ger utförlig utskrift så att du ser exakt vilken rad och fil ett fynd kommer från.

cd mitt-repo
gitleaks git -v .

Ett typiskt fynd i terminalen ser ut ungefär så här:

Finding:     AKIAIOSFODNN7EXAMPLE
Secret:      AKIAIOSFODNN7EXAMPLE
RuleID:      aws-access-token
Entropy:     3.98
File:        config/settings.py
Line:        14
Commit:      4a1c9e2
Author:      [email protected]
Date:        2026-03-02T10:15:00Z

10:12 säkerhetsfynd hittades i 3 filer, 847 commits skannade

Om utskriften avslutas med noll fynd och exitkod 0 är repot rent för den historik du skannade. En exitkod skild från noll signalerar fynd, vilket är precis det du vill utnyttja i nästa steg när du kopplar in verktyget i CI.

Steg 4–5: Tolka resultatet och bygga en egen .gitleaks.toml

Standardreglerna i Gitleaks täcker de vanligaste molntjänsterna, men i praktiken har varje bolag egna interna tokenformat, till exempel en intern API-gateway eller ett internt testcertifikat som inte matchar någon generisk regel. Lösningen är att skriva en egen konfigurationsfil och peka Gitleaks mot den.

# .gitleaks.toml
title = "Anpassad konfiguration för interna tokens"

[[rules]]
id = "internal-api-token"
description = "Intern API-token för exempelbolagets tjänster"
regex = '''(?i)exempelbolag-(prod|stage)-[a-z0-9]{32}'''
tags = ["intern", "api", "kritisk"]

[[rules]]
id = "internal-test-cert"
description = "Testcertifikat som av misstag checkats in"
regex = '''-----BEGIN (RSA )?PRIVATE KEY-----'''
path = '''.*test.*\.pem$'''

Kör sedan skanningen med den egna konfigurationen explicit angiven:

gitleaks git -v --config .gitleaks.toml .

Skriv gärna en kort beskrivning och en tydlig id för varje regel. Det gör det mycket enklare för resten av teamet att förstå varför ett fynd flaggades, särskilt när ni senare bygger allowlists för de fynd som visar sig vara harmlösa testdata. Ett vanligt nybörjarfel är att skriva ett regex som är för brett, till exempel ett som matchar alla 32 tecken långa hexadecimala strängar. Det fångar riktiga nycklar, men flaggar samtidigt hashvärden, commit-id och andra harmlösa strängar som förekommer överallt i en kodbas, vilket snabbt dränker teamet i falska larm.

Steg 6–7: Allowlist och full historikskanning

Inte alla fynd är farliga. Testfixturer innehåller ofta medvetet falska nycklar, exempeltokens i dokumentation matchar samma mönster som riktiga hemligheter, och genererade testcertifikat kan trigga entropiregler utan att utgöra någon risk. För att undvika att teamet slutar bry sig om varningarna behöver du en allowlist.

[allowlist]
description = "Globala undantag"
paths = [
  '''.*_test\.go$''',
  '''.*/fixtures/.*''',
  '''.*\.md$'''
]
regexes = [
  '''AKIAIOSFODNN7EXAMPLE''',
  '''sk_test_[0-9a-zA-Z]{24}'''
]

När allowlisten är på plats är det tid för den skanning som faktiskt avgör om repot är säkert: en fullständig genomgång av hela historiken, inte bara den senaste commiten. Detta är särskilt viktigt för repor som funnits i flera år innan Gitleaks infördes.

# Skanna hela historiken från första commit
gitleaks git --log-opts="--all" -v .

# Exportera resultatet till JSON för vidare bearbetning
gitleaks git --log-opts="--all" --report-format json --report-path fynd.json .

Räkna med att den första fullständiga historikskanningen på ett gammalt repo tar betydligt längre tid än en vanlig skanning, ibland flera minuter beroende på hur många commit repot innehåller. Kör den som ett engångsjobb, dokumentera fynden, och åtgärda dem innan du går vidare till att automatisera kontinuerliga skanningar. På riktigt stora repor, med tiotusentals commits eller flera decennier av historik, kan det vara värt att köra den första genomgången på en separat maskin med gott om minne snarare än på en delad CI-agent som andra team också behöver använda samtidigt.

Steg 8: Pre-commit-hook som stoppar läckor lokalt

Den billigaste platsen att fånga en hemlighet är innan den överhuvudtaget lämnar utvecklarens dator. Ramverket pre-commit gör det enkelt att köra Gitleaks automatiskt varje gång någon försöker committa.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Installera själva git-hooken en gång per klonat repo:

pip install pre-commit
pre-commit install

Från och med nu körs Gitleaks automatiskt vid varje git commit, och committen blockeras direkt i terminalen om ett fynd upptäcks. Det är enkelt att kringgå med --no-verify, så hooken ska ses som ett första skyddslager, inte det enda. Fördelen med att fånga läckan här är hastigheten: utvecklaren får feedback på sekunden, innan koden ens lämnat den lokala maskinen, vilket är betydligt billigare att åtgärda än ett fynd som redan hunnit till en delad branch och kanske synkats till flera kollegors klonade kopior.

Steg 9: Automatisera i GitHub Actions

Nästa lager är att blockera en pull request centralt, oavsett vad som händer på utvecklarens lokala maskin. Det officiella gitleaks-action gör detta med minimal konfiguration.

# .github/workflows/gitleaks.yml
name: Gitleaks
on: [pull_request, push]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Gitleaks Secret Scan
        uses: gitleaks/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Lägg märke till fetch-depth: 0. Utan den hämtar checkout-steget bara den senaste commiten, vilket gör att Gitleaks inte kan skanna historiken i pull requesten korrekt. Koppla sedan jobbet till en branch protection-regel så att en pull request med fynd inte kan mergas förrän problemet är löst. I GitHub gör du det under repots inställningar, i sektionen för grenskydd, genom att kräva att statuskontrollen från Gitleaks-jobbet ska vara godkänd innan mergeknappen aktiveras. Utan den regeln fungerar CI-jobbet bara som en varning som utvecklare kan välja att bortse från.

Steg 10: Kör Gitleaks i GitLab CI/CD

Många Nordiska bolag, särskilt inom offentlig sektor, kör självhostad GitLab snarare än GitHub. Gitleaks fungerar lika bra där genom den officiella Docker-avbildningen.

# .gitlab-ci.yml
secret-scan:
  stage: test
  image:
    name: zricethezav/gitleaks:v8.30.1
    entrypoint: [""]
  script:
    - gitleaks git --log-opts="--all" -v .
  allow_failure: false

allow_failure: false är avgörande. Sätter du den till true kommer pipelinen fortfarande visa en varning vid fynd, men den blockerar inte merget, vilket i praktiken gör hela kontrollen kosmetisk. Vill ni köra jobbet snabbare på stora repor kan ni byta ut den fullständiga historikskanningen mot ett läge som bara jämför den aktuella branchen mot huvudgrenen, och sedan lägga den fullständiga genomgången i ett separat, schemalagt pipeline-jobb som körs till exempel varje natt.

Steg 11: Container- och multirepo-skanning med Docker

Om ni inte vill installera Gitleaks lokalt på varje utvecklarmaskin, eller om ni behöver skanna många repor samtidigt från ett CI-agent-nätverk, är Docker-avbildningen det enklaste alternativet. Samma logik går att koppla ihop med hur ni redan signerar containeravbildningar i leveranskedjan, som ett steg tidigare i pipelinen.

docker run -v $(pwd):/repo zricethezav/gitleaks:v8.30.1 \
  git --log-opts="--all" -v /repo

# Skanna flera repor i en loop
for dir in ./repos/*/; do
  echo "Skannar $dir"
  docker run -v "$dir":/repo zricethezav/gitleaks:v8.30.1 \
    git --log-opts="--all" /repo
done

Den här metoden är särskilt användbar vid en engångsgenomgång av ett helt GitHub- eller GitLab-konto med hundratals repor, ett vanligt scenario när ett bolag för första gången inför hemlighetsskanning i en redan stor kodbas.

Steg 12: Rapportering med SARIF/JSON och ärendehantering

För att fynd ska bli åtgärdade, och inte bara synas i en terminal någon glömmer, behöver de in i ett system människor faktiskt tittar på. Gitleaks kan skriva ut resultatet i flera maskinläsbara format som passar olika verktyg.

Format	Flagga	Vanligt användningsområde
JSON	–report-format json	Egna skript, dashboards, Slack-notiser
SARIF	–report-format sarif	GitHub Code Scanning, säkerhetsflik i repot
CSV	–report-format csv	Enkel export till kalkylark för revision
JUnit	–report-format junit	Visa fynd som testfel i CI-gränssnittet

gitleaks git --log-opts="--all" \
  --report-format sarif \
  --report-path gitleaks.sarif .

Laddar du upp SARIF-filen till GitHub Code Scanning dyker fynden upp direkt i repots säkerhetsflik, med samma fildiff-vy som andra kodsäkerhetsverktyg använder. Det gör det betydligt lättare att koppla ett fynd till rätt person och rätt ärende, snarare än att någon behöver leta i en CI-logg. Om ni redan använder ett incidenthanteringssystem som Jira eller ett SIEM-verktyg kan JSON-formatet läsas av ett enkelt skript som skapar ett ärende automatiskt för varje nytt fynd, komplett med filväg, commit-hash och vilken regel som slog till.

Steg 13: Rotations- och incidentrunbook när en hemlighet redan läckt

Att hitta en läckt hemlighet är bara halva jobbet. Nyckeln måste också behandlas som redan komprometterad, oavsett hur säkra ni känner er på att ingen hann utnyttja den. Bygg in följande punkter i teamets rutin, och koppla den gärna till en bredare NIS2-incidentplan om bolaget omfattas av lagen.

Rotera nyckeln omedelbart hos den tjänst den hör till, innan ni gör något annat.
Slå av den gamla nyckeln aktivt i leverantörens konsol, ta inte för givet att en ny nyckel automatiskt inaktiverar den gamla.
Granska åtkomstloggar hos leverantören för perioden nyckeln var exponerad, för att se om den faktiskt användes av någon obehörig.
Skriv om Git-historiken med git filter-repo eller BFG Repo-Cleaner om nyckeln fortfarande ligger kvar i gamla commits, och tvinga alla klonade kopior att synka om.
Dokumentera incidenten, inklusive vilken regel i Gitleaks som fångade den och hur lång tid nyckeln var exponerad, som underlag för en eventuell anmälan.

Den sista punkten är inte byråkrati för sin egen skull. Om nyckeln gav åtkomst till personuppgifter kan exponeringstiden vara avgörande för om händelsen räknas som en anmälningspliktig personuppgiftsincident, ungefär som i CISA-fallet ovan där exponeringen pågick i sex månader innan den upptäcktes.

Fem vanliga fallgropar med Gitleaks

De flesta av dessa misstag är inte tekniskt svåra att undvika, men de är lätta att missa när ett team sätter upp sin första pipeline under tidspress. Gå igenom listan innan ni kallar konfigurationen klar, snarare än att upptäcka dem först när ett verkligt fynd slinker igenom.

Fallgrop	Konsekvens	Lösning
Skannar bara senaste commit	Gamla läckor i historiken upptäcks aldrig	Kör alltid med `--log-opts="--all"` minst en gång per repo
Ingen allowlist för testdata	Teamet börjar ignorera larmen helt	Bygg en tydlig allowlist tidigt och underhåll den
Shallow checkout i CI	Gitleaks ser bara en commit och missar fynd	Sätt `fetch-depth: 0` i checkout-steget
Rotera bara nyckeln, inte historiken	Den gamla, redan läckta nyckeln syns fortfarande i klonade kopior	Skriv om historiken med filter-repo eller BFG efter rotation
Pre-commit-hooken är den enda kontrollen	En utvecklare kör `--no-verify` och läckan slinker igenom	Kombinera hook, CI-blockering och periodisk historikskanning

Felsökning: åtta vanliga fel och lösningar

De flesta problem med Gitleaks handlar inte om buggar i verktyget själv, utan om hur det kopplats in i pipelinen eller vilka flaggor som glömts bort. Nedanstående lista täcker de fel vi stöter på oftast när team sätter upp sin första skanning, från felaktiga sökvägar till behörighetsproblem i CI.

Problem	Trolig orsak	Lösning
“no such file .gitleaks.toml”	Konfigurationsfilen ligger inte i sökvägen som angetts	Ange full sökväg eller kör kommandot från repots rot
Skanningen hittar inga fynd trots kända läckor	Skanningen kör bara mot senaste commit	Lägg till `--log-opts="--all"`
CI-jobbet tar väldigt lång tid	Full historikskanning på ett mycket stort repo	Begränsa till senaste N commits vid vanlig CI, kör full skanning separat och mer sällan
Samma fynd rapporteras om och om igen	Fyndet är känt och godkänt men saknas i allowlisten	Lägg till exakt regex eller filväg i allowlist-sektionen
Pre-commit-hooken körs inte alls	`pre-commit install` har inte körts i det lokala repot	Kör installationskommandot en gång per klonat repo
Action i GitHub misslyckas med behörighetsfel	`GITHUB_TOKEN` saknar rätt scope eller är inte satt	Kontrollera att env-variabeln pekar mot secrets.GITHUB_TOKEN
Docker-körningen hittar inga filer	Volymen är felaktigt monterad	Kontrollera att sökvägen efter `-v` pekar på repots rot, inte en undermapp
SARIF-filen visas inte i GitHub	Filen laddades aldrig upp med rätt action	Använd `github/codeql-action/upload-sarif` som ett separat steg efter skanningen

Avancerade tips för stora team och monorepos

I ett monorepo med flera team blir det snabbt rörigt om alla delar samma .gitleaks.toml. Lägg istället en gemensam basfil i roten och låt varje team lägga till egna, mer specifika regler i undermappar där det behövs, och slå ihop dem i CI innan skanningen körs.

För organisationer med hundratals repor är det värt att bygga ett litet skript som samlar JSON-rapporter från varje repo till en central databas eller ett kalkylark, snarare än att förlita sig på att varje team läser sin egen CI-logg. Koppla gärna resultatet vidare till samma typ av riskrapportering ni redan använder för SBOM och leveranskedjesäkerhet, så att ledningen ser läckta hemligheter och sårbara beroenden i samma översikt.

Ett annat tips: sätt en hård gräns på exekveringstid i CI för den fullständiga historikskanningen och kör den nattlig eller veckovis snarare än på varje pull request. Den dagliga kontrollen bör vara snabb och bara täcka de senaste ändringarna, medan den djupa genomgången av hela historiken sköts som ett schemalagt jobb.

Om organisationen har flera hundra utvecklare är det värt att göra Gitleaks-konfigurationen till en egen, versionshanterad artefakt som alla repor hämtar från en gemensam källa, snarare än att varje team kopierar och klistrar in sin egen .gitleaks.toml. Då slipper ni att en förbättrad regel eller en ny allowlist-post måste spridas manuellt till hundratals repor. Ett enkelt sätt är att lägga basfilen i ett centralt repo och låta ett kort skript i varje pipeline hämta den innan skanningen körs.

Tänk också på hemligheter som aldrig ser ut som hemligheter. Interna hostnamn, databasers interna IP-adresser och kundnummer i loggfiler är inte det Gitleaks letar efter som standard, men de kan vara lika känsliga i en Nordisk kontext med GDPR. Om ni har den typen av data i koden är det värt att skriva egna regler för just det, snarare än att anta att standardreglerna täcker allt som är känsligt för er verksamhet.

Ett komplett exempelprojekt: Node.js-API med full Gitleaks-pipeline

Nedan är strukturen för ett minimalt men komplett projekt som binder ihop allt du gått igenom: lokal hook, egen konfiguration, allowlist och en CI-pipeline som blockerar merge vid fynd.

mitt-api/
├── .github/workflows/gitleaks.yml
├── .gitleaks.toml
├── .pre-commit-config.yaml
├── src/
│   └── server.js
├── package.json
└── README.md

Konfigurationsfilen kombinerar de anpassade reglerna och allowlisten från tidigare steg i en enda fil:

# .gitleaks.toml
title = "mitt-api secret scanning"

[[rules]]
id = "internal-api-token"
description = "Intern API-token"
regex = '''(?i)mittapi-(prod|stage)-[a-z0-9]{32}'''
tags = ["intern", "kritisk"]

[allowlist]
description = "Testdata och fixturer"
paths = [
  '''.*_test\.js$''',
  '''.*/fixtures/.*'''
]

Med denna struktur på plats stoppas en läckt nyckel redan lokalt av pre-commit-hooken från steg 8. Om den ändå slinker igenom, till exempel via en kollaborators direkta push, fångas den av GitHub Actions-jobbet från steg 9, som blockerar merget innan koden når huvudgrenen. Kör slutligen en full historikskanning enligt steg 6–7 en gång som ett engångsjobb för att bekräfta att det befintliga repot är rent innan pipelinen sätts i produktion.

Testa hela flödet genom att medvetet committa en falsk testnyckel, till exempel en påhittad AWS-nyckel med rätt format, och bekräfta att både hooken lokalt och CI-jobbet i molnet stoppar den. Ta sedan bort testnyckeln och committa på nytt innan du går vidare, annars ligger den kvar i historiken och dyker upp igen vid nästa fullständiga skanning.

Lägg gärna till en enkel README-sektion i själva projektet som förklarar vad som händer om Gitleaks stoppar en commit eller en pull request, och vem i teamet man ska kontakta om man är osäker på om ett fynd är farligt. Nya utvecklare som möter en blockerad commit för första gången blir ofta osäkra på om de gjort något fel, och en tydlig instruktion i README-filen sparar både tid och irritation jämfört med att de gissar sig fram eller, i värsta fall, kör --no-verify för att bara komma vidare.

När pipelinen är på plats är den enkel att underhålla. Uppdatera versionsnumret i .pre-commit-config.yaml och i GitHub Actions-jobbet när en ny Gitleaks-version släpps, granska allowlisten en gång i kvartalet så att den inte samlar på sig undantag som egentligen borde tas bort, och låt den fullständiga historikskanningen köra som ett schemalagt jobb utan att någon behöver komma ihåg att starta den manuellt.

Vanliga frågor om Gitleaks

Är Gitleaks gratis att använda?
Ja, Gitleaks är öppen källkod under MIT-licens och kostar inget att installera eller köra, oavsett om det sker lokalt, i Docker eller i CI.

Fångar Gitleaks hemligheter som redan har tagits bort i en senare commit?
Ja, förutsatt att du skannar med --log-opts="--all". En borttagen rad finns fortfarande kvar i det ursprungliga commit-objektet i Git, och det är precis den historiken Gitleaks läser.

Kan Gitleaks ersätta GitHub Advanced Security eller GitGuardian?
Gitleaks löser samma grundproblem men är ett fristående CLI-verktyg utan inbyggd dashboard eller molntjänst. Många team använder Gitleaks som den kostnadsfria motorn i CI och kopplar sedan resultatet till en betaltjänst eller ett eget dashboard för överblick.

Vad gör jag om Gitleaks larmar men jag inte förstår varför?
Kör skanningen med flaggan -v för att se exakt fil, rad och regel-id. Sök sedan upp regel-id i din .gitleaks.toml eller i standardreglerna för att förstå vilket mönster som triggade fyndet.

Räcker det med en pre-commit-hook, eller behöver jag CI också?
En hook kan alltid kringgås med --no-verify eller genom att någon push:ar direkt utan att gå via den lokala klonen. CI-kontrollen är den som faktiskt garanterar att inget läcker till huvudgrenen, och den bör alltid finnas som ett andra lager.

Hur ofta bör vi köra en full historikskanning?
En gång vid införandet för att städa upp gamla synder, och därefter periodiskt, till exempel veckovis som ett schemalagt jobb, snarare än på varje pull request där det bara skulle förlänga väntetiden i onödan.

Vad ska vi göra först om Gitleaks hittar en riktig, aktiv hemlighet?
Rotera nyckeln hos leverantören omedelbart, innan du gör något annat, och behandla den som redan komprometterad. Se steg 13 för en fullständig checklista.

Fungerar Gitleaks med andra språk än de vanliga molnleverantörernas SDK:er?
Ja, eftersom detektionen bygger på mönster och entropi i textinnehållet, inte på språket kodfilen är skriven i. Du kan lika gärna skriva egna regler för interna Nordiska system som för globala molntjänster.

Kan Gitleaks skanna andra platser än Git-repor, till exempel lokala mappar eller Docker-avbildningar?
Ja. Utöver läget git, som läser commit-historik, finns ett läge som heter dir för att skanna en mapp rakt av utan att bry sig om Git-historik, praktiskt för att kontrollera exporterade arkiv eller uppackade avbildningar innan de publiceras.

Blir CI-pipelinen mycket långsammare av att lägga till Gitleaks?
En vanlig skanning mot den senaste ändringen tar oftast bara några sekunder. Det är den fullständiga historikskanningen som kan ta betydande tid på stora, gamla repor, vilket är skälet till att den bör köras som ett separat, mer sällan schemalagt jobb snarare än på varje pull request.

Gitleaks: Stoppa API-nycklar i 13 Steg, 75 Min [2026]