Prosjektet ditt har 47 kjente sårbarheter. Tre av dem er kritiske. Det er meldingen utviklere ser etter en enkel npm install, og det er akkurat det npm audit er laget for å avdekke. Denne guiden tar deg gjennom hele prosessen: fra første kjøring til automatisk fiks, fra CI-integrasjon til manuell håndtering av de vanskelige tilfellene.

Med npm v10 og Node.js 22 LTS er verktøykjeden mer presis enn noen gang. Du trenger ikke tredjepartsverktøy for å oppdage kritiske hull i avhengighetskjeden din. Alt du trenger er allerede installert.

Hva er npm audit og hvorfor betyr det noe

npm audit er et innebygd sikkerhetsverktøy i Node Package Manager. Kommandoen sammenligner avhengighetene i prosjektet ditt mot GitHub Advisory Database, som er den samme databasen som driver GitHub Dependabot. Når npm finner en pakke med kjente sårbarheter, rapporterer den alvorsgraden, hvilken versjon som er berørt, og hva du bør gjøre.

Verktøyet ble introdusert i npm v6 i 2018 og har siden blitt et standard steg i sikker Node.js-utvikling. GitHub Advisory Database holder over 300.000 sikkerhetsrådgivninger på tvers av alle store programmeringsspråkøkosystemer, og npm-registeret alene inneholder over 2,5 millioner pakker. Sjansen for at minst én avhengighet i et modent Node.js-prosjekt har en kjent sårbarhet er statistisk sett svært høy.

Det som gjør npm audit fix spesielt nyttig er at kommandoen ikke bare identifiserer problemer, den løser dem også. For de fleste sårbarheter er én kommando nok til å oppdatere pakker til sikre versjoner uten å bryte eksisterende funksjonalitet.

Forutsetninger

For å følge denne guiden trenger du:

  • Node.js 18 LTS eller nyere (Node.js 22 LTS anbefales, utgitt oktober 2024)
  • npm v9 eller nyere (leveres med Node.js 22, verifiser med npm --version)
  • Grunnleggende kunnskap om terminal eller kommandolinje
  • Et eksisterende Node.js-prosjekt, eller du oppretter et testprosjekt underveis
  • Grunnleggende forståelse av package.json og package-lock.json

Verifiser installasjonen din:

node --version
# v22.x.x

npm --version
# 10.x.x

Slik fungerer GitHub Advisory Database

Kjernen i npm audit er npm sin sårbarhetsskanning mot GitHub Advisory Database. Denne databasen samler sikkerhetsrådgivninger fra CVE-programmet (Common Vulnerabilities and Exposures), sikkerhetsteam hos store selskaper, og ansvarlig publisering fra individuelle forskere. Hver rådgivning inneholder:

  • En unik GHSA-identifikator (for eksempel GHSA-jchw-25xp-jwwc)
  • CVE-nummer om det er tildelt
  • Alvorsgrad: Critical, High, Moderate eller Low
  • CVSS-score (Common Vulnerability Scoring System, skala 0.1–10.0)
  • Berørte versjoner og den første sikre versjonen
  • En detaljert beskrivelse av sårbarheten og anbefalt utbedring

Når du kjører npm audit, sender npm en beskrivelse av prosjektets avhengigheter til npm-registeret. Registeret sjekker dette mot Advisory Database og returnerer en rapport med alle kjente problemer. Ingen kildekode sendes. Kun pakkenavn og versjonsnumre fra package-lock.json overføres.

AlvorsgradCVSS-scoreAnbefalt handlingTypisk eksempel
Critical9.0–10.0Fiks umiddelbartRemote Code Execution
High7.0–8.9Fiks innen 24 timerSQL-injeksjon, autentiseringsomgåelse
Moderate4.0–6.9Planlegg fiks innen en ukeInformasjonslekkasje, CSRF
Low0.1–3.9Behandle ved neste oppdateringKlartekst HTTP-redirect

Steg 1: Sett opp testprosjektet

La oss opprette et prosjekt med kjente sårbarheter slik at du ser nøyaktig hva npm audit rapporterer. I et ekte prosjekt hopper du over dette steget og jobber direkte med din eksisterende kodebase. Testprosjektet bruker eldre pakkeversjonersom er godt dokumentert i Advisory Database.

mkdir npm-audit-demo
cd npm-audit-demo
npm init -y

Installer noen eldre versjoner av pakker som historisk har hatt sårbarheter. Dette er utelukkende for demonstrasjonsformål:

npm install [email protected] [email protected]

Prosjektstrukturen din ser nå slik ut:

npm-audit-demo/
├── node_modules/
├── package.json
└── package-lock.json

package-lock.json er avgjørende for at npm audit skal fungere korrekt. Filen inneholder nøyaktige versjoner for alle direkte og transitive avhengigheter. Aldri legg denne filen i .gitignore.

Steg 2: Kjør npm audit for første gang

Nå som prosjektet er satt opp, kjøres den grunnleggende sikaningen:

npm audit

Outputen vil ligne på dette (nøyaktige tall varierer avhengig av versjonene som er installert og hvilke advisories som er publisert på kjøretidspunktet):

# npm audit report

lodash  <4.17.21
Severity: high
Prototype Pollution in lodash - https://github.com/advisories/GHSA-jf85-cpcp-j695
fix available via `npm audit fix`
node_modules/lodash

express  <4.19.2
Severity: moderate
Improper Input Validation in qs - https://github.com/advisories/GHSA-hrpp-h998-j3pp
fix available via `npm audit fix`
node_modules/express

2 vulnerabilities (1 high, 1 moderate)

To address all issues, run:
  npm audit fix

Kommandoen returnerer exit-kode 0 hvis ingen sårbarheter finnes. Den returnerer en ikke-null exit-kode hvis det finnes sårbarheter. Dette er sentralt for CI/CD-integrasjon, som vi kommer tilbake til i Steg 10.

Vær oppmerksom på at rapporten skiller mellom direkte avhengigheter (pakker du har listet i package.json) og transitive avhengigheter (pakker som dine direkte avhengigheter avhenger av). Begge typer vises i rapporten, og begge kan utgjøre sikkerhetsrisiko.

Steg 3: Forstå audit-rapporten i detalj

Rapporten har et konsistent format. Her er en detaljert gjennomgang av hva hvert felt betyr:

Pakkens navn og berørte versjoner: Den første linjen angir pakkenavnet etterfulgt av versjonsspesifikasjonen som er sårbar. Notasjonen <4.17.21 betyr alle versjoner under 4.17.21 er berørt. Notasjonen >=2.0.0 <2.1.5 betyr et versjonsspenn.

Severity: Alvorsgraden er ett av fire nivåer. npm beregner dette ut fra CVSS-scoren i GitHub Advisory Database.

Feilbeskrivelse og lenke: En kort beskrivelse av sårbarheten og en lenke til den fullstendige rådgivningen på github.com/advisories. Les alltid rådgivningen for å forstå den faktiske risikoen i din kontekst.

Fix-status: Enten “fix available via npm audit fix” eller “No fix available”. Sistnevnte betyr at ingen sikker versjon eksisterer ennå i registeret, og du må vurdere alternative pakker eller midlertidige tiltak.

Avhengighetsstien: Viser hvilken mappe i node_modules pakken befinner seg i. For transitive avhengigheter vises den fulle stien, for eksempel node_modules/express/node_modules/qs.

Oppsummering: Den siste linjen gir et raskt overblikk over antall sårbarheter per alvorsgrad og total.

Steg 4: npm audit –json for maskinlesbar output

For automatisering og videre bearbeiding er JSON-formatet nyttig. Det gir strukturert output som lar deg filtrere, sortere og integrere med andre verktøy:

npm audit --json

For å skrive rapporten til fil:

npm audit --json > audit-report.json

Du kan konvertere rapporten til HTML for enklere gjennomgang i nettleseren:

npm audit --json | npx npm-audit-html --output audit-report.html

For å telle antall sårbarheter per nivå med jq:

npm audit --json | jq '.metadata.vulnerabilities'
# Output:
# {
#   "info": 0,
#   "low": 0,
#   "moderate": 1,
#   "high": 1,
#   "critical": 0,
#   "total": 2
# }

JSON-outputen fra npm audit --json inneholder to hovedelementer: vulnerabilities (en liste over alle funne sårbarheter med full detaljer) og metadata (oppsummerende statistikk inkludert total avhengighetstelling og sårbarhetstall per alvorsgrad).

Steg 5: Kjør npm audit fix for automatisk utbedring

npm audit fix er den enkleste måten å løse sårbarheter som har tilgjengelige fikse versjoner. Kommandoen oppdaterer pakker til de laveste versjonene som løser kjente problemer, innenfor de versjonsspennene som er definert i package.json.

npm audit fix

Forventet output etter vellykket kjøring:

changed 2 packages, and audited 127 packages in 3.8s

37 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Etter en vellykket npm audit fix bør du alltid kjøre testsuiten din for å verifisere at ingen oppgradering har introdusert regresjoner:

npm audit fix
npm test

Noen ganger løser ikke npm audit fix alle problemer. Dette skjer typisk i to situasjoner: det finnes ingen tilgjengelig fiks ennå for den sårbare pakken, eller fiksen krever en major-versjonsbump som potensielt kan bryte eksisterende funksjonalitet. I begge tilfeller vil en gjenværende rapport vise hva som gjenstår.

Steg 6: Forhåndsvis endringer med –dry-run

Før du lar npm audit fix gjøre endringer i et produksjons- eller delt prosjekt, er det god praksis å forhåndsvise nøyaktig hva som vil endres. --dry-run-flagget gjør nettopp det, uten å faktisk endre noe:

npm audit fix --dry-run

Output fra dry-run:

Would change 2 packages:
  lodash  4.17.20 -> 4.17.21
  qs      6.5.2   -> 6.5.3 (transitive, via express)

Run `npm audit fix` to apply fixes.

For en mer detaljert forhåndsvisning som inkluderer all metainformasjon:

npm audit fix --dry-run --json | jq '.audit.auditReportVersion, .install, .remove'

Dry-run er spesielt nyttig i større team der avhengighetsoppdateringer må koordineres, eller i prosjekter med strenge testingskrav der enhver endring må valideres gjennom testsuiten. Gjør det til en vane å alltid kjøre dry-run først i etablerte prosjekter.

Steg 7: npm audit fix –force og når du ikke skal bruke det

Når npm audit fix ikke løser alle problemer, kan du bli fristet til å kjøre:

npm audit fix --force

Dette flagget tillater npm å oppgradere pakker til major-versjoner, selv om det kan introdusere brytende endringer. npm advarer selv eksplisitt om dette:

npm WARN using --force Recommended protections disabled.
npm WARN audit Updating express to 5.0.1, which is outside your stated dependency range.

changed 8 packages, and audited 127 packages in 5.4s

found 0 vulnerabilities

Bruk –force med stor forsiktighet. Major-versjonsbump kan medføre:

  • API-endringer som bryter eksisterende kode
  • Fjernede funksjoner du bruker aktivt
  • Endret atferd som ikke fanges opp av eksisterende tester
  • Nye peer-dependency-konflikter med andre pakker

En tryggere fremgangsmåte enn --force er å oppgradere manuelt én pakke om gangen, teste grundig etter hver endring, og dokumentere alle endringer. Se Steg 8 for den manuelle tilnærmingen.

KommandoHva den gjørRisikonivåAnbefaling
npm auditRapporterer sårbarheterIngenAlltid trygg å kjøre
npm audit fix --dry-runForhåndsviser endringerIngenKjør alltid dette først
npm audit fixOppgraderer innen semver-reglerLavTrygg etter dry-run
npm audit fix --forceTillater major-versjonsbumpHøyKun etter grundig testing
npm install pkg@versionManuell målrettet oppgraderingVariererAnbefalt for komplekse tilfeller

Steg 8: Manuell håndtering av transitive avhengigheter

Transitive avhengigheter (pakker som er avhengigheter av dine direkte avhengigheter) kan kreve manuell inngripen. Her er den anbefalte fremgangsmåten steg for steg.

Finn hvilke pakker som drar inn en bestemt sårbar transitiv avhengighet:

npm ls qs
# output:
# [email protected]
# └── [email protected]
#     └── [email protected]

For å tvinge frem en spesifikk versjon av en transitiv avhengighet bruker du overrides-feltet i package.json (tilgjengelig fra npm v8.3):

{
  "name": "mitt-prosjekt",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.17.0"
  },
  "overrides": {
    "qs": "^6.11.0"
  }
}

Etter å ha lagt til overrides, kjør npm install på nytt for å oppdatere lockfilen og verifiser:

npm install
npm audit
npm test

Viktig: Bruk overrides med forsiktighet. Du overstyrer pakkevedlikeholderens versjonskrav, og det kan føre til inkompatibilitetsproblemer. Verifiser alltid at den overstyrte versjonen er bakoverkompatibel.

Steg 9: Filtrer etter alvorsgrad og scope

I store prosjekter med mange transitive avhengigheter kan npm audit returnere mange sårbarheter. Du kan begrense auditens scope for å fokusere på det som faktisk er risikofylt:

# Kun produksjonsavhengigheter (ekskluder devDependencies)
npm audit --omit=dev

# Feiler kun på critical-nivå
npm audit --audit-level=critical

# Feiler på high og critical, men viser alle i rapporten
npm audit --audit-level=high

# Kombiner: produksjonsavhengigheter, feiler på high+
npm audit --omit=dev --audit-level=high

--omit=dev er spesielt verdifullt i produksjons-CI-pipelines der du kun bekymrer deg for kode som faktisk kjøres av sluttbrukere. Dev-avhengigheter som testverktøy, lintere og byggeverktøy er aldri eksponert i produksjon. Sårbarheter i disse utgjør generelt en betydelig lavere risiko.

Et viktig poeng som mange misforstår: --audit-level endrer terskelen for hva som gjør at kommandoen feiler, men filtrerer ikke rapporten. Med --audit-level=high vil rapporten fortsatt vise moderate og low-sårbarheter. Kommandoen vil bare returnere exit-kode 1 (feil) hvis det finnes high eller critical-funn.

Steg 10: Integrer npm audit i CI/CD-pipeline

En av de viktigste bruksområdene for npm audit er som en automatisk sikkerhetsport i CI/CD-pipelinen. Kommandoen returnerer exit-kode 1 ved sårbarheter over terskelen, som stopper pipelines automatisk.

Komplett GitHub Actions workflow:

# .github/workflows/security.yml
name: Sikkerhetsaudit

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
  schedule:
    # Kjør hverdager kl. 06:00 UTC (08:00 norsk tid)
    - cron: '0 6 * * 1-5'

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Installer avhengigheter (ren installasjon)
        run: npm ci

      - name: Kjør sikkerhetsaudit for produksjon
        run: npm audit --audit-level=high --omit=dev

      - name: Generer HTML-rapport ved feil
        if: failure()
        run: |
          mkdir -p reports
          npm audit --json | npx npm-audit-html --output reports/audit.html

      - name: Last opp sikkerhetsrapport
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: security-audit-report
          path: reports/audit.html
          retention-days: 30

Den planlagte daglige kjøringen er kritisk. Nye sårbarheter oppdages kontinuerlig. En pakke som var trygg i går kan ha fått en ny CVE i dag. Uten periodisk overvåking kan prosjektet ditt ha kjente kritiske sårbarheter i uker uten at noen vet om det.

Steg 11: npm ci vs npm install i pipelines

I CI-miljøer bør du alltid bruke npm ci i stedet for npm install. Forskjellene er vesentlige for sikkerhet og reproduserbarhet:

Egenskapnpm installnpm ci
Låser versjonerNei (kan oppgradere innen range)Ja (bruker package-lock.json nøyaktig)
Sletter node_modulesNeiJa (alltid ren installasjon)
Feiler ved avvikNeiJa (stopper om lock ikke matcher)
Endrer package-lock.jsonKan gjøre detAldri
Hastighet i CITregereRaskere
Anbefalt tilLokal utviklingCI/CD og produksjonsbygg

npm ci garanterer reproduserbare bygg. Hvis package-lock.json mangler eller ikke stemmer overens med package.json, vil npm ci feile med en tydelig feilmelding. Dette forhindrer at utilsiktede avhengighetsoppgraderinger sniker seg inn i produksjonsmiljøet, noe som er særlig viktig for sikkerhetsaudit-resultatene.

Steg 12: Komplett automatiseringsscript

Her er et komplett Node.js-script som kombinerer alle stegene til en automatisert sikkerhetsprosess. Legg det til som en npm-script i prosjektet ditt:

// scripts/security-check.js
const { execSync } = require('child_process');
const fs = require('fs');
const path = require('path');

function runAudit() {
  console.log('=== npm sikkerhetsaudit ===\n');

  let auditData;
  try {
    const output = execSync('npm audit --json', {
      encoding: 'utf8',
      // npm audit returnerer non-zero exit-kode ved funn,
      // men vi ønsker å lese JSON-outputen uansett
      stdio: ['pipe', 'pipe', 'pipe']
    });
    auditData = JSON.parse(output);
  } catch (err) {
    if (err.stdout) {
      try {
        auditData = JSON.parse(err.stdout);
      } catch {
        console.error('Klarte ikke å parse audit-output:', err.message);
        process.exit(2);
      }
    } else {
      console.error('Klarte ikke å kjøre npm audit:', err.message);
      process.exit(2);
    }
  }

  const { vulnerabilities, metadata } = auditData;
  const counts = metadata.vulnerabilities;

  console.log('Sårbarhetsoversikt:');
  console.log(`  Critical: ${counts.critical}`);
  console.log(`  High:     ${counts.high}`);
  console.log(`  Moderate: ${counts.moderate}`);
  console.log(`  Low:      ${counts.low}`);
  console.log(`  Total:    ${counts.total}\n`);

  // Lagre full rapport
  const reportDir = path.join(process.cwd(), 'reports');
  if (!fs.existsSync(reportDir)) {
    fs.mkdirSync(reportDir, { recursive: true });
  }
  fs.writeFileSync(
    path.join(reportDir, 'audit-report.json'),
    JSON.stringify(auditData, null, 2)
  );
  console.log('Full rapport lagret i reports/audit-report.json\n');

  // Feiler ved critical eller high
  if (counts.critical > 0 || counts.high > 0) {
    console.error('FEIL: Critical eller high-sårbarheter funnet!');
    console.error('Kjør `npm audit fix` for å løse automatisk fiksbare problemer.');
    process.exit(1);
  }

  if (counts.moderate > 0) {
    console.warn(`ADVARSEL: ${counts.moderate} moderate sårbarhet(er) funnet. Planlegg fiks.`);
  }

  console.log('Sikkerhetsstatus: OK');
  process.exit(0);
}

runAudit();

Legg til scriptene i package.json:

{
  "name": "mitt-prosjekt",
  "version": "1.0.0",
  "engines": {
    "node": ">=22.0.0",
    "npm": ">=10.0.0"
  },
  "scripts": {
    "test": "jest --coverage",
    "audit:check": "node scripts/security-check.js",
    "audit:fix": "npm audit fix",
    "audit:preview": "npm audit fix --dry-run",
    "audit:report": "npm audit --json | npx npm-audit-html --output reports/audit.html",
    "preinstall": "npm audit --audit-level=critical --omit=dev 2>/dev/null || true"
  }
}

npm audit vs Snyk vs GitHub Dependabot: sammenligning

Det finnes flere verktøy for avhengighetssikkerhet. Her er en sammenligning av de tre mest brukte i Node.js-prosjekter:

Egenskapnpm auditSnykGitHub Dependabot
KostnadGratis (innebygd)Gratis/betalt planGratis for GitHub-brukere
DatakildeGitHub Advisory DBSnyk Vulnerability DBGitHub Advisory DB
Automatiske PR-erNeiJaJa
Kodeflytanalyse (SAST)NeiJa (betalt)Nei
CI-integrasjonEnkel, innebygdAvansert via CLI/APIInnebygd i GitHub
LisenssjekkngNeiJa (betalt)Nei
Exploit-modenhetNeiJaNei
OppsettIngen (allerede installert)npm install -g snykKonfigurasjonsfil i repo

For de fleste Node.js-prosjekter er npm audit tilstrekkelig som første forsvarslinje. Det er zero-konfigurasjon, gratis, og allerede tilgjengelig i alle Node.js-installasjoner. Snyk tilbyr mer avanserte funksjoner som exploit-modenhet og lisensstyring, noe som er verdifullt i større organisasjoner med compliance-krav. GitHub Dependabot er ideelt for GitHub-baserte prosjekter som ønsker automatiske sikkerhets-PR-er uten manuell oppfølging.

npm audit og Dependabot deler GitHub Advisory Database som kilde. De vil derfor identifisere de samme sårbarhetene. Snyk har sin egen sårbarhetsdatabase som i noen tilfeller oppdages raskere enn GitHub Advisory Database, men for standard open source-pakker er overlappen stor. For regulerte bransjer (finans, helse) anbefales det å kombinere npm audit med OWASP Dependency-Check for bredest mulig dekning.

5 vanlige fallgruver med npm audit fix

Fallgruve 1: Kjøre npm audit fix –force uten testing. --force kan oppgradere pakker til major-versjoner med brytende endringer. En Express 4.x-applikasjon som oppgraderes til Express 5.x via --force kan slutte å fungere fordi Express 5 har en ny router-arkitektur og fjernede API-er. Løsning: Alltid kjør testsuiten din etter enhver --force-operasjon, og les CHANGELOG for alle oppgraderte pakker.

Fallgruve 2: Ignorere “No fix available”-meldinger uten oppfølging. Når npm rapporterer at det ikke finnes noen fiks, betyr det ikke at du ikke trenger å gjøre noe. Det betyr at pakken ennå ikke har publisert en sikker versjon. Handlingsalternativer: bytt til en aktivt vedlikeholdt alternativ pakke, implementer en midlertidig workaround i din egen kode, eller sett opp en GitHub-alert slik at du vet når en fiks blir tilgjengelig.

Fallgruve 3: Utelate package-lock.json fra versjonskontroll. Uten package-lock.json kan npm audit ikke gi nøyaktige resultater fordi den ikke vet nøyaktig hvilke versjoner av transitive avhengigheter som er installert. Locking-filen sikrer at alle i teamet og CI-miljøet installerer nøyaktig de samme versjonene. Aldri legg package-lock.json i .gitignore.

Fallgruve 4: Bruke npm install i stedet for npm ci i pipelines. npm install kan oppdatere package-lock.json, noe som betyr at CI-miljøet ditt kan installere andre versjoner enn det som er testet lokalt. Dette ugyldiggjør audit-resultatene og kan skjule sikkerhetsrisikoer. Bruk alltid npm ci i CI/CD-miljøer.

Fallgruve 5: Kjøre audit kun ved nye releases. Nye CVE-er publiseres daglig. En pakke som var trygg fredag kan ha en ny kritisk sårbarhet mandag. Sett opp daglige planlagte audit-kjøringer i CI-systemet ditt, ikke bare ved nye commits. Bruk GitHub Actions’ schedule-trigger (se Steg 10) for automatisk daglig overvåking.

Feilsøking: 8 vanlige problemer og løsninger

Problem 1: “Cannot read properties of undefined” ved npm audit

Årsak: Manglende eller korrupt package-lock.json. Løsning:

rm -rf node_modules package-lock.json
npm install
npm audit

Problem 2: “ENOAUDIT: No audit found in the registry”

Årsak: npm kan ikke nå audit-endepunktet i registeret. Kontroller nettverkstilgang og proxy-innstillinger:

npm config get proxy
npm config get https-proxy
npm config get registry
# Verifiser tilgang til registeret:
curl -I https://registry.npmjs.org

Problem 3: Sårbarheter gjenoppstår etter npm audit fix

Årsak: Sårbare pakker er transitiv avhengighet av en direkte avhengighet som ikke kan oppgraderes innenfor semver-regler. Løsning: Bruk overrides i package.json (se Steg 8) eller oppgrader den direkte avhengigheten manuelt med npm install pakke@nyeste.

Problem 4: npm audit feiler i offline-miljø

Årsak: npm audit krever internettilgang for å spørre Advisory Database. For airgapped-miljøer kan du bruke et privat npm-register (Verdaccio, JFrog Artifactory, GitHub Packages) som speiler Advisory Database og tillater lokale auditspørringer. Alternativt kan du bruke Snyk sin CLI i offline-modus med en lokal kopi av sårbarhetsdatabasen.

Problem 5: For mange falske positiver fra dev-avhengigheter

Løsning: Bruk --omit=dev for å ekskludere dev-avhengigheter. Testverktøy og byggeverktøy kjøres aldri i produksjon og er normalt ikke direkte eksponert for eksterne angripere:

npm audit --omit=dev --audit-level=high

Problem 6: npm audit fix bryter applikasjonen

Årsak: En oppgradert pakke hadde en API-endring innenfor sin semver-versjon (brudd på semver-konvensjon). Løsning: Tilbakestill med git, identifiser den spesifikke pakken som forårsaket problemet, og oppgrader til en version du vet fungerer:

git checkout package-lock.json
npm ci
# Oppgrader pakker én etter én
npm install [email protected]
npm test
npm install [email protected]
npm test

Problem 7: Workspace-prosjekter viser feil antall sårbarheter

I npm workspaces kjøres npm audit som standard på hele workspace-treet. For å kjøre audit på ett enkelt workspace:

npm audit --workspace=packages/min-app
# eller kortform
npm audit -w packages/min-app

Problem 8: npm audit rapporterer 0 sårbarheter, men Snyk finner fler

Årsak: Snyk vedlikeholder sin egen proprietære sårbarhetsdatabase som kan inneholde funn som ennå ikke er publisert til GitHub Advisory Database, eller som er spesifikke for Snyk-plattformen. For produksjonskritiske applikasjoner anbefales det å bruke komplementerende verktøy. Se Snyk sine ti beste npm-sikkerhetspraksiser for detaljer om hva de oppdager som npm audit ikke gjør.

Avanserte tips for en moden sikkerhetsprosess

Konfigurer npm audit som pre-commit-hook. Med Husky kan du kjøre npm audit --audit-level=critical som en pre-commit-hook, slik at ingen kan committe kode som introduserer kritiske sårbarheter i produksjonsavhengighetene:

npm install --save-dev husky
npx husky init
echo "npm audit --audit-level=critical --omit=dev" > .husky/pre-commit

Hold Node.js og npm oppdatert. Eldre versjoner av npm kan mangle advisories for nyere pakker eller ha feil i auditlogikken. Bruk en Node.js-versjonshåndterer (nvm, fnm eller Volta) for enkelt å holde runtime oppdatert:

# Med nvm
nvm install --lts
nvm use --lts

# Oppdater npm separat
npm install -g npm@latest

Sett opp automatiske Dependabot-PR-er som supplement. Kombiner daglig npm audit i CI med GitHub Dependabot for automatiske pull requests. Legg til en .github/dependabot.yml-fil:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Europe/Oslo"
    labels:
      - "security"
      - "dependencies"

Dokumenter bevisst aksepterte risikoer. Noen sårbarheter er ikke relevante for din brukscase. For eksempel er en ReDoS-sårbarhet (Regular Expression Denial of Service) i en pakke du kun bruker i offline batchprosessering normalt ikke en risiko. Dokumenter slike vurderinger i et SECURITY.md-dokument i repoet, slik at teamet vet at de er vurdert og ikke oversett.

Bruk npm audit signatures for ekstra verifisering. Fra npm v9 kan du verifisere at nedlastede pakker matcher de signerte versjonene i registeret. Dette beskytter mot angrep der et kompromittert CDN eller speil leverer manipulerte pakker:

npm audit signatures
# Verifiserer kryptografiske signaturer for alle installerte pakker

For mer om truslene npm audit signatures beskytter mot, se vår artikkel om npm forsyningskjedeangrep.

Relatert dekning

Denne guiden er del av shattered.io sin Node.js-sikkerhetsserie. Neste steg for en komplett sikkerhetsstrategi:

Ofte stilte spørsmål

Hva er forskjellen mellom npm audit og npm audit fix?

npm audit scanner avhengighetene dine og rapporterer sårbarheter uten å endre noe. npm audit fix gjør det samme, men forsøker i tillegg å automatisk oppgradere sårbare pakker til sikre versjoner innenfor det tillatte versjonsspennet definert i package.json. Start alltid med npm audit for å forstå situasjonen, bruk npm audit fix --dry-run for å forhåndsvise planlagte endringer, og kjør deretter npm audit fix.

Er det trygt å kjøre npm audit fix i produksjon?

Uten --force-flagget er npm audit fix generelt trygt fordi det kun oppdaterer innenfor semver-kompatible versjoner. Best practice er likevel: kjør --dry-run først, test etter oppdatering, og deploy til staging-miljø før produksjon. Gjennomgå alltid git-diff på package-lock.json for å se nøyaktig hva som endret seg.

Hva betyr “No fix available” i npm audit?

“No fix available” betyr at pakkevedlikeholderen ennå ikke har publisert en versjon som løser sårbarheten. I dette tilfellet bør du vurdere om du faktisk er eksponert basert på din brukscase, søke etter en alternativ pakke, og følge med på pakken ved å aktivere GitHub-varsler for repositoriet. For kritiske pakker uten fiks bør du vurdere midlertidige kompenserende kontroller i din egen kode.

Hvordan håndterer jeg sårbarheter i transitive avhengigheter?

Transitive avhengigheter kan ikke alltid fikses med npm audit fix. Bruk overrides-feltet i package.json for å tvinge frem en spesifikk versjon av en transitiv avhengighet. Alternativt kan du oppgradere den direkte avhengigheten som drar inn den sårbare pakken. Bruk npm ls pakkenavn for å forstå avhengighetstreet.

Hvor ofte bør jeg kjøre npm audit?

Kjør npm audit ved: hvert nye installasjon av avhengigheter, før og etter enhver avhengighetsoppdatering, automatisk via daglige planlagte kjøringer i CI/CD, og som en del av code review-prosessen for PRer som endrer package.json. Nye sårbarheter oppdages daglig, så periodisk overvåking er viktigere enn ad-hoc-kjøringer.

Kan jeg stole på at npm audit finner alle sårbarheter?

Nei. npm audit sjekker kun mot kjente, publiserte sårbarheter i GitHub Advisory Database. Den oppdager ikke nulldagssårbarheter (zero-days), feil i din egen kode, konfigurasjonssvakheter, eller forsyningskjedeangrep via ondsinnede pakker med lignende navn (typosquatting). For mer helhetlig sikkerhet kombineres npm audit med statisk kodeanalyse (ESLint security-plugins), dynamisk testing, og npm audit signatures for pakkeintegritetskontroll.

Bør jeg committe package-lock.json til Git?

Ja, alltid for applikasjoner. package-lock.json er avgjørende for reproduserbare bygg og nøyaktige audit-resultater. Uten denne filen kan npm ci ikke fungere, og npm audit mangler informasjon om nøyaktig hvilke versjoner som er installert. Unntaket er npm-biblioteker (pakker du publiserer til registeret), der du typisk ikke committer lockfilen slik at konsumentene kan løse versjoner med sine egne constraints.

Hva gjør npm audit signatures?

npm audit signatures ble introdusert i npm v9 og verifiserer kryptografiske signaturer for alle installerte pakker. Kommandoen sjekker at pakkene du har lastet ned faktisk er signert av de registrerte vedlikeholderne og ikke er manipulert underveis. Dette er et ekstra sikkerhetslag utover vanlig sårbarhetsscanning, og beskytter mot man-in-the-middle-angrep og kompromitterte CDN-er. Kjør den separat fra vanlig audit: npm audit signatures.