Semgrep 1.176: Hitta Sårbarheter i Kod, 14 Steg [2026]

Trettio sekunder. Så lång tid tar det ungefär för Semgrep att skanna ett medelstort Node.js-repo och peka ut hårdkodade lösenord, osäkra SQL-frågor och trasig autentiseringslogik, innan koden ens når en pull request. Verktyget har gått från nischprodukt till standardkomponent i CI/CD-pipelines hos säkerhetsteam runt om i Norden, och senaste versionen av Community Edition, 1.176.0, landade under veckan 31 augusti-6 september 2026 med snabbare skanningsstart. Den här guiden visar hur du installerar Semgrep, skriver egna regler, kopplar in verktyget i GitHub Actions och bygger ett komplett exempelprojekt där du både introducerar och fixar en riktig sårbarhet. Du behöver inga tidigare erfarenheter av statisk kodanalys, bara grundläggande kommandoradsvana.

Guiden är skriven för utvecklare och säkerhetsansvariga som redan hört talas om statisk kodanalys men aldrig satt upp det själva. Vi går igenom 14 konkreta steg, från installation till en produktionsklar CI/CD-integration, och vi bygger ett litet men fullt fungerande exempelprojekt längs vägen så att du ser hela flödet, från sårbar kod till grön pipeline. Utöver stegen får du fallgropar att undvika, en felsökningslista för de vanligaste problemen och en genomgång av hur Semgrep skiljer sig från alternativ som CodeQL och Snyk Code.

Vad är Semgrep och varför spelar SAST roll just nu

Semgrep är ett verktyg för statisk applikationssäkerhetstestning, förkortat SAST, som letar efter sårbara mönster direkt i källkoden innan den byggs eller körs. Till skillnad från dynamisk testning (DAST), där ett verktyg som OWASP ZAP anfaller en körande applikation utifrån, läser Semgrep koden rad för rad och matchar den mot regler skrivna i ett enkelt, läsbart format. Det gör verktyget snabbt att komma igång med jämfört med tyngre alternativ som kräver att hela projektet kompileras först.

Enligt Semgreps officiella prissida stöder plattformen fler än 35 programmeringsspråk, från JavaScript och Python till Go och Java. Community Edition är gratis och kan användas på upp till tio repositorier utan kostnad, medan de betalda nivåerna Code, Supply Chain och Secrets kostar från 15 till 30 dollar per bidragsgivare och månad enligt samma prissida. Den stora skillnaden mot rena beroende-skannrar som OSV-Scanner är att Semgrep letar efter fel i koden du själv skriver, inte bara i tredjepartspaket.

Det som gör hösten 2026 till ett bra tillfälle att sätta upp Semgrep är att leverantören just nu migrerar kunder till ett nytt system kallat Unified Policies. Enligt Semgreps releaseanteckningar för veckan 3-9 augusti 2026 börjar migreringen den 24 augusti, och det gamla policysystemet stängs den 1 november 2026. Sätter du upp Semgrep från grunden nu slipper du migrera senare. Samtidigt fortsätter verktyget att uppdateras i snabb takt, med versioner släppta i princip varje vecka under sommaren och hösten 2026.

En annan anledning att prioritera SAST just nu är att sårbarheter som introduceras direkt i egen kod, till skillnad från sårbara beroenden, sällan täcks av verktyg som fokuserar enbart på tredjepartspaket. En organisation som redan kör en beroendeskanner som OSV-Scanner och en hemlighetsskanner som Gitleaks har ofta ett blint fält kvar: logikfel, saknad indatavalidering och osäkra API-anrop som skrivs av det egna teamet. Det är exakt det fältet Semgrep är byggt för att täcka, och det är också därför verktyget ofta beskrivs som ett komplement snarare än en ersättning till andra skannrar i pipelinen.

Förkunskaper och verktyg du behöver

Innan du börjar behöver du några saker installerade. Semgrep körs som en fristående binär via pip eller Docker, så du slipper kompilera något själv. Tabellen nedan sammanfattar vad du behöver för att följa hela guiden, inklusive exempelprojektet.

Verktyg	Version / krav	Syfte i guiden
Python	Python 3 (senaste stabila release)	Krävs för att installera Semgrep via pip
Semgrep CLI	1.176.0 eller senare	Själva skanningsverktyget
Git	Senaste versionen	Versionshantering och GitHub-integration
Node.js	20.x LTS eller senare	Kör exempelprojektets sårbara API
Docker (valfritt)	Senaste versionen	Köra Semgrep utan lokal Python-miljö
GitHub-konto	–	Testa CI/CD-integrationen med Actions

Du behöver inte ett Semgrep-konto för att följa de första stegen. Community Edition fungerar helt lokalt utan inloggning. Kontot blir först relevant när du vill använda molnbaserad policyhantering, Pro-regler eller notifieringar via Slack och Jira, vilket vi kommer tillbaka till senare i guiden.

Så väljer du mellan pip, pipx och Docker

Det finns tre huvudsakliga sätt att köra Semgrep, och valet påverkar hur guiden nedan känns i praktiken. Pip-installationen som vi använder i steg 1 är enklast för den som redan har en Python-miljö och vill ha kommandot direkt i terminalen. Pipx isolerar Semgrep i en egen virtuell miljö och undviker konflikter med andra Python-paket, vilket är att föredra på en utvecklarmaskin med flera projekt. Docker-alternativet kräver ingen lokal Python-installation alls och är ofta förstahandsvalet i CI/CD-pipelines eftersom det ger en identisk körmiljö oavsett vilken runner som används. Vilket du väljer spelar ingen roll för resten av guiden, kommandona är i stort sett identiska.

Steg 1-3: Installera Semgrep och kör din första skanning

Det snabbaste sättet att komma igång är via pip. Öppna en terminal och kör följande kommandon. Steg 1 installerar verktyget, steg 2 verifierar versionen och steg 3 kör den första skanningen mot ett valfritt repo.

# Steg 1: installera Semgrep
pip install semgrep

# Steg 2: verifiera att installationen fungerar
semgrep --version

# Steg 3: kör en första skanning med automatiska regler
cd mitt-projekt
semgrep scan --config=auto .

Flaggan --config=auto hämtar regler baserat på vilka språk och ramverk Semgrep upptäcker i projektet, hämtade från det publika regelregistret på semgrep.dev. Första gången du kör kommandot kan det ta någon minut extra medan regelpaketet laddas ner, men efterföljande körningar cachas lokalt. På en dator utan internetuppkoppling kan du i stället peka på ett lokalt regelbibliotek med --config=./regler/.

Ett vanligt resultat efter en första skanning av en medelstor kodbas ser ut ungefär så här i terminalen:

  ┌──────────────┐
  │ 7 Findings   │
  └──────────────┘

  routes/user.js
     javascript.express.security.audit.express-sql-injection
        SQL-fråga byggs med strängkonkatenering av användarindata.
        12: const query = "SELECT * FROM users WHERE id = " + req.query.id;

  config/db.js
     generic.secrets.security.detected-mongodb-credentials
        Hårdkodad MongoDB-anslutningssträng med lösenord i klartext.
        4: const uri = "mongodb://admin:hemligt123@cluster0...";

Ran 891 rules on 43 files: 7 findings.

Varje träff visar filnamn, radnummer, regelns id och en kort förklaring. Regel-id:t är sökbart i Semgreps register, där du hittar bakgrund om varför mönstret flaggas och vilken CWE-kategori det tillhör.

Installera med Docker i stället

Föredrar du att slippa en lokal Python-miljö helt går det lika bra att köra Semgrep i en container. Det är särskilt användbart på maskiner där du inte har administratörsrättigheter att installera Python-paket globalt, eller när du vill garantera att alla i teamet kör exakt samma Semgrep-version oavsett operativsystem.

# Kör Semgrep via Docker utan lokal installation
docker pull semgrep/semgrep

docker run --rm -v "${PWD}:/src" semgrep/semgrep \
  semgrep scan --config=auto /src

Flaggan -v "${PWD}:/src" monterar din nuvarande katalog i containern så att Semgrep kan läsa filerna. Resultatet skrivs ut i terminalen precis som vid en vanlig lokal körning, och du kan lägga till samma flaggor som --baseline-ref eller egna konfigurationsfiler genom att montera fler volymer.

Steg 4-6: Förstå regelregistret och läs en riktig regel

Semgreps regelregister innehåller färdiga regler för vanliga sårbarhetsklasser: SQL-injektion, cross-site scripting, hårdkodade hemligheter, osäker deserialisering och en lång rad ramverksspecifika fel i Django, Express, Spring och Flask. Reglerna är skrivna i YAML och går att läsa utan djup Semgrep-kunskap, vilket är en av anledningarna till att verktyget sprider sig snabbt i säkerhetsteam som inte vill underhålla en svart låda.

Steg 4 är att titta på strukturen i en regel. Steg 5 är att förstå hur pattern matchar kod snarare än text, vilket är kärnan i Semgreps motor: reglerna bygger på syntaxträd, inte reguljära uttryck, så de tål omformatering av kod och variabelnamn som byts ut. Steg 6 är att testa en regel mot din egen kodbas med semgrep scan --config "p/security-audit", ett av de mest använda fördefinierade paketen i registret.

# Steg 6: kör ett specifikt regelpaket mot koden
semgrep scan --config "p/security-audit" --config "p/secrets" .

Genom att kombinera flera --config-flaggor kör du flera regelpaket i samma skanning. Det är vanligt att lägga ett generellt säkerhetspaket ovanpå ett språkspecifikt, exempelvis p/javascript tillsammans med p/security-audit, för bredare täckning utan att behöva skriva egna regler från början.

Steg 7-9: Skriv och testa egna regler

De färdiga reglerna täcker mycket, men varje kodbas har egna mönster som ingen generisk regel känner till: interna hjälpfunktioner för databasanrop, egna wrappers runt HTTP-klienter eller företagsspecifika namnkonventioner för hemligheter. Steg 7 är att identifiera ett sådant mönster i din egen kod. Steg 8 är att skriva en regel som fångar det. Steg 9 är att testa regeln mot både sårbar och säker kod för att undvika falska positiva.

Nedan är ett exempel på en egen regel som letar efter hårdkodade anslutningssträngar till databaser, ett av de vanligaste fynden i verkliga kodgranskningar.

rules:
  - id: hardkodad-databasuppkoppling
    languages: [javascript, typescript]
    severity: ERROR
    message: >
      Hittade en hårdkodad databas-URI med inbäddat lösenord.
      Flytta värdet till en miljövariabel eller en hemlighetshanterare
      som HashiCorp Vault eller AWS Secrets Manager.
    patterns:
      - pattern-either:
          - pattern: $VAR = "mongodb://$USER:$PASS@..."
          - pattern: $VAR = "postgres://$USER:$PASS@..."
    metadata:
      cwe: "CWE-798: Use of Hard-coded Credentials"
      owasp: "A07:2021 Identification and Authentication Failures"
      confidence: HIGH

Spara filen som regler/hemligheter.yaml och testa den fristående med semgrep scan --config regler/hemligheter.yaml .. Semgrep har även ett inbyggt testkommando, semgrep --test, som jämför regelns faktiska träffar mot förväntade träffar markerade med kommentaren # ruleid: i en testfil. Det gör det möjligt att lägga regeltester i samma CI-pipeline som resten av testsviten.

Steg 10-12: Integrera Semgrep i GitHub Actions

En skanning som bara körs manuellt glöms bort. Steg 10 är att lägga Semgrep i CI-pipelinen så att varje pull request skannas automatiskt. Steg 11 är att konfigurera vilka regelpaket som ska köras i CI kontra lokalt, ofta ett bredare paket i CI. Steg 12 är att sätta upp så att bygget faller om en kritisk sårbarhet hittas, men bara varnar för lägre allvarlighetsgrad.

name: semgrep
on:
  pull_request: {}
  push:
    branches: ["main"]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4

      - name: Kör Semgrep-skanning
        run: semgrep ci --config=auto
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

Kommandot semgrep ci skiljer sig från semgrep scan genom att det är byggt specifikt för pipelines: det känner av om körningen sker i en pull request eller på huvudgrenen, och det skickar resultat till Semgreps molnplattform om en SEMGREP_APP_TOKEN är satt. Utan token körs skanningen ändå, men utan centraliserad historik och utan de utökade Pro-reglerna som kräver ett betalt konto. För team som enbart vill köra Community Edition lokalt i CI räcker det att byta ut semgrep ci mot semgrep scan --config=auto --error, där flaggan --error gör att kommandot avslutas med felkod när träffar hittas.

Pre-commit-hook som komplement till CI

Att bara skanna i CI innebär att en utvecklare får feedback först efter att koden pushats och pipelinen körts klart, vilket ofta tar flera minuter. Ett snabbare alternativ är att lägga Semgrep som en pre-commit-hook, så att skanningen körs lokalt mot endast de ändrade filerna innan en commit ens skapas. Det kräver paketet pre-commit och en enkel konfigurationsfil i repots rot.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/semgrep/semgrep
    rev: v1.176.0
    hooks:
      - id: semgrep
        args: ["--config=auto", "--error"]

Aktivera hooken med pre-commit install så körs Semgrep automatiskt varje gång någon i teamet försöker committa. Kom ihåg att pre-commit-hooken är ett komplement till CI-jobbet, inte en ersättning, eftersom en utvecklare alltid kan hoppa över en lokal hook med flaggan --no-verify. CI-jobbet i GitHub Actions är därför den enda kontrollen som garanterat körs.

Samma flöde i GitLab CI

Kör din organisation GitLab i stället för GitHub fungerar samma princip, men konfigurationen skrivs i .gitlab-ci.yml i stället för en Actions-workflow. Semgreps officiella Docker-image fungerar identiskt oavsett CI-plattform, vilket är en av fördelarna med att verktyget distribueras som en container.

# .gitlab-ci.yml
semgrep:
  image: semgrep/semgrep
  stage: test
  script:
    - semgrep ci --config=auto
  variables:
    SEMGREP_APP_TOKEN: $SEMGREP_APP_TOKEN
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

Precis som i GitHub Actions-exemplet ovan sparas apptoken som en skyddad CI/CD-variabel i GitLab, aldrig direkt i konfigurationsfilen. Det gäller generellt för alla hemligheter i en pipeline, och det är för övrigt exakt den typen av misstag som Semgreps egna regler för hårdkodade hemligheter är byggda för att fånga.

Steg 13-14: Baseline, undantag och hantering av resultat

Kör du Semgrep mot en existerande kodbas för första gången är det inte ovanligt att få hundratals träffar. Att åtgärda allt på en gång är orealistiskt, så steg 13 är att sätta en baseline som markerar befintliga fynd som kända, medan nya fynd i framtida commits fortfarande blockerar bygget. Det görs med flaggan --baseline-ref, som jämför den aktuella grenen mot en tidigare commit eller mot huvudgrenen.

# Steg 13: jämför endast nya fynd mot main-grenen
semgrep scan --config=auto --baseline-ref main .

# Steg 14: undanta filer och kataloger permanent
cat .semgrepignore
node_modules/
dist/
build/
*.min.js
test/fixtures/

Filen .semgrepignore fungerar på samma sätt som .gitignore och används för genererad kod, tredjepartsbibliotek och testfixturer som aldrig ska skannas. Undvik att lägga hela mappar med applikationskod i den filen bara för att slippa hantera träffar, det gömmer problemet snarare än att lösa det. Bättre är att markera enskilda rader som medvetna undantag med kommentaren // nosemgrep: regel-id direkt i koden, tillsammans med en motivering.

Komplett exempelprojekt: hitta och fixa en sårbarhet i en Node.js-API

För att knyta ihop stegen ovan bygger vi ett minimalt Express-API med en medveten SQL-injektionssårbarhet, skannar det med Semgrep och åtgärdar felet. Det är samma typ av fel som Semgreps regel javascript.express.security.audit.express-sql-injection letar efter, och som återkommande dyker upp i verkliga kodgranskningar av interna API:er.

Så här ser den sårbara versionen ut innan Semgrep körs:

// routes/user.js - SÅRBAR VERSION
const express = require("express");
const router = express.Router();

router.get("/user", (req, res) => {
  // Användarindata konkateneras direkt in i SQL-strängen
  const query = "SELECT * FROM users WHERE id = " + req.query.id;
  db.query(query, (err, result) => {
    if (err) return res.status(500).json({ error: "Databasfel" });
    res.json(result);
  });
});

module.exports = router;

Kör semgrep scan --config=auto routes/ mot filen och verktyget flaggar raden med strängkonkatenering direkt, med hänvisning till CWE-89 (SQL Injection) i metadatan. Fixen är att byta till en parameteriserad fråga, där databasdrivrutinen hanterar indata separat från själva SQL-satsen i stället för att bygga en ny sträng för varje anrop.

// routes/user.js - ÅTGÄRDAD VERSION
const express = require("express");
const router = express.Router();

router.get("/user", (req, res) => {
  // Parameteriserad fråga, indata skickas separat från SQL-satsen
  const query = "SELECT * FROM users WHERE id = ?";
  db.query(query, [req.query.id], (err, result) => {
    if (err) return res.status(500).json({ error: "Databasfel" });
    res.json(result);
  });
});

module.exports = router;

Kör skanningen igen och fyndet är borta. Lägg till filen i din testsvit tillsammans med ett Semgrep-regeltest enligt steg 9, så förhindrar du att samma mönster smyger sig in igen vid en framtida refaktorering. Det här är kärnan i vad SAST ska göra: inte bara hitta en enskild bugg, utan bygga in en spärr mot att bugklassen återkommer.

Vill du utöka exempelprojektet ytterligare är ett naturligt nästa steg att lägga till en motsvarande route som tar emot ett lösenord och kontrollera att det hashas innan det sparas, snarare än att skickas vidare i klartext. Semgreps generiska säkerhetspaket flaggar även den typen av mönster, och övningen är ett bra sätt att se hur samma arbetsflöde, skanna, läsa fyndet, åtgärda, skanna igen, upprepas oavsett vilken sårbarhetsklass det handlar om. Det gör det också enklare att bygga upp en intern katalog av “innan och efter”-exempel som nya utvecklare i teamet kan lära sig av.

Semgrep CE, Pro och andra SAST-verktyg

Semgrep konkurrerar med flera etablerade verktyg för statisk kodanalys, där GitHubs CodeQL och kommersiella plattformar som Snyk Code och Bearer är de mest omtalade alternativen. Skillnaden ligger delvis i angreppssätt: CodeQL bygger en fullständig databasrepresentation av koden och tillåter komplexa frågor i ett frågespråk som liknar SQL, vilket ger djup men kräver mer beräkningskraft och startsträcka. Semgreps regelbaserade mönstermatchning är i gengäld snabbare att komma igång med och enklare att läsa för utvecklare utan säkerhetsbakgrund.

Egenskap	Semgrep Community Edition	Semgrep Pro / Code
Kostnad	0 dollar/månad	Från 30 dollar/bidragsgivare/månad
Antal repositorier (gratis)	Upp till 10	Obegränsat (betald plan)
Regelspråk	YAML, öppet register	Samma, plus proprietära Pro-regler
AI-krediter per utvecklare/månad	60	20
CI/CD-drift	Egen konfiguration (semgrep scan)	Semgrep-infrastruktur, en klicks-deploy
Privata regler	Nej	Ja, för Teams och Enterprise
Stödda språk	35+	35+

Notera att gratisnivåns AI-kreditsiffra (60 krediter) faktiskt är högre än vad som ingår i den billigaste betalda nivån (20 krediter per utvecklare), enligt Semgreps prissida. Det är ovanligt i branschen och värt att räkna på om ditt team huvudsakligen vill använda AI-assisterad triage av fynd snarare än fler repositorier. För de flesta mindre team och open source-projekt räcker Community Edition gott, medan Pro-nivån blir motiverad när du behöver privata regler, garanterad support eller centraliserad policyhantering över många repositorier.

Ett praktiskt sätt att avgöra vilken nivå som passar är att räkna antal repositorier snarare än antal utvecklare. Ett team med fem utvecklare men bara två repositorier kommer långt på gratisnivån. En organisation med tjugo mikrotjänster fördelade över lika många repositorier når gränsen på tio repositorier snabbt och bör räkna på den betalda nivån redan från start, även om varje enskilt team är litet. Det är en annan prismodell än många konkurrerande verktyg, som ofta prissätter per utvecklare oavsett hur koden är strukturerad i repositorier.

Semgreps AI-funktioner, MCP och utvecklarverktyg

Utöver den klassiska regelbaserade skanningen har Semgrep byggt ut sitt AI-erbjudande under 2026. Enligt prissidan ingår ett visst antal AI-krediter per utvecklare och månad i både gratis- och betalnivåerna, tänkta att användas för AI-assisterad triage: att automatiskt föreslå om ett fynd är en verklig sårbarhet eller en falsk positiv, och i vissa fall föreslå en konkret kodändring. Det ersätter inte en säkerhetsgranskares bedömning, men det minskar tiden ett team lägger på att sortera igenom en lång lista med fynd efter en första skanning av en stor, obehandlad kodbas.

Semgrep har också byggt stöd för Model Context Protocol, MCP, vilket gör det möjligt att koppla in Semgreps skanningsfunktioner direkt i AI-assisterade kodredigerare och agentbaserade utvecklarverktyg. I praktiken innebär det att en AI-assistent kan anropa Semgrep som ett verktyg mitt i en kodgenereringssession, för att kontrollera att nyskriven kod inte introducerar samma sårbarhetsklasser som verktyget annars hade flaggat i efterhand. Det är fortfarande ett relativt nytt användningsområde, men det speglar en bredare trend där säkerhetsverktyg integreras tidigare i utvecklingsflödet snarare än att köras som en sista kontroll före release.

Rent praktiskt kopplas Semgrep även till vanliga utvecklarverktyg utanför AI-sfären. Enligt prissidan ingår integrationer mot Visual Studio Code och JetBrains-familjen som IDE-plugin, mot pull request- och merge request-flöden för direkt kommentering av fynd i kodgranskningen, samt mot Jira för att automatiskt skapa ärenden av fynd över en viss allvarlighetsgrad och mot Slack och e-post för notifieringar. En REST-API finns också tillgängligt för team som vill bygga egna integrationer mot interna verktyg för sårbarhetshantering i stället för att använda Semgreps färdiga kopplingar.

Vanliga fallgropar när team inför Semgrep

De flesta problem med Semgrep-införanden handlar inte om verktyget i sig utan om hur det rullas ut i en organisation. Ett team som infört Semgrep fel riskerar antingen att drunkna i brus eller att aldrig få verktyget accepterat av utvecklarna som ska leva med det dagligen. Här är de fallgropar som dyker upp oftast, och varför de uppstår.

• Att köra alla regelpaket från dag ett. Ett fullt --config=auto mot en stor, äldre kodbas ger ofta hundratals fynd som skrämmer bort utvecklare och gör att hela initiativet stämplas som brus redan innan det fått en chans. Börja smalt med ett fokuserat paket som p/secrets, visa att fynden är relevanta, och bygg ut täckningen därifrån i takt med att teamet ser värdet.
• Ingen baseline vid första körningen. Utan --baseline-ref blockeras varje pull request av gammal skuld som ingen i teamet skrev, vilket känns orättvist för den som råkar öppna en pull request samma dag som verktyget aktiveras. Sätt baseline innan du gör skanningen obligatorisk i CI, så att bara nya fynd blockerar bygget.
• Att blint lita på --config=auto i produktion. Autokonfigurationen hämtar regler från det publika registret vid varje körning, vilket gör resultaten svåra att reproducera exakt om registret uppdateras mellan två körningar av samma commit. Lås regelversionerna i CI, antingen genom att checka in regelfilerna eller genom att peka på en specifik registerversion, för reproducerbara resultat över tid.
• Att ignorera falska positiva i stället för att justera regeln. Ett team som bara klickar bort varningar utan att åtgärda grundorsaken tappar snabbt förtroendet för verktyget, och nästa gång en riktig sårbarhet flaggas riskerar den att avfärdas på samma sätt. Skriv om regeln eller lägg till ett riktat undantag med en tydlig motivering i stället för att bara stänga varningen.
• Att lägga hela mappar i .semgrepignore. Som nämnt i steg 14 gömmer det problemet i stället för att lösa det, och det är lätt att glömma varför undantaget en gång lades till när mappen växer och börjar innehålla ny applikationskod som borde skannas.
• Att glömma testa egna regler mot säker kod. En regel som bara testas mot ett sårbart exempel kan råka matcha helt ogiltig kod också, vilket i värsta fall skapar fler falska positiva än den verkliga sårbarhet regeln var tänkt att fånga. Testa alltid mot både positiva och negativa exempel med semgrep --test innan regeln aktiveras i CI.

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

Nedan är de problem som oftast dyker upp när team sätter upp Semgrep för första gången, tillsammans med hur du löser dem.

• “command not found: semgrep” efter installation. Python-binärens installationskatalog ligger ofta inte i PATH som standard, särskilt på macOS med flera Python-versioner installerade parallellt. Kör python3 -m pip show semgrep för att hitta installationsvägen och lägg till den i din shell-profil, eller installera om med pipx install semgrep som hanterar PATH automatiskt åt dig.
• Skanningen hänger sig eller tar orimligt lång tid på stora repositorier. Begränsa omfånget med --include och --exclude för att undvika att skanna genererad kod och stora datafiler, eller dela upp skanningen per katalog i separata CI-jobb som körs parallellt i stället för ett enda sekventiellt jobb.
• “No rules matched” trots att du angett en config. Kontrollera att sökvägen till YAML-filen är korrekt relativt din nuvarande katalog, och att filen faktiskt innehåller nyckeln rules: på rätt nivå i strukturen. Ett vanligt misstag är felaktig indentering som gör att Semgrep tolkar filen som tom.
• CI-jobbet failar men du ser inga fynd i loggen. Semgrep CI-läget kan avsluta med felkod av andra skäl än fynd, till exempel nätverksfel vid hämtning av regler från registret eller ett ogiltigt apptoken. Kör med flaggan --verbose för fullständig felutskrift och läs de sista raderna innan sammanfattningen.
• Regelfilen ger syntaxfel vid parsning. YAML är indenteringskänsligt och en enda felplacerad blanksteg kan göra hela filen ogiltig. Validera filen separat med python3 -c "import yaml,sys; yaml.safe_load(open(sys.argv[1]))" regler/min-regel.yaml innan du kör Semgrep mot den, så slipper du gissa var felet ligger.
• Samma sårbarhet flaggas i tusentals rader trots ett litet undantag. Kontrollera att nosemgrep-kommentaren står på exakt rätt rad, inte på raden ovanför eller inbäddad i en avslutande parentes, eftersom Semgrep bara läser undantaget om det ligger på samma rad som fyndet.
• Skanningen ger olika resultat lokalt och i CI. Oftast beror det på att --config=auto hämtat en nyare regelversion i CI än den som cachats lokalt på din utvecklarmaskin. Lås en specifik registerversion eller checka in regelfilerna i repot i stället för att alltid hämta senaste vid varje körning.
• Docker-containern kan inte nå filsystemet. Glöm inte volymmonteringen, det är den vanligaste orsaken till att en Docker-baserad körning rapporterar noll filer skannade. Kör docker run --rm -v "${PWD}:/src" semgrep/semgrep semgrep scan --config=auto /src så att containern faktiskt ser din kod på sökvägen /src.
• Pre-commit-hooken körs inte alls. Kontrollera att du faktiskt kört pre-commit install i repot, eftersom hook-konfigurationen i .pre-commit-config.yaml bara läses av git om hooken är registrerad lokalt hos varje utvecklare.

Avancerade tips för erfarna användare

När grundflödet sitter finns det flera sätt att få mer värde ur Semgrep. Flaggan --x-dependency-paths, som lades till i version 1.168, visar hela beroendekedjan bakom en Supply Chain-varning i stället för bara det direkta paketet, vilket gör det lättare att avgöra om en sårbarhet går att åtgärda med en enkel versionsuppdatering eller kräver att ett helt beroende byts ut.

Ett annat tips är att kombinera Semgreps SAST-fynd med resultat från en secrets-skanner som Gitleaks och en containerskanner som Trivy i samma pipeline. De tre verktygen täcker olika lager, kod, hemligheter i historik och sårbara paket i imagen, och tillsammans ger de en betydligt bredare bild än något av dem gör ensamt. Många team kör dem som separata jobb i samma GitHub Actions-workflow och samlar resultaten i ett gemensamt dashboard via SARIF-format, som samtliga tre verktyg kan exportera till.

För team som redan har IDE-integration är det värt att aktivera Semgreps VS Code- eller JetBrains-plugin, vilket enligt Semgreps prissida ingår i både gratis- och betalnivåerna. Det flyttar feedbacken från “efter pull request” till “medan du skriver koden”, vilket i praktiken är den billigaste tidpunkten att fixa ett fel på eftersom det aldrig hinner committas.

Ett sista tips är att inte behandla regeluppsättningen som statisk. Gå igenom vilka regler som faktiskt genererar åtgärdade fynd kontra vilka som bara skapar brus en gång i kvartalet, och stäng av eller skriv om de regler som konsekvent ger falska positiva i just din kodbas. Ett regelset som underhålls aktivt av teamet som äger koden ger betydligt högre träffsäkerhet över tid än ett som bara aktiverades en gång och sedan lämnades orört.

Prestanda och skalning i stora kodbaser

Ju större monorepo, desto viktigare blir det att tänka på skanningstid. Semgreps releaseanteckningar för veckan 31 augusti-6 september 2026 nämner en konkret förbättring: skanningskonfigurationen genereras snabbare, vilket enligt samma anteckningar gör att skanningar kan starta upp till sex sekunder tidigare. Det låter marginellt, men i en pipeline som kör hundratals gånger om dagen över ett helt team summerar sekunderna snabbt.

Praktiska knep för stora kodbaser inkluderar att köra --baseline-ref i varje pull request så att bara ändrade filer skannas fullt ut, att dela upp monorepot i flera parallella CI-jobb per undermapp, och att undvika att köra breda regelpaket som p/default vid varje enskild commit. Ett vanligt mönster är att köra ett smalt, snabbt regelpaket vid varje push och ett bredare, tyngre paket en gång per dygn eller vid merge till huvudgrenen.

Minneskonsumtion är en annan faktor som ofta glöms bort. På CI-runners med begränsat minne kan en full skanning av ett stort monorepo konkurrera med andra byggsteg om samma resurser. Om skanningen kraschar eller blir onormalt långsam i just den situationen, testa att köra Semgrep som ett separat jobb med egen resurstilldelning snarare än som ett steg i ett redan tungt byggjobb, så att de inte konkurrerar om samma minne och CPU samtidigt.

Semgrep, NIS2 och den svenska säkerhetskontexten

För svenska och nordiska organisationer som omfattas av NIS2-lagstiftningen är kodgranskning en del av det som tillsynsmyndigheter förväntar sig ska dokumenteras som en del av riskhanteringen i mjukvaruutvecklingen. Ett SAST-verktyg som Semgrep ger inte i sig efterlevnad, men det ger ett spårbart underlag: vilka regler som körts, vilka fynd som identifierats och hur de åtgärdats över tid. Det underlaget är precis det som blir relevant om en incident inträffar och en tillsynsprocess ska visa att organisationen haft rimliga tekniska kontroller på plats.

Kombinationen av kodanalys, beroendeskanning och hemlighetsdetektion byggs ofta upp stegvis i svenska utvecklingsteam, där Semgrep vanligen är det första steget eftersom det kräver minst infrastruktur att komma igång med. Ett team som redan använder OSV-Scanner för beroenden eller Gitleaks för hemligheter i historiken kan lägga till Semgrep som ett tredje lager utan att behöva bygga om befintlig pipeline-infrastruktur, eftersom samtliga tre verktyg körs som fristående kommandoradsverktyg i samma CI-miljö.

Det är också värt att komma ihåg att ett verktyg som Semgrep bara är en del av en bredare säkerhetsprocess. Regelbunden granskning av containerimages med ett verktyg som Trivy, signering av byggartefakter med Cosign och en dokumenterad incidentplan enligt NIS2-kraven hör alla till samma helhet. Poängen med att sätta upp SAST tidigt i det arbetet är att det fångar den typ av fel som annars riskerar att upptäckas långt senare, ibland först när en extern part rapporterar en sårbarhet eller när en incident redan skett.

Vanliga frågor om Semgrep

Är Semgrep gratis att använda?
Community Edition är gratis utan begränsning i tid, men gratisnivån för molnfunktioner som centraliserad policyhantering är begränsad till tio repositorier enligt Semgreps prissida. Kommandoradsverktyget i sig kan du köra lokalt mot hur många repositorier du vill utan kostnad.

Ersätter Semgrep behovet av manuell kodgranskning?
Nej. Semgrep fångar mönsterbaserade fel som saknad indatavalidering eller hårdkodade hemligheter, men verktyget förstår inte affärslogik eller komplexa behörighetsflöden på samma sätt som en erfaren granskare. Det bästa resultatet får du genom att låta Semgrep ta de mekaniska, upprepbara felen så att mänsklig granskning kan fokusera på logik och arkitektur.

Vilken skillnad är det mellan semgrep scan och semgrep ci?
semgrep scan är det generella kommandot för lokala körningar och anpassade konfigurationer. semgrep ci är byggt specifikt för pipelines, känner av kontext som pull request kontra huvudgren och kan skicka resultat till Semgreps molnplattform om en apptoken är satt.

Kan Semgrep hitta sårbarheter i tredjepartsbibliotek?
Det är vad Supply Chain-delen av produkten är till för, skild från kärnfunktionen SAST som granskar din egen kod. För ren beroendeskanning används ofta ett dedikerat verktyg som OSV-Scanner tillsammans med Semgrep, snarare än att förlita sig på ett enda verktyg för båda uppgifterna.

Hur många falska positiva ska jag förvänta mig?
Det varierar kraftigt beroende på vilka regelpaket som körs och hur specifikt anpassade de är till din kodbas. Generiska paket som p/security-audit ger fler falska positiva i ovanliga kodmönster, medan egna, smalt skrivna regler mot kända interna mönster ger färre. Justera regler löpande i stället för att acceptera en hög andel brus.

Fungerar Semgrep med monorepos?
Ja, men stora monorepos kräver att du tänker igenom skanningsstrategin enligt avsnittet om prestanda ovan. Dela upp skanningen per undermapp och använd --baseline-ref för att undvika att varje pull request skannar hela repot på nytt.

Vad händer med det gamla policysystemet efter migreringen till Unified Policies?
Enligt Semgreps egna releaseanteckningar började migreringen till Unified Policies den 24 augusti 2026, och det tidigare policysystemet sunsettas den 1 november 2026. Organisationer som fortfarande kör det gamla systemet bör planera migreringen i god tid innan dess.

Kan jag köra Semgrep helt offline, utan att hämta regler från internet?
Ja. Du kan ladda ner regelpaket i förväg och peka semgrep scan mot en lokal katalog eller enskild YAML-fil i stället för att använda --config=auto, som alltid hämtar från det publika registret online. Det är särskilt relevant i miljöer med begränsad eller reglerad internetåtkomst, till exempel vissa myndighetsnätverk, där varje utgående anslutning måste godkännas separat.