I början av september 2026 fick användare av HashiCorp Vault en påminnelse om hur snabbt ett enda beroende kan bli ett säkerhetsproblem. Vault 2.1.0 patchade en sårbarhet i Go-paketet software.sslmate.com/src/go-pkcs12, spårad som GO-2026-5052, genom att helt enkelt uppdatera en beroendeversion. Samma vecka släppte nätverksverktyget Suricata version 8.0.7, som utvecklarna själva beskrev som releasen med flest rapporterade sårbarheter någonsin i projektets historia. Mönstret är tydligt: de flesta säkerhetsproblem 2026 dyker inte upp i din egen kod, utan i de tusentals paket din applikation bygger på. Det är exakt det problemet OSV-Scanner löser, och i den här guiden bygger vi ett komplett arbetsflöde för att hitta och åtgärda sårbara beroenden innan de blir din nästa incident.
Ett modernt Node.js- eller Python-projekt drar in hundratals transitiva beroenden utan att en enda utvecklare medvetet har valt dem. Varje sådant paket är en möjlig ingång för en angripare, och ingen enskild person i teamet hinner läsa igenom källkoden för samtliga. Det är därför automatiserad skanning mot en aktuell sårbarhetsdatabas har gått från “trevligt att ha” till en grundläggande del av mjukvaruleveranskedjan, oavsett om du bygger en intern verktygslåda eller en produkt som säljs till offentlig sektor. Den här guiden går igenom installation, dagliga arbetsflöden, CI/CD-integration och felsökning i tolv konkreta steg, byggt kring OSV-Scanner v2.6.0.
Vad är OSV-Scanner och varför behövs det 2026
OSV-Scanner är ett kommandoradsverktyg från Google, skrivet i Go, som jämför projektets beroenden mot OSV.dev, en öppen databas över kända sårbarheter i open source-paket. Google beskriver verktyget som “en officiellt underhållen frontend till OSV-databasen som kopplar ett projekts lista över beroenden till de sårbarheter som påverkar dem”, enligt projektets GitHub-repository. Verktyget lanserades först i december 2022, då Google-teamet skrev att målet var att ge “utvecklare av öppen källkod enkel tillgång till sårbarhetsinformation som är relevant för deras projekt”, enligt Google Security Blog.
Den senaste stabila versionen, OSV-Scanner v2.6.0, släpptes den 14 september 2026 enligt projektets officiella releasesida på GitHub. Releasen är den 55:e i projektets historia och innehåller bland annat uppdateringar till den interna komponenten osv-scalibr, som hanterar själva inventeringen av paket och filer, samt en fix som grupperar sårbarhetsträffar per exakt ekosystem istället för att blanda ihop resultat från olika paketkällor. En annan förbättring i v2.6.0 gör att skanningen returnerar ett tydligt fel om en angiven containeravbildning saknas, istället för att tyst hoppa över den.
Så fungerar OSV.dev-databasen
OSV.dev samlar sårbarhetsdata från flera ekosystem, bland annat npm, PyPI, crates.io, Go, Maven och Linux-distributioner, i ett enhetligt format. Enligt projektets dokumentation gör detta att utvecklare kan “identifiera kända sårbarheter i tredjeparts open source-beroenden som utgör en verklig risk för applikationen och dess miljö, så att de kan fokusera åtgärdsarbetet på de sårbarheter som spelar roll”, enligt OSV.dev:s dokumentation. Istället för att bara varna om att ett paket har en känd CVE, försöker OSV.dev och OSV-Scanner avgöra om just din version av paketet faktiskt innehåller den sårbara koden, vilket minskar antalet falska positiva jämfört med äldre skanningsmetoder.
Skillnaden mot äldre skanningsverktyg är i praktiken märkbar redan från första körningen. Ett vanligt problem med enklare CVE-lexikon är att de matchar på paketnamn och grov versionsräkning, vilket ofta ger en lång lista av teoretiska risker som säkerhetsteamet sedan måste manuellt sålla igenom. OSV.dev:s format inkluderar exakta drabbade versionsintervall per commit där det är möjligt, vilket gör att OSV-Scanner kan avgöra om just din låsta version faktiskt omfattas innan den ens hamnar i rapporten. Resultatet är färre rader att gå igenom, men varje rad väger tyngre.
Förkunskaper och verktyg du behöver
Du behöver inte vara Go-utvecklare för att använda OSV-Scanner, men du bör känna till grunderna i kommandoraden och git. Guiden tar cirka 75 minuter att gå igenom om du följer alla steg, inklusive CI/CD-integrationen. Se till att följande finns på plats innan du börjar.
| Verktyg | Version / krav | Syfte |
|---|---|---|
| OSV-Scanner | v2.6.0 (senaste stabila) | Själva skanningsverktyget |
| Operativsystem | Linux, macOS eller Windows | Verktyget är plattformsoberoende |
| Go (valfritt) | 1.22 eller senare | Krävs endast om du installerar via go install |
| Docker (valfritt) | Senaste versionen | Krävs för containerbaserad körning och image-skanning |
| Git | Senaste versionen | För att klona testprojekt och versionshantera konfiguration |
| GitHub- eller GitLab-konto | – | För CI/CD-integrationen längre fram i guiden |
Du behöver också ett projekt att testa på. Har du inget eget till hands duger vilket repo som helst med en package.json, requirements.txt, go.mod eller liknande lockfil, eftersom det är dessa filer OSV-Scanner läser för att bygga en lista över dina beroenden.
Har teamet redan en etablerad rutin för statisk kodanalys eller hemlighetsskanning, till exempel med Gitleaks för att hitta läckta API-nycklar, passar OSV-Scanner naturligt in som ytterligare ett steg i samma pipeline snarare än ett fristående initiativ. De löser olika problem, hemligheter i kod kontra sårbara paket, men konfigureras och triggas på liknande sätt.
Steg 1-2: Installera OSV-Scanner
Det finns tre huvudsakliga sätt att installera OSV-Scanner: via Homebrew, via go install, eller genom att köra den officiella Docker-avbildningen. Välj den metod som passar din arbetsmiljö bäst.
# Alternativ 1: Homebrew (macOS och Linux)
brew install osv-scanner
# Alternativ 2: go install (kräver Go 1.22+)
go install github.com/google/osv-scanner/v2/cmd/[email protected]
# Alternativ 3: Docker, ingen lokal installation krävs
docker pull ghcr.io/google/osv-scanner:latestPå Windows kan du ladda ner den fristående binärfilen direkt från releasesidan och lägga till den i din PATH manuellt. Kör du via Docker slipper du helt att hantera Go-verktygskedjan lokalt, vilket är praktiskt om du bara vill testa verktyget snabbt eller köra det i en byggmiljö där du inte kontrollerar vilka språk som är installerade.
Ett litet men värt påpekande: pinna alltid en specifik version i skript och CI-konfiguration, som i exemplet ovan med @v2.6.0, i stället för att peka på latest. Det gör att en oväntad förändring i skanningsbeteende mellan versioner aldrig kommer som en överraskning mitt i en release, och att alla i teamet kör exakt samma kontroller lokalt som i CI.
Steg 3: Verifiera installationen
Innan du börjar skanna riktiga projekt, kontrollera att installationen fungerar och att du har rätt version.
osv-scanner --versionKommandot ska skriva ut versionsnumret, i det här fallet osv-scanner version: 2.6.0 följt av byggdatum och commit-hash. Får du “command not found” i stället, kontrollera att katalogen där binärfilen ligger (till exempel $HOME/go/bin vid installation via go install) finns med i din PATH-variabel.
Steg 4: Skanna ditt första projekt
Navigera till roten av ett projekt som innehåller en lockfil och kör en grundläggande skanning. OSV-Scanner v2 använder ett underkommando, scan source, för filbaserade skanningar.
cd mitt-projekt
osv-scanner scan source .Verktyget letar automatiskt upp kända lockfilstyper i katalogen, till exempel package-lock.json, yarn.lock, poetry.lock, requirements.txt, go.sum och Cargo.lock, extraherar exakta paketversioner och slår upp varje paket mot OSV.dev. Har du ett projekt med flera språk i samma repo, till exempel en Node.js-frontend och en Python-backend, hittar OSV-Scanner beroenden från båda utan extra konfiguration.
Steg 5: Tolka resultatet
Standardutdata är en tabell i terminalen. Ett typiskt resultat från ett medelstort Node.js-projekt kan se ut så här.
Scanning dir ./mitt-projekt
Scanned package-lock.json file and found 412 packages
+-----------------------+------+-----------+---------------+---------+
| OSV URL | CVSS | ECOSYSTEM | PACKAGE | VERSION |
+-----------------------+------+-----------+---------------+---------+
| osv.dev/GHSA-xxxx-yyyy| 7.5 | npm | lodash.merge | 4.6.1 |
| osv.dev/GHSA-aaaa-bbbb| 9.1 | npm | node-fetch | 2.6.0 |
+-----------------------+------+-----------+---------------+---------+Varje rad pekar mot en specifik sårbarhetspost på OSV.dev, som innehåller beskrivning, drabbade versionsintervall och länkar till patchar. CVSS-kolumnen ger dig en snabb prioriteringssignal, men behandla den som en utgångspunkt snarare än facit. Ett paket med CVSS 9.1 som bara används i ett testskript som aldrig når produktion är ofta mindre akut än ett paket med CVSS 7.5 som körs i din publika API-gateway. Vill du bearbeta resultatet programmatiskt, lägg till --format json för strukturerad utdata som passar i skript och CI-pipelines.
Så prioriterar du en lång lista med fynd
Ett projekt som skannas för första gången ger sällan en kort, hanterbar lista. Snarare än att försöka åtgärda allt på en gång, sortera fynden i tre enkla köer utifrån exponering och allvarlighetsgrad. Den här grova modellen, byggd på CVSS-intervall kombinerat med var paketet faktiskt används, brukar räcka för att komma igång utan att drunkna i detaljer redan första dagen.
| Kö | CVSS-intervall | Typisk åtgärd | Rekommenderad tidsram |
|---|---|---|---|
| Akut | 9.0–10.0 i internetexponerad kod | Patcha eller mitigera omedelbart, eskalera till ansvarig ägare | Samma dag till 48 timmar |
| Hög prioritet | 7.0–8.9, eller lägre i kritisk tjänst | Planera in i närmast kommande sprint | 1–2 veckor |
| Löpande underhåll | Under 7.0 i icke-exponerad kod | Samla ihop och åtgärda vid nästa beroendeuppdatering | Nästa planerade uppgradering |
Den här indelningen är medvetet enkel. Syftet är inte att ersätta en riktig riskbedömning utan att ge teamet ett sätt att komma igång samma dag som den första rapporten landar, i stället för att fastna i en lång diskussion om exakt hur allvarligt varje enskilt fynd är innan något över huvud taget åtgärdas. Vill du fördjupa hur allvarlighetsgrader faktiskt beräknas, går vår guide om CVSS 4.0 och CVE-bevakning igenom modellen i detalj.
Steg 6: Skanna rekursivt i stora projekt
Monorepos och större kodbaser har ofta lockfiler spridda i flera underkataloger, till exempel en per mikrotjänst. Lägg till flaggan -r för att söka igenom hela katalogträdet.
osv-scanner scan source -r .På stora repon med hundratals underprojekt kan detta ta betydligt längre tid, eftersom varje unik lockfil genererar en egen uppsättning uppslag mot OSV.dev. Ett vanligt mönster i CI är att begränsa rekursiv skanning till specifika kataloger med hjälp av .gitignore-liknande exkluderingsregler, så att exempelvis node_modules eller genererade byggartefakter inte skannas i onödan.
Steg 7: Skanna SBOM-filer
Om din organisation redan genererar en Software Bill of Materials i formatet CycloneDX eller SPDX, kan OSV-Scanner läsa den filen direkt i stället för att analysera lockfiler på nytt. Det är särskilt värdefullt om SBOM:en kommer från en leverantör och du inte har tillgång till källkoden själv.
osv-scanner scan source --sbom=./sbom.cdx.jsonDetta gör OSV-Scanner till ett naturligt komplement till separata SBOM-genereringsverktyg: SBOM:en beskriver vad som ingår i mjukvaran, medan OSV-Scanner svarar på om något av det innehållet faktiskt är sårbart just nu. I takt med att fler upphandlingar i offentlig sektor och NIS2-relaterade leverantörskrav efterfrågar SBOM som leveransformat, blir förmågan att skanna dem direkt allt viktigare för inköpande organisationer. Har ni ännu ingen etablerad process för att generera SBOM:ar, är vår guide om SBOM och leveranskedjesäkerhet ett bra ställe att börja.
Steg 8: Skanna containeravbildningar
Många sårbarheter hamnar inte i din applikationskod utan i baslagren av din Docker-avbildning: operativsystempaket, systembibliotek och runtime-verktyg som följer med basimagen. Skanna en byggd avbildning så här.
osv-scanner scan image mitt-projekt:latestI v2.6.0 returnerar kommandot numera ett tydligt felmeddelande om avbildningen inte hittas lokalt, en direkt konsekvens av en fix i den här releasen som beskrivs i release-anteckningarna. Tidigare kunde en felskriven bildtagg tyst hoppas över, vilket gav en falsk känsla av trygghet: en “ren” rapport som i själva verket berodde på att skanningen aldrig kom åt bilden. Kör alltid docker images för att bekräfta att taggen finns lokalt innan du litar på ett tomt resultat.
Skanna avbildningen efter bygg men före publicering till ert register, så att en sårbar basimage eller ett systempaket med känd sårbarhet aldrig hinner nå en publik registerplats. Många team lägger detta som ett separat steg direkt efter docker build i CI, med samma exit code-logik som filbaserad skanning: en icke-nollstatus stoppar publiceringssteget automatiskt.
Steg 9: Ignorera falska positiva med konfigurationsfil
Inte alla träffar kräver omedelbar åtgärd. Kanske är paketet bara en dev-dependency som aldrig paketeras i produktion, eller så har du redan bedömt risken och beslutat att vänta på nästa större versionsuppgradering. Skapa en osv-scanner.toml i projektroten för att dokumentera sådana beslut i stället för att bara ignorera varningarna i huvudet.
[[IgnoredVulns]]
id = "GHSA-xxxx-yyyy-zzzz"
reason = "Endast använt i testmiljö, patchas vid nästa sprintavstämning"
[[IgnoredVulns]]
id = "GHSA-aaaa-bbbb-cccc"
reason = "Falsk positiv, koden i sårbar funktion nås aldrig"Kör sedan skanningen med --config=osv-scanner.toml så exkluderas de dokumenterade posterna från framtida rapporter, men filen fungerar samtidigt som ett granskningsbart register över medvetna risktaganden, vilket är användbart vid interna säkerhetsgenomgångar eller revisioner.
Steg 10: Integrera i GitHub Actions
Manuella skanningar hittar problem för sent, ofta efter att koden redan har mergats. Lägg in OSV-Scanner som en obligatorisk kontroll i din CI-pipeline så att sårbara beroenden stoppas redan i pull request-steget.
name: osv-scanner
on:
pull_request:
push:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Installera OSV-Scanner
run: go install github.com/google/osv-scanner/v2/cmd/[email protected]
- name: Kör skanning
run: osv-scanner scan source -r . --format=tableMed detta på plats får varje pull request en automatisk kontroll, och bygget markeras som misslyckat om skanningen hittar sårbarheter med icke-nollstatus (exit code 1). Vill du bara varna utan att blockera merge under en övergångsperiod, lägg till continue-on-error: true på steget tills teamet har hunnit rensa upp i befintlig skuld.
Steg 11: Integrera i GitLab CI
Motsvarande integration i GitLab CI görs som ett eget jobb i pipelinen, lämpligen med Docker-avbildningen för att slippa installera Go i byggmiljön.
osv-scan:
stage: test
image: ghcr.io/google/osv-scanner:latest
script:
- osv-scanner scan source -r . --format=json --output=osv-report.json
artifacts:
paths:
- osv-report.json
when: alwaysAtt spara rapporten som en artefakt gör att teamet kan gå tillbaka och jämföra resultat mellan körningar, vilket är särskilt värdefullt när ni vill visa en trend över tid, till exempel inför en revision kopplad till leverantörskrav eller NIS2-rapportering.
Steg 12: Bygg ett komplett exempelprojekt
Sätt nu ihop stegen till ett fullständigt, återanvändbart arbetsflöde. Följande struktur fungerar som utgångspunkt för de flesta projekt, oavsett språk.
mitt-projekt/
├── osv-scanner.toml # ignore-regler och undantag
├── .github/workflows/
│ └── osv-scanner.yml # CI-kontroll på varje PR
├── scripts/
│ └── scan-lokalt.sh # snabb lokal koll före commit
├── package-lock.json # eller motsvarande lockfil
└── src/
# scripts/scan-lokalt.sh
#!/usr/bin/env bash
set -e
echo "Kör OSV-Scanner lokalt..."
osv-scanner scan source -r . --config=osv-scanner.toml --format=table
echo "Klart. Inga blockerande sårbarheter hittades."Kör scan-lokalt.sh innan varje commit av vana, låt CI-jobbet från steg 10 fånga allt som ändå slinker igenom, och låt osv-scanner.toml vara det levande dokumentet där teamet motiverar sina undantag. Det tredelade upplägget, lokal koll, CI-grind och dokumenterade undantag, täcker de flesta scenarier utan att bli en administrativ börda.
Testa hela flödet end-to-end genom att medvetet lägga till ett känt sårbart paket i en testgren, till exempel en gammal version av lodash eller node-fetch, och verifiera att den lokala skriptet, CI-jobbet och ignore-listan alla beter sig som förväntat. Ta sedan bort testberoendet innan grenen mergas. Den här typen av kontrollerad brandövning avslöjar snabbt om något steg i kedjan är felkonfigurerat, till exempel om CI-jobbet av misstag pekar på fel katalog eller om ignore-filen inte laddas alls, långt innan ett riktigt fynd dyker upp och ingen märker att larmet aldrig gick fram.
Vanliga fallgropar
- Att skanna utan att committa lockfilen. Utan en exakt lockfil kan OSV-Scanner bara gissa versioner utifrån versionsintervall i manifestfiler, vilket ger sämre precision. Committa alltid
package-lock.json,poetry.lockeller motsvarande. - Att blockera hela pipelinen från dag ett. Ett första körning på ett moget projekt ger ofta dussintals träffar. Börja med en varningsläge, städa upp historisk skuld, och slå sedan på hård blockering.
- Att lita blint på tomma resultat vid image-skanning. Som beskrivet i steg 8 kunde äldre versioner tyst missa saknade avbildningar. Verifiera alltid att rätt tagg faktiskt skannades.
- Att ignorera CVSS-poäng utan kontext. Ett högt CVSS-värde säger inget om huruvida den sårbara koden faktiskt nås i din applikation. Prioritera efter exponering, inte bara siffran.
- Att glömma bort transitiva beroenden. De flesta sårbarheter dyker inte upp i dina direkta beroenden utan i beroenden till dina beroenden. Lockfil-baserad skanning fångar detta automatiskt, men manuell granskning av
package.jsongör det inte. - Att köra skanningen sällan. Nya sårbarheter publiceras löpande i OSV.dev. Ett projekt som skannades rent för tre månader sedan kan vara sårbart idag utan att en enda rad kod har ändrats.
- Att sätta ignore-regler utan utgångsdatum. En rad i
osv-scanner.tomlsom skrevs för att “vänta ut” en sårbarhet blir lätt permanent om ingen påminns om att ompröva den. Skriv alltid ett datum i motiveringsfältet och gör en enkel rutin av att granska filen kvartalsvis. - Att blanda ihop utvecklingsberoenden med produktionsberoenden i prioriteringen. Ett sårbart testverktyg som aldrig når en produktionsserver ska hanteras annorlunda än ett sårbart bibliotek som körs i den publika API-ytan, även om båda dyker upp i samma rapport.
Felsökning
De flesta problem med OSV-Scanner handlar om sökvägar, versioner eller saknade filer snarare än buggar i själva verktyget. Nedanstående tabell samlar de vanligaste felen vi stötte på när vi byggde exempelprojektet i steg 12, tillsammans med den snabbaste vägen till en lösning.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| “command not found: osv-scanner” | Binärfilen finns inte i PATH | Kontrollera installationssökväg, lägg till i PATH eller kör om installationskommandot |
| Skanningen hittar noll paket | Ingen känd lockfil i katalogen | Kontrollera att lockfilen har standardnamn och ligger i rätt katalog, eller ange den explicit med -L |
| Container-skanning ger tomt resultat | Avbildningen finns inte lokalt | Kör docker pull eller docker build innan skanning, verifiera med docker images |
| Väldigt långsam skanning på monorepo | Rekursiv skanning genomsöker onödiga kataloger | Exkludera node_modules, byggkataloger och vendor-mappar |
| Ignore-regler i osv-scanner.toml verkar inte fungera | Konfigurationsfilen anges inte i kommandot | Lägg till --config=osv-scanner.toml explicit vid varje körning |
| CI-jobbet misslyckas trots att inga nya sårbarheter lagts till | OSV.dev har publicerat en ny sårbarhet i ett befintligt beroende | Detta är förväntat beteende, inte ett fel. Åtgärda eller dokumentera undantag |
| JSON-utdata går inte att parsa i skript | Både stdout och statusmeddelanden skrivs till samma ström | Använd --output=fil.json för att skriva ren JSON till fil |
| Go install misslyckas med modulfel | Fel eller för gammal Go-version | Uppgradera till Go 1.22 eller senare, kör go version för att bekräfta |
| Olika resultat lokalt jämfört med CI | Olika versioner av OSV-Scanner används | Pinna exakt version, till exempel @v2.6.0, i både lokala skript och CI-konfiguration |
Avancerade tips
När grundflödet sitter finns det flera sätt att skärpa användningen ytterligare. Kombinera --format=sarif med kodgranskningsverktyg som stödjer SARIF-formatet, så att sårbarheter visas direkt som kommentarer i pull requests snarare än i en separat loggfil som ingen läser. Sätt upp en schemalagd nattlig körning utöver PR-grinden, eftersom nya sårbarheter i OSV.dev kan göra ett tidigare “rent” projekt sårbart utan att en enda rad kod ändrats i repot.
För organisationer med många repon, bygg ett centralt dashboard genom att samla JSON-utdata från varje projekts CI-körning i en gemensam datalagring, till exempel en enkel S3-bucket eller ett internt API. Det ger säkerhetsteamet en översikt över hela portföljens exponering i stället för att behöva logga in i varje enskild pipeline. Slutligen: koppla ihop OSV-Scanners resultat med din patchhanteringsprocess, så att en hög CVSS-poäng automatiskt skapar ett ärende i ert ärendehanteringssystem med rätt prioritet och ägare, i stället för att bara ligga kvar i en byggloggen.
En annan vanlig utbyggnad är att köra OSV-Scanner som en del av release-processen, inte bara vid varje commit. Lägg till ett skanningssteg direkt innan en tagg eller release skapas, och blockera releasen helt om verktyget hittar sårbarheter med känd, aktivt utnyttjad status. Vill du gå längre, kombinera resultatet med interna telemetridata om vilka tjänster som faktiskt exponeras mot internet, så att prioriteringen tar hänsyn till verklig attackyta i stället för att behandla alla fynd lika.
OSV-Scanner jämfört med andra verktyg
OSV-Scanner är inte ensamt på marknaden för beroendeskanning. Trivy, som ursprungligen är mest känt för containerskanning, och Grype, som fokuserar specifikt på sårbarhetsskanning av avbildningar och filsystem, löser delvis överlappande problem. Skillnaden ligger ofta i datakälla och integrationsdjup.
Väljer du mellan dem, fråga dig först vad ni faktiskt behöver täcka. Ett team som redan har byggt ett helt arbetsflöde kring Trivy för containerskanning behöver inte nödvändigtvis byta ut det, men kan lägga till OSV-Scanner specifikt för applikationsberoenden där dess OSV.dev-baserade precision gör skillnad. Ett team som börjar från noll och bara har ett CI-system utan tidigare skanningsverktyg gör klokt i att starta med OSV-Scanner just eftersom det är gratis, snabbt att sätta upp och inte kräver något konto.
| Verktyg | Primär datakälla | Starkast på | Licens |
|---|---|---|---|
| OSV-Scanner | OSV.dev | Lockfiler, SBOM, transitiva beroenden | Apache 2.0, gratis |
| Trivy | Flera databaser inkl. NVD, GHSA | Containeravbildningar, IaC-konfiguration | Apache 2.0, gratis |
| Grype | Anchore-databas + flera källor | Filsystem- och imageskanning | Apache 2.0, gratis |
| Snyk | Egen kommersiell databas | Utvecklarupplevelse, IDE-integration | Kommersiell, gratisnivå finns |
I praktiken använder många team flera av dessa verktyg parallellt: OSV-Scanner för snabb, gratis beroendekontroll direkt i CI, och ett bredare verktyg som Trivy för containerlagrens operativsystempaket. Ingen av dem ersätter behovet av att faktiskt läsa och agera på rapporterna, oavsett hur bra själva skanningsmotorn är.
OSV-Scanner för svenska och nordiska team
Kraven på spårbarhet i mjukvaruleveranskedjan har skärpts i takt med att NIS2-direktivet implementerats i svensk lag via cybersäkerhetslagen. Organisationer som klassas som samhällsviktiga eller viktiga entiteter förväntas kunna redogöra för vilka komponenter deras system bygger på och hur snabbt kända sårbarheter åtgärdas. Läs mer om vad lagen konkret kräver av patchhantering i vår genomgång av patchhantering och kända, aktivt utnyttjade sårbarheter. Ett verktyg som OSV-Scanner löser inte hela den uppgiften på egen hand, men det ger en konkret, körbar del av svaret: en maskinläsbar rapport över exakt vilka kända sårbarheter som finns i produktionskoden just nu, och när de först upptäcktes.
För leverantörer till offentlig sektor i Sverige och övriga Norden blir detta även en försäljningsfråga. Fler upphandlingar efterfrågar dokumenterad hantering av öppen källkod, ibland i form av en SBOM som ska kunna verifieras. Att kunna visa en logg av regelbundna OSV-Scanner-körningar, kopplad till en dokumenterad process för att åtgärda eller motivera undantag via osv-scanner.toml, är ett konkret sätt att svara på den typen av krav utan att bygga ett helt eget compliance-system från grunden. Samma logik gäller mindre svenska scale-ups som säljer till större nordiska koncerner, där leverantörsgranskning av mjukvarusäkerhet blivit standard snarare än undantag.
Sammanfattning
OSV-Scanner v2.6.0 ger dig ett gratis, snabbt och aktivt underhållet sätt att hitta kända sårbarheter i dina beroenden, från enskilda lockfiler till fullständiga containeravbildningar och SBOM-filer. Installationen tar minuter, den första skanningen tar sekunder, och den verkliga vinsten kommer när du kopplar in verktyget i CI/CD så att varje pull request automatiskt kontrolleras. Kombinerat med en dokumenterad ignore-lista och en rutin för regelbunden omskanning, får du ett arbetsflöde som fångar det Vault-teamet och Suricata-teamet redan har lärt sig 2026: sårbarheter i beroendekedjan dyker upp kontinuerligt, och den enda hållbara strategin är att skanna lika kontinuerligt tillbaka. Fler praktiska guider inom området hittar du i vår samlade bevakning av cybersäkerhet.
Vanliga frågor om OSV-Scanner
Är OSV-Scanner gratis att använda?
Ja. OSV-Scanner är ett öppen källkod-projekt från Google under Apache 2.0-licens, utan kostnad för kommersiell eller privat användning, och kräver inget konto eller API-nyckel för grundläggande skanning mot OSV.dev.
Vilka programmeringsspråk och ekosystem stöds?
OSV-Scanner läser lockfiler från de flesta stora ekosystem, bland annat npm, PyPI, RubyGems, crates.io, Go-moduler, Maven och NuGet, eftersom OSV.dev aggregerar sårbarhetsdata från samtliga dessa källor.
Kan OSV-Scanner skanna privata, interna paket?
Verktyget kan läsa lockfiler som innehåller referenser till privata paket, men eftersom OSV.dev bara innehåller data om öppna, publikt kända sårbarheter kommer interna paket utan publicerade CVE:er eller GHSA-poster inte ge några träffar. Skanningen är i grunden ett uppslag mot en öppen databas, inte en statisk kodanalys av din egen kodbas.
Skiljer sig OSV-Scanner från Dependabot eller GitHub Security Advisories?
De löser ett liknande problem men på olika sätt. Dependabot är inbyggt i GitHub och skapar automatiska pull requests för uppgraderingar, medan OSV-Scanner är ett fristående CLI-verktyg som fungerar oavsett var koden hostas, och som du själv styr helt i din egen pipeline.
Hur ofta bör jag köra en skanning?
Minst vid varje pull request, samt via en schemalagd nattlig eller veckovis körning på huvudgrenen. Eftersom nya sårbarheter publiceras löpande i OSV.dev kan ett projekt som skannades rent förra veckan vara sårbart idag, utan att koden ändrats.
Fungerar OSV-Scanner med Docker Compose-projekt med flera tjänster?
Ja, kör en skanning per byggd avbildning med osv-scanner scan image, eller skanna hela repots källkodsmapp rekursivt med -r om varje tjänst har sin egen lockfil i en undermapp.
Vad gör jag om en sårbarhet saknar patch?
Dokumentera beslutet i osv-scanner.toml med en tydlig motivering och ett datum för omprövning, bedöm om paketet kan bytas ut mot ett alternativ, och begränsa exponeringen genom nätverkssegmentering eller åtkomstkontroll tills en patch finns tillgänglig.
Kan jag använda OSV-Scanner tillsammans med Trivy eller Grype i samma pipeline?
Absolut, och många team gör det. Verktygen överlappar delvis men har olika styrkor, så en kombination ger bredare täckning än något enskilt verktyg gör på egen hand.
Kostar det något att köra OSV-Scanner i stor skala i CI/CD?
Själva verktyget och uppslagen mot OSV.dev är kostnadsfria oavsett hur många gånger om dagen du kör dem. Den enda kostnaden är beräkningstid i din egen CI-miljö, vilket för de flesta projekt handlar om några sekunder till någon enstaka minut per körning, beroende på projektets storlek och om skanningen körs rekursivt över ett stort monorepo.
