{"id":112,"date":"2026-06-18T17:00:39","date_gmt":"2026-06-18T17:00:39","guid":{"rendered":"https:\/\/shattered.io\/no\/2026\/06\/18\/npm-audit-fix-nodejs\/"},"modified":"2026-06-18T17:01:59","modified_gmt":"2026-06-18T17:01:59","slug":"npm-audit-fix-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/no\/npm-audit-fix-nodejs\/","title":{"rendered":"npm audit fix i Node.js: 12 Steg, 30 Min [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Prosjektet ditt har 47 kjente s\u00e5rbarheter. Tre av dem er kritiske. Det er meldingen utviklere ser etter en enkel <code>npm install<\/code>, og det er akkurat det <code>npm audit<\/code> er laget for \u00e5 avdekke. Denne guiden tar deg gjennom hele prosessen: fra f\u00f8rste kj\u00f8ring til automatisk fiks, fra CI-integrasjon til manuell h\u00e5ndtering av de vanskelige tilfellene.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Med npm v10 og Node.js 22 LTS er verkt\u00f8ykjeden mer presis enn noen gang. Du trenger ikke tredjepartsverkt\u00f8y for \u00e5 oppdage kritiske hull i avhengighetskjeden din. Alt du trenger er allerede installert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"hva-er-npm-audit-og-hvorfor-betyr-det-noe\">Hva er npm audit og hvorfor betyr det noe<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>npm audit<\/code> er et innebygd sikkerhetsverkt\u00f8y i Node Package Manager. Kommandoen sammenligner avhengighetene i prosjektet ditt mot <a href=\"https:\/\/github.com\/advisories\" rel=\"noopener noreferrer\" target=\"_blank\">GitHub Advisory Database<\/a>, som er den samme databasen som driver GitHub Dependabot. N\u00e5r npm finner en pakke med kjente s\u00e5rbarheter, rapporterer den alvorsgraden, hvilken versjon som er ber\u00f8rt, og hva du b\u00f8r gj\u00f8re.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Verkt\u00f8yet 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\u00e5dgivninger p\u00e5 tvers av alle store programmeringsspr\u00e5k\u00f8kosystemer, og npm-registeret alene inneholder over 2,5 millioner pakker. Sjansen for at minst \u00e9n avhengighet i et modent Node.js-prosjekt har en kjent s\u00e5rbarhet er statistisk sett sv\u00e6rt h\u00f8y.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Det som gj\u00f8r <code>npm audit fix<\/code> spesielt nyttig er at kommandoen ikke bare identifiserer problemer, den l\u00f8ser dem ogs\u00e5. For de fleste s\u00e5rbarheter er \u00e9n kommando nok til \u00e5 oppdatere pakker til sikre versjoner uten \u00e5 bryte eksisterende funksjonalitet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"forutsetninger\">Forutsetninger<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">For \u00e5 f\u00f8lge denne guiden trenger du:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Node.js 18 LTS eller nyere<\/strong> (Node.js 22 LTS anbefales, utgitt oktober 2024)<\/li>\n<li><strong>npm v9 eller nyere<\/strong> (leveres med Node.js 22, verifiser med <code>npm --version<\/code>)<\/li>\n<li>Grunnleggende kunnskap om terminal eller kommandolinje<\/li>\n<li>Et eksisterende Node.js-prosjekt, eller du oppretter et testprosjekt underveis<\/li>\n<li>Grunnleggende forst\u00e5else av <code>package.json<\/code> og <code>package-lock.json<\/code><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Verifiser installasjonen din:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>node --version\n# v22.x.x\n\nnpm --version\n# 10.x.x<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"slik-fungerer-github-advisory-database\">Slik fungerer GitHub Advisory Database<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Kjernen i <code>npm audit<\/code> er <a href=\"https:\/\/docs.npmjs.com\/auditing-package-dependencies-for-security-vulnerabilities\" rel=\"noopener noreferrer\" target=\"_blank\">npm sin s\u00e5rbarhetsskanning<\/a> mot GitHub Advisory Database. Denne databasen samler sikkerhetsr\u00e5dgivninger fra CVE-programmet (Common Vulnerabilities and Exposures), sikkerhetsteam hos store selskaper, og ansvarlig publisering fra individuelle forskere. Hver r\u00e5dgivning inneholder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>En unik GHSA-identifikator (for eksempel GHSA-jchw-25xp-jwwc)<\/li>\n<li>CVE-nummer om det er tildelt<\/li>\n<li>Alvorsgrad: Critical, High, Moderate eller Low<\/li>\n<li>CVSS-score (Common Vulnerability Scoring System, skala 0.1\u201310.0)<\/li>\n<li>Ber\u00f8rte versjoner og den f\u00f8rste sikre versjonen<\/li>\n<li>En detaljert beskrivelse av s\u00e5rbarheten og anbefalt utbedring<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">N\u00e5r du kj\u00f8rer <code>npm audit<\/code>, 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 <code>package-lock.json<\/code> overf\u00f8res.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Alvorsgrad<\/th><th>CVSS-score<\/th><th>Anbefalt handling<\/th><th>Typisk eksempel<\/th><\/tr><\/thead><tbody><tr><td>Critical<\/td><td>9.0\u201310.0<\/td><td>Fiks umiddelbart<\/td><td>Remote Code Execution<\/td><\/tr><tr><td>High<\/td><td>7.0\u20138.9<\/td><td>Fiks innen 24 timer<\/td><td>SQL-injeksjon, autentiseringsomg\u00e5else<\/td><\/tr><tr><td>Moderate<\/td><td>4.0\u20136.9<\/td><td>Planlegg fiks innen en uke<\/td><td>Informasjonslekkasje, CSRF<\/td><\/tr><tr><td>Low<\/td><td>0.1\u20133.9<\/td><td>Behandle ved neste oppdatering<\/td><td>Klartekst HTTP-redirect<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-1-sett-opp-testprosjektet\">Steg 1: Sett opp testprosjektet<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La oss opprette et prosjekt med kjente s\u00e5rbarheter slik at du ser n\u00f8yaktig hva <code>npm audit<\/code> 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.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir npm-audit-demo\ncd npm-audit-demo\nnpm init -y<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Installer noen eldre versjoner av pakker som historisk har hatt s\u00e5rbarheter. Dette er utelukkende for demonstrasjonsform\u00e5l:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install express@4.17.0 lodash@4.17.20<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Prosjektstrukturen din ser n\u00e5 slik ut:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm-audit-demo\/\n\u251c\u2500\u2500 node_modules\/\n\u251c\u2500\u2500 package.json\n\u2514\u2500\u2500 package-lock.json<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>package-lock.json<\/code> er avgj\u00f8rende for at <code>npm audit<\/code> skal fungere korrekt. Filen inneholder n\u00f8yaktige versjoner for alle direkte og transitive avhengigheter. Aldri legg denne filen i <code>.gitignore<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-2-kjor-npm-audit-for-forste-gang\">Steg 2: Kj\u00f8r npm audit for f\u00f8rste gang<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">N\u00e5 som prosjektet er satt opp, kj\u00f8res den grunnleggende sikaningen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Outputen vil ligne p\u00e5 dette (n\u00f8yaktige tall varierer avhengig av versjonene som er installert og hvilke advisories som er publisert p\u00e5 kj\u00f8retidspunktet):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># npm audit report\n\nlodash  &lt;4.17.21\nSeverity: high\nPrototype Pollution in lodash - https:\/\/github.com\/advisories\/GHSA-jf85-cpcp-j695\nfix available via `npm audit fix`\nnode_modules\/lodash\n\nexpress  &lt;4.19.2\nSeverity: moderate\nImproper Input Validation in qs - https:\/\/github.com\/advisories\/GHSA-hrpp-h998-j3pp\nfix available via `npm audit fix`\nnode_modules\/express\n\n2 vulnerabilities (1 high, 1 moderate)\n\nTo address all issues, run:\n  npm audit fix<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Kommandoen returnerer exit-kode 0 hvis ingen s\u00e5rbarheter finnes. Den returnerer en ikke-null exit-kode hvis det finnes s\u00e5rbarheter. Dette er sentralt for CI\/CD-integrasjon, som vi kommer tilbake til i Steg 10.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">V\u00e6r oppmerksom p\u00e5 at rapporten skiller mellom <strong>direkte avhengigheter<\/strong> (pakker du har listet i <code>package.json<\/code>) og <strong>transitive avhengigheter<\/strong> (pakker som dine direkte avhengigheter avhenger av). Begge typer vises i rapporten, og begge kan utgj\u00f8re sikkerhetsrisiko.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-3-forsta-audit-rapporten-i-detalj\">Steg 3: Forst\u00e5 audit-rapporten i detalj<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Rapporten har et konsistent format. Her er en detaljert gjennomgang av hva hvert felt betyr:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Pakkens navn og ber\u00f8rte versjoner:<\/strong> Den f\u00f8rste linjen angir pakkenavnet etterfulgt av versjonsspesifikasjonen som er s\u00e5rbar. Notasjonen <code>&lt;4.17.21<\/code> betyr alle versjoner under 4.17.21 er ber\u00f8rt. Notasjonen <code>&gt;=2.0.0 &lt;2.1.5<\/code> betyr et versjonsspenn.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Severity:<\/strong> Alvorsgraden er ett av fire niv\u00e5er. npm beregner dette ut fra CVSS-scoren i GitHub Advisory Database.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Feilbeskrivelse og lenke:<\/strong> En kort beskrivelse av s\u00e5rbarheten og en lenke til den fullstendige r\u00e5dgivningen p\u00e5 github.com\/advisories. Les alltid r\u00e5dgivningen for \u00e5 forst\u00e5 den faktiske risikoen i din kontekst.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fix-status:<\/strong> Enten &#8220;fix available via <code>npm audit fix<\/code>&#8221; eller &#8220;No fix available&#8221;. Sistnevnte betyr at ingen sikker versjon eksisterer enn\u00e5 i registeret, og du m\u00e5 vurdere alternative pakker eller midlertidige tiltak.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Avhengighetsstien:<\/strong> Viser hvilken mappe i <code>node_modules<\/code> pakken befinner seg i. For transitive avhengigheter vises den fulle stien, for eksempel <code>node_modules\/express\/node_modules\/qs<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Oppsummering:<\/strong> Den siste linjen gir et raskt overblikk over antall s\u00e5rbarheter per alvorsgrad og total.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-4-npm-audit-json-for-maskinlesbar-output\">Steg 4: npm audit &#8211;json for maskinlesbar output<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">For automatisering og videre bearbeiding er JSON-formatet nyttig. Det gir strukturert output som lar deg filtrere, sortere og integrere med andre verkt\u00f8y:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --json<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For \u00e5 skrive rapporten til fil:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --json > audit-report.json<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Du kan konvertere rapporten til HTML for enklere gjennomgang i nettleseren:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --json | npx npm-audit-html --output audit-report.html<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For \u00e5 telle antall s\u00e5rbarheter per niv\u00e5 med <code>jq<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --json | jq '.metadata.vulnerabilities'\n# Output:\n# {\n#   \"info\": 0,\n#   \"low\": 0,\n#   \"moderate\": 1,\n#   \"high\": 1,\n#   \"critical\": 0,\n#   \"total\": 2\n# }<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">JSON-outputen fra <code>npm audit --json<\/code> inneholder to hovedelementer: <code>vulnerabilities<\/code> (en liste over alle funne s\u00e5rbarheter med full detaljer) og <code>metadata<\/code> (oppsummerende statistikk inkludert total avhengighetstelling og s\u00e5rbarhetstall per alvorsgrad).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-5-kjor-npm-audit-fix-for-automatisk-utbedring\">Steg 5: Kj\u00f8r npm audit fix for automatisk utbedring<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>npm audit fix<\/code> er den enkleste m\u00e5ten \u00e5 l\u00f8se s\u00e5rbarheter som har tilgjengelige fikse versjoner. Kommandoen oppdaterer pakker til de laveste versjonene som l\u00f8ser kjente problemer, innenfor de versjonsspennene som er definert i <code>package.json<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Forventet output etter vellykket kj\u00f8ring:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>changed 2 packages, and audited 127 packages in 3.8s\n\n37 packages are looking for funding\n  run `npm fund` for details\n\nfound 0 vulnerabilities<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Etter en vellykket <code>npm audit fix<\/code> b\u00f8r du alltid kj\u00f8re testsuiten din for \u00e5 verifisere at ingen oppgradering har introdusert regresjoner:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix\nnpm test<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Noen ganger l\u00f8ser ikke <code>npm audit fix<\/code> alle problemer. Dette skjer typisk i to situasjoner: det finnes ingen tilgjengelig fiks enn\u00e5 for den s\u00e5rbare pakken, eller fiksen krever en major-versjonsbump som potensielt kan bryte eksisterende funksjonalitet. I begge tilfeller vil en gjenv\u00e6rende rapport vise hva som gjenst\u00e5r.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-6-forhandsvis-endringer-med-dry-run\">Steg 6: Forh\u00e5ndsvis endringer med &#8211;dry-run<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00f8r du lar <code>npm audit fix<\/code> gj\u00f8re endringer i et produksjons- eller delt prosjekt, er det god praksis \u00e5 forh\u00e5ndsvise n\u00f8yaktig hva som vil endres. <code>--dry-run<\/code>-flagget gj\u00f8r nettopp det, uten \u00e5 faktisk endre noe:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix --dry-run<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Output fra dry-run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Would change 2 packages:\n  lodash  4.17.20 -> 4.17.21\n  qs      6.5.2   -> 6.5.3 (transitive, via express)\n\nRun `npm audit fix` to apply fixes.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For en mer detaljert forh\u00e5ndsvisning som inkluderer all metainformasjon:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix --dry-run --json | jq '.audit.auditReportVersion, .install, .remove'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Dry-run er spesielt nyttig i st\u00f8rre team der avhengighetsoppdateringer m\u00e5 koordineres, eller i prosjekter med strenge testingskrav der enhver endring m\u00e5 valideres gjennom testsuiten. Gj\u00f8r det til en vane \u00e5 alltid kj\u00f8re dry-run f\u00f8rst i etablerte prosjekter.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-7-npm-audit-fix-force-og-nar-du-ikke-skal-bruke-det\">Steg 7: npm audit fix &#8211;force og n\u00e5r du ikke skal bruke det<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">N\u00e5r <code>npm audit fix<\/code> ikke l\u00f8ser alle problemer, kan du bli fristet til \u00e5 kj\u00f8re:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix --force<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Dette flagget tillater npm \u00e5 oppgradere pakker til major-versjoner, selv om det kan introdusere brytende endringer. npm advarer selv eksplisitt om dette:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm WARN using --force Recommended protections disabled.\nnpm WARN audit Updating express to 5.0.1, which is outside your stated dependency range.\n\nchanged 8 packages, and audited 127 packages in 5.4s\n\nfound 0 vulnerabilities<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Bruk &#8211;force med stor forsiktighet.<\/strong> Major-versjonsbump kan medf\u00f8re:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>API-endringer som bryter eksisterende kode<\/li>\n<li>Fjernede funksjoner du bruker aktivt<\/li>\n<li>Endret atferd som ikke fanges opp av eksisterende tester<\/li>\n<li>Nye peer-dependency-konflikter med andre pakker<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">En tryggere fremgangsm\u00e5te enn <code>--force<\/code> er \u00e5 oppgradere manuelt \u00e9n pakke om gangen, teste grundig etter hver endring, og dokumentere alle endringer. Se Steg 8 for den manuelle tiln\u00e6rmingen.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Kommando<\/th><th>Hva den gj\u00f8r<\/th><th>Risikoniv\u00e5<\/th><th>Anbefaling<\/th><\/tr><\/thead><tbody><tr><td><code>npm audit<\/code><\/td><td>Rapporterer s\u00e5rbarheter<\/td><td>Ingen<\/td><td>Alltid trygg \u00e5 kj\u00f8re<\/td><\/tr><tr><td><code>npm audit fix --dry-run<\/code><\/td><td>Forh\u00e5ndsviser endringer<\/td><td>Ingen<\/td><td>Kj\u00f8r alltid dette f\u00f8rst<\/td><\/tr><tr><td><code>npm audit fix<\/code><\/td><td>Oppgraderer innen semver-regler<\/td><td>Lav<\/td><td>Trygg etter dry-run<\/td><\/tr><tr><td><code>npm audit fix --force<\/code><\/td><td>Tillater major-versjonsbump<\/td><td>H\u00f8y<\/td><td>Kun etter grundig testing<\/td><\/tr><tr><td><code>npm install pkg@version<\/code><\/td><td>Manuell m\u00e5lrettet oppgradering<\/td><td>Varierer<\/td><td>Anbefalt for komplekse tilfeller<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-8-manuell-handtering-av-transitive-avhengigheter\">Steg 8: Manuell h\u00e5ndtering av transitive avhengigheter<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Transitive avhengigheter (pakker som er avhengigheter av dine direkte avhengigheter) kan kreve manuell inngripen. Her er den anbefalte fremgangsm\u00e5ten steg for steg.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Finn hvilke pakker som drar inn en bestemt s\u00e5rbar transitiv avhengighet:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm ls qs\n# output:\n# npm-audit-demo@1.0.0\n# \u2514\u2500\u2500 express@4.17.0\n#     \u2514\u2500\u2500 qs@6.5.2<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For \u00e5 tvinge frem en spesifikk versjon av en transitiv avhengighet bruker du <code>overrides<\/code>-feltet i <code>package.json<\/code> (tilgjengelig fra npm v8.3):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"name\": \"mitt-prosjekt\",\n  \"version\": \"1.0.0\",\n  \"dependencies\": {\n    \"express\": \"^4.17.0\"\n  },\n  \"overrides\": {\n    \"qs\": \"^6.11.0\"\n  }\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Etter \u00e5 ha lagt til <code>overrides<\/code>, kj\u00f8r <code>npm install<\/code> p\u00e5 nytt for \u00e5 oppdatere lockfilen og verifiser:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install\nnpm audit\nnpm test<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Viktig:<\/strong> Bruk <code>overrides<\/code> med forsiktighet. Du overstyrer pakkevedlikeholderens versjonskrav, og det kan f\u00f8re til inkompatibilitetsproblemer. Verifiser alltid at den overstyrte versjonen er bakoverkompatibel.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-9-filtrer-etter-alvorsgrad-og-scope\">Steg 9: Filtrer etter alvorsgrad og scope<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">I store prosjekter med mange transitive avhengigheter kan <code>npm audit<\/code> returnere mange s\u00e5rbarheter. Du kan begrense auditens scope for \u00e5 fokusere p\u00e5 det som faktisk er risikofylt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Kun produksjonsavhengigheter (ekskluder devDependencies)\nnpm audit --omit=dev\n\n# Feiler kun p\u00e5 critical-niv\u00e5\nnpm audit --audit-level=critical\n\n# Feiler p\u00e5 high og critical, men viser alle i rapporten\nnpm audit --audit-level=high\n\n# Kombiner: produksjonsavhengigheter, feiler p\u00e5 high+\nnpm audit --omit=dev --audit-level=high<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>--omit=dev<\/code> er spesielt verdifullt i produksjons-CI-pipelines der du kun bekymrer deg for kode som faktisk kj\u00f8res av sluttbrukere. Dev-avhengigheter som testverkt\u00f8y, lintere og byggeverkt\u00f8y er aldri eksponert i produksjon. S\u00e5rbarheter i disse utgj\u00f8r generelt en betydelig lavere risiko.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Et viktig poeng som mange misforst\u00e5r: <code>--audit-level<\/code> endrer terskelen for hva som gj\u00f8r at kommandoen feiler, men filtrerer ikke rapporten. Med <code>--audit-level=high<\/code> vil rapporten fortsatt vise moderate og low-s\u00e5rbarheter. Kommandoen vil bare returnere exit-kode 1 (feil) hvis det finnes high eller critical-funn.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-10-integrer-npm-audit-i-ci-cd-pipeline\">Steg 10: Integrer npm audit i CI\/CD-pipeline<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">En av de viktigste bruksomr\u00e5dene for <code>npm audit<\/code> er som en automatisk sikkerhetsport i CI\/CD-pipelinen. Kommandoen returnerer exit-kode 1 ved s\u00e5rbarheter over terskelen, som stopper pipelines automatisk.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Komplett GitHub Actions workflow:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># .github\/workflows\/security.yml\nname: Sikkerhetsaudit\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n  schedule:\n    # Kj\u00f8r hverdager kl. 06:00 UTC (08:00 norsk tid)\n    - cron: '0 6 * * 1-5'\n\njobs:\n  audit:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v4\n\n      - uses: actions\/setup-node@v4\n        with:\n          node-version: '22'\n          cache: 'npm'\n\n      - name: Installer avhengigheter (ren installasjon)\n        run: npm ci\n\n      - name: Kj\u00f8r sikkerhetsaudit for produksjon\n        run: npm audit --audit-level=high --omit=dev\n\n      - name: Generer HTML-rapport ved feil\n        if: failure()\n        run: |\n          mkdir -p reports\n          npm audit --json | npx npm-audit-html --output reports\/audit.html\n\n      - name: Last opp sikkerhetsrapport\n        if: failure()\n        uses: actions\/upload-artifact@v4\n        with:\n          name: security-audit-report\n          path: reports\/audit.html\n          retention-days: 30<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Den planlagte daglige kj\u00f8ringen er kritisk. Nye s\u00e5rbarheter oppdages kontinuerlig. En pakke som var trygg i g\u00e5r kan ha f\u00e5tt en ny CVE i dag. Uten periodisk overv\u00e5king kan prosjektet ditt ha kjente kritiske s\u00e5rbarheter i uker uten at noen vet om det.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-11-npm-ci-vs-npm-install-i-pipelines\">Steg 11: npm ci vs npm install i pipelines<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">I CI-milj\u00f8er b\u00f8r du alltid bruke <code>npm ci<\/code> i stedet for <code>npm install<\/code>. Forskjellene er vesentlige for sikkerhet og reproduserbarhet:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Egenskap<\/th><th>npm install<\/th><th>npm ci<\/th><\/tr><\/thead><tbody><tr><td>L\u00e5ser versjoner<\/td><td>Nei (kan oppgradere innen range)<\/td><td>Ja (bruker package-lock.json n\u00f8yaktig)<\/td><\/tr><tr><td>Sletter node_modules<\/td><td>Nei<\/td><td>Ja (alltid ren installasjon)<\/td><\/tr><tr><td>Feiler ved avvik<\/td><td>Nei<\/td><td>Ja (stopper om lock ikke matcher)<\/td><\/tr><tr><td>Endrer package-lock.json<\/td><td>Kan gj\u00f8re det<\/td><td>Aldri<\/td><\/tr><tr><td>Hastighet i CI<\/td><td>Tregere<\/td><td>Raskere<\/td><\/tr><tr><td>Anbefalt til<\/td><td>Lokal utvikling<\/td><td>CI\/CD og produksjonsbygg<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><code>npm ci<\/code> garanterer reproduserbare bygg. Hvis <code>package-lock.json<\/code> mangler eller ikke stemmer overens med <code>package.json<\/code>, vil <code>npm ci<\/code> feile med en tydelig feilmelding. Dette forhindrer at utilsiktede avhengighetsoppgraderinger sniker seg inn i produksjonsmilj\u00f8et, noe som er s\u00e6rlig viktig for sikkerhetsaudit-resultatene.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"steg-12-komplett-automatiseringsscript\">Steg 12: Komplett automatiseringsscript<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/\/ scripts\/security-check.js\nconst { execSync } = require('child_process');\nconst fs = require('fs');\nconst path = require('path');\n\nfunction runAudit() {\n  console.log('=== npm sikkerhetsaudit ===\\n');\n\n  let auditData;\n  try {\n    const output = execSync('npm audit --json', {\n      encoding: 'utf8',\n      \/\/ npm audit returnerer non-zero exit-kode ved funn,\n      \/\/ men vi \u00f8nsker \u00e5 lese JSON-outputen uansett\n      stdio: ['pipe', 'pipe', 'pipe']\n    });\n    auditData = JSON.parse(output);\n  } catch (err) {\n    if (err.stdout) {\n      try {\n        auditData = JSON.parse(err.stdout);\n      } catch {\n        console.error('Klarte ikke \u00e5 parse audit-output:', err.message);\n        process.exit(2);\n      }\n    } else {\n      console.error('Klarte ikke \u00e5 kj\u00f8re npm audit:', err.message);\n      process.exit(2);\n    }\n  }\n\n  const { vulnerabilities, metadata } = auditData;\n  const counts = metadata.vulnerabilities;\n\n  console.log('S\u00e5rbarhetsoversikt:');\n  console.log(`  Critical: ${counts.critical}`);\n  console.log(`  High:     ${counts.high}`);\n  console.log(`  Moderate: ${counts.moderate}`);\n  console.log(`  Low:      ${counts.low}`);\n  console.log(`  Total:    ${counts.total}\\n`);\n\n  \/\/ Lagre full rapport\n  const reportDir = path.join(process.cwd(), 'reports');\n  if (!fs.existsSync(reportDir)) {\n    fs.mkdirSync(reportDir, { recursive: true });\n  }\n  fs.writeFileSync(\n    path.join(reportDir, 'audit-report.json'),\n    JSON.stringify(auditData, null, 2)\n  );\n  console.log('Full rapport lagret i reports\/audit-report.json\\n');\n\n  \/\/ Feiler ved critical eller high\n  if (counts.critical > 0 || counts.high > 0) {\n    console.error('FEIL: Critical eller high-s\u00e5rbarheter funnet!');\n    console.error('Kj\u00f8r `npm audit fix` for \u00e5 l\u00f8se automatisk fiksbare problemer.');\n    process.exit(1);\n  }\n\n  if (counts.moderate > 0) {\n    console.warn(`ADVARSEL: ${counts.moderate} moderate s\u00e5rbarhet(er) funnet. Planlegg fiks.`);\n  }\n\n  console.log('Sikkerhetsstatus: OK');\n  process.exit(0);\n}\n\nrunAudit();<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Legg til scriptene i <code>package.json<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"name\": \"mitt-prosjekt\",\n  \"version\": \"1.0.0\",\n  \"engines\": {\n    \"node\": \">=22.0.0\",\n    \"npm\": \">=10.0.0\"\n  },\n  \"scripts\": {\n    \"test\": \"jest --coverage\",\n    \"audit:check\": \"node scripts\/security-check.js\",\n    \"audit:fix\": \"npm audit fix\",\n    \"audit:preview\": \"npm audit fix --dry-run\",\n    \"audit:report\": \"npm audit --json | npx npm-audit-html --output reports\/audit.html\",\n    \"preinstall\": \"npm audit --audit-level=critical --omit=dev 2>\/dev\/null || true\"\n  }\n}<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"npm-audit-vs-snyk-vs-github-dependabot-sammenligning\">npm audit vs Snyk vs GitHub Dependabot: sammenligning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Det finnes flere verkt\u00f8y for avhengighetssikkerhet. Her er en sammenligning av de tre mest brukte i Node.js-prosjekter:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Egenskap<\/th><th>npm audit<\/th><th>Snyk<\/th><th>GitHub Dependabot<\/th><\/tr><\/thead><tbody><tr><td>Kostnad<\/td><td>Gratis (innebygd)<\/td><td>Gratis\/betalt plan<\/td><td>Gratis for GitHub-brukere<\/td><\/tr><tr><td>Datakilde<\/td><td>GitHub Advisory DB<\/td><td>Snyk Vulnerability DB<\/td><td>GitHub Advisory DB<\/td><\/tr><tr><td>Automatiske PR-er<\/td><td>Nei<\/td><td>Ja<\/td><td>Ja<\/td><\/tr><tr><td>Kodeflytanalyse (SAST)<\/td><td>Nei<\/td><td>Ja (betalt)<\/td><td>Nei<\/td><\/tr><tr><td>CI-integrasjon<\/td><td>Enkel, innebygd<\/td><td>Avansert via CLI\/API<\/td><td>Innebygd i GitHub<\/td><\/tr><tr><td>Lisenssjekkng<\/td><td>Nei<\/td><td>Ja (betalt)<\/td><td>Nei<\/td><\/tr><tr><td>Exploit-modenhet<\/td><td>Nei<\/td><td>Ja<\/td><td>Nei<\/td><\/tr><tr><td>Oppsett<\/td><td>Ingen (allerede installert)<\/td><td>npm install -g snyk<\/td><td>Konfigurasjonsfil i repo<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">For de fleste Node.js-prosjekter er <code>npm audit<\/code> tilstrekkelig som f\u00f8rste 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\u00f8rre organisasjoner med compliance-krav. <a href=\"https:\/\/docs.github.com\/en\/code-security\/dependabot\/dependabot-alerts\/about-dependabot-alerts\" rel=\"noopener noreferrer\" target=\"_blank\">GitHub Dependabot<\/a> er ideelt for GitHub-baserte prosjekter som \u00f8nsker automatiske sikkerhets-PR-er uten manuell oppf\u00f8lging.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">npm audit og Dependabot deler GitHub Advisory Database som kilde. De vil derfor identifisere de samme s\u00e5rbarhetene. Snyk har sin egen s\u00e5rbarhetsdatabase 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 \u00e5 kombinere npm audit med <a href=\"https:\/\/owasp.org\/www-project-dependency-check\/\" rel=\"noopener noreferrer\" target=\"_blank\">OWASP Dependency-Check<\/a> for bredest mulig dekning.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-vanlige-fallgruver-med-npm-audit-fix\">5 vanlige fallgruver med npm audit fix<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fallgruve 1: Kj\u00f8re npm audit fix &#8211;force uten testing.<\/strong> <code>--force<\/code> kan oppgradere pakker til major-versjoner med brytende endringer. En Express 4.x-applikasjon som oppgraderes til Express 5.x via <code>--force<\/code> kan slutte \u00e5 fungere fordi Express 5 har en ny router-arkitektur og fjernede API-er. L\u00f8sning: Alltid kj\u00f8r testsuiten din etter enhver <code>--force<\/code>-operasjon, og les CHANGELOG for alle oppgraderte pakker.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fallgruve 2: Ignorere &#8220;No fix available&#8221;-meldinger uten oppf\u00f8lging.<\/strong> N\u00e5r npm rapporterer at det ikke finnes noen fiks, betyr det ikke at du ikke trenger \u00e5 gj\u00f8re noe. Det betyr at pakken enn\u00e5 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\u00e5r en fiks blir tilgjengelig.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fallgruve 3: Utelate package-lock.json fra versjonskontroll.<\/strong> Uten <code>package-lock.json<\/code> kan <code>npm audit<\/code> ikke gi n\u00f8yaktige resultater fordi den ikke vet n\u00f8yaktig hvilke versjoner av transitive avhengigheter som er installert. Locking-filen sikrer at alle i teamet og CI-milj\u00f8et installerer n\u00f8yaktig de samme versjonene. Aldri legg <code>package-lock.json<\/code> i <code>.gitignore<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fallgruve 4: Bruke npm install i stedet for npm ci i pipelines.<\/strong> <code>npm install<\/code> kan oppdatere <code>package-lock.json<\/code>, noe som betyr at CI-milj\u00f8et ditt kan installere andre versjoner enn det som er testet lokalt. Dette ugyldiggj\u00f8r audit-resultatene og kan skjule sikkerhetsrisikoer. Bruk alltid <code>npm ci<\/code> i CI\/CD-milj\u00f8er.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fallgruve 5: Kj\u00f8re audit kun ved nye releases.<\/strong> Nye CVE-er publiseres daglig. En pakke som var trygg fredag kan ha en ny kritisk s\u00e5rbarhet mandag. Sett opp daglige planlagte audit-kj\u00f8ringer i CI-systemet ditt, ikke bare ved nye commits. Bruk GitHub Actions&#8217; <code>schedule<\/code>-trigger (se Steg 10) for automatisk daglig overv\u00e5king.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"feilsoking-8-vanlige-problemer-og-losninger\">Feils\u00f8king: 8 vanlige problemer og l\u00f8sninger<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 1: &#8220;Cannot read properties of undefined&#8221; ved npm audit<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: Manglende eller korrupt <code>package-lock.json<\/code>. L\u00f8sning:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>rm -rf node_modules package-lock.json\nnpm install\nnpm audit<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 2: &#8220;ENOAUDIT: No audit found in the registry&#8221;<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: npm kan ikke n\u00e5 audit-endepunktet i registeret. Kontroller nettverkstilgang og proxy-innstillinger:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm config get proxy\nnpm config get https-proxy\nnpm config get registry\n# Verifiser tilgang til registeret:\ncurl -I https:\/\/registry.npmjs.org<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 3: S\u00e5rbarheter gjenoppst\u00e5r etter npm audit fix<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: S\u00e5rbare pakker er transitiv avhengighet av en direkte avhengighet som ikke kan oppgraderes innenfor semver-regler. L\u00f8sning: Bruk <code>overrides<\/code> i <code>package.json<\/code> (se Steg 8) eller oppgrader den direkte avhengigheten manuelt med <code>npm install pakke@nyeste<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 4: npm audit feiler i offline-milj\u00f8<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: <code>npm audit<\/code> krever internettilgang for \u00e5 sp\u00f8rre Advisory Database. For airgapped-milj\u00f8er kan du bruke et privat npm-register (Verdaccio, JFrog Artifactory, GitHub Packages) som speiler Advisory Database og tillater lokale auditsp\u00f8rringer. Alternativt kan du bruke Snyk sin CLI i offline-modus med en lokal kopi av s\u00e5rbarhetsdatabasen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 5: For mange falske positiver fra dev-avhengigheter<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L\u00f8sning: Bruk <code>--omit=dev<\/code> for \u00e5 ekskludere dev-avhengigheter. Testverkt\u00f8y og byggeverkt\u00f8y kj\u00f8res aldri i produksjon og er normalt ikke direkte eksponert for eksterne angripere:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --omit=dev --audit-level=high<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 6: npm audit fix bryter applikasjonen<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: En oppgradert pakke hadde en API-endring innenfor sin semver-versjon (brudd p\u00e5 semver-konvensjon). L\u00f8sning: Tilbakestill med git, identifiser den spesifikke pakken som for\u00e5rsaket problemet, og oppgrader til en version du vet fungerer:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>git checkout package-lock.json\nnpm ci\n# Oppgrader pakker \u00e9n etter \u00e9n\nnpm install lodash@4.17.21\nnpm test\nnpm install express@4.19.2\nnpm test<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 7: Workspace-prosjekter viser feil antall s\u00e5rbarheter<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I npm workspaces kj\u00f8res <code>npm audit<\/code> som standard p\u00e5 hele workspace-treet. For \u00e5 kj\u00f8re audit p\u00e5 ett enkelt workspace:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit --workspace=packages\/min-app\n# eller kortform\nnpm audit -w packages\/min-app<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Problem 8: npm audit rapporterer 0 s\u00e5rbarheter, men Snyk finner fler<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5rsak: Snyk vedlikeholder sin egen propriet\u00e6re s\u00e5rbarhetsdatabase som kan inneholde funn som enn\u00e5 ikke er publisert til GitHub Advisory Database, eller som er spesifikke for Snyk-plattformen. For produksjonskritiske applikasjoner anbefales det \u00e5 bruke komplementerende verkt\u00f8y. Se <a href=\"https:\/\/snyk.io\/blog\/ten-npm-security-best-practices\/\" rel=\"noopener noreferrer\" target=\"_blank\">Snyk sine ti beste npm-sikkerhetspraksiser<\/a> for detaljer om hva de oppdager som npm audit ikke gj\u00f8r.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"avanserte-tips-for-en-moden-sikkerhetsprosess\">Avanserte tips for en moden sikkerhetsprosess<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Konfigurer npm audit som pre-commit-hook.<\/strong> Med Husky kan du kj\u00f8re <code>npm audit --audit-level=critical<\/code> som en pre-commit-hook, slik at ingen kan committe kode som introduserer kritiske s\u00e5rbarheter i produksjonsavhengighetene:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install --save-dev husky\nnpx husky init\necho \"npm audit --audit-level=critical --omit=dev\" > .husky\/pre-commit<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Hold Node.js og npm oppdatert.<\/strong> Eldre versjoner av npm kan mangle advisories for nyere pakker eller ha feil i auditlogikken. Bruk en Node.js-versjonsh\u00e5ndterer (nvm, fnm eller Volta) for enkelt \u00e5 holde runtime oppdatert:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Med nvm\nnvm install --lts\nnvm use --lts\n\n# Oppdater npm separat\nnpm install -g npm@latest<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Sett opp automatiske Dependabot-PR-er som supplement.<\/strong> Kombiner daglig <code>npm audit<\/code> i CI med GitHub Dependabot for automatiske pull requests. Legg til en <code>.github\/dependabot.yml<\/code>-fil:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># .github\/dependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"\/\"\n    schedule:\n      interval: \"weekly\"\n      day: \"monday\"\n      time: \"09:00\"\n      timezone: \"Europe\/Oslo\"\n    labels:\n      - \"security\"\n      - \"dependencies\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Dokumenter bevisst aksepterte risikoer.<\/strong> Noen s\u00e5rbarheter er ikke relevante for din brukscase. For eksempel er en ReDoS-s\u00e5rbarhet (Regular Expression Denial of Service) i en pakke du kun bruker i offline batchprosessering normalt ikke en risiko. Dokumenter slike vurderinger i et <code>SECURITY.md<\/code>-dokument i repoet, slik at teamet vet at de er vurdert og ikke oversett.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Bruk npm audit signatures for ekstra verifisering.<\/strong> 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:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit signatures\n# Verifiserer kryptografiske signaturer for alle installerte pakker<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For mer om truslene <code>npm audit signatures<\/code> beskytter mot, se v\u00e5r artikkel om <a href=\"\/no\/npm-supply-chain-attacks-2026\/\">npm forsyningskjedeangrep<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"relatert-dekning\">Relatert dekning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Denne guiden er del av shattered.io sin Node.js-sikkerhetsserie. Neste steg for en komplett sikkerhetsstrategi:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/no\/npm-supply-chain-attacks-2026\/\">npm forsyningskjedeangrep: 1,2 millioner ondsinnede pakker<\/a> (truslene bak tallene)<\/li>\n<li><a href=\"\/no\/sql-injection-nodejs\/\">SQL Injection i Node.js: 12 steg for sikre databaser<\/a> (sikring av databaselaget)<\/li>\n<li><a href=\"\/no\/helmet-js-nodejs-sikkerhetshoder\/\">Helmet.js i Node.js: Sikkerhetshoder i 12 steg<\/a> (HTTP-sikkerhetshoder)<\/li>\n<li><a href=\"\/no\/csrf-protection-nodejs\/\">CSRF-beskyttelse i Node.js: 12 steg<\/a> (skjemabeskyttelse)<\/li>\n<li><a href=\"\/no\/rate-limiting-nodejs\/\">Rate Limiting i Node.js: 12 steg, 30 min<\/a> (API-overbelastningsbeskyttelse)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ofte-stilte-sporsmal\">Ofte stilte sp\u00f8rsm\u00e5l<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-er-forskjellen-mellom-npm-audit-og-npm-audit-fix\">Hva er forskjellen mellom npm audit og npm audit fix?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>npm audit<\/code> scanner avhengighetene dine og rapporterer s\u00e5rbarheter uten \u00e5 endre noe. <code>npm audit fix<\/code> gj\u00f8r det samme, men fors\u00f8ker i tillegg \u00e5 automatisk oppgradere s\u00e5rbare pakker til sikre versjoner innenfor det tillatte versjonsspennet definert i <code>package.json<\/code>. Start alltid med <code>npm audit<\/code> for \u00e5 forst\u00e5 situasjonen, bruk <code>npm audit fix --dry-run<\/code> for \u00e5 forh\u00e5ndsvise planlagte endringer, og kj\u00f8r deretter <code>npm audit fix<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"er-det-trygt-a-kjore-npm-audit-fix-i-produksjon\">Er det trygt \u00e5 kj\u00f8re npm audit fix i produksjon?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Uten <code>--force<\/code>-flagget er <code>npm audit fix<\/code> generelt trygt fordi det kun oppdaterer innenfor semver-kompatible versjoner. Best practice er likevel: kj\u00f8r <code>--dry-run<\/code> f\u00f8rst, test etter oppdatering, og deploy til staging-milj\u00f8 f\u00f8r produksjon. Gjennomg\u00e5 alltid git-diff p\u00e5 <code>package-lock.json<\/code> for \u00e5 se n\u00f8yaktig hva som endret seg.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-betyr-no-fix-available-i-npm-audit\">Hva betyr &#8220;No fix available&#8221; i npm audit?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">&#8220;No fix available&#8221; betyr at pakkevedlikeholderen enn\u00e5 ikke har publisert en versjon som l\u00f8ser s\u00e5rbarheten. I dette tilfellet b\u00f8r du vurdere om du faktisk er eksponert basert p\u00e5 din brukscase, s\u00f8ke etter en alternativ pakke, og f\u00f8lge med p\u00e5 pakken ved \u00e5 aktivere GitHub-varsler for repositoriet. For kritiske pakker uten fiks b\u00f8r du vurdere midlertidige kompenserende kontroller i din egen kode.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hvordan-handterer-jeg-sarbarheter-i-transitive-avhengigheter\">Hvordan h\u00e5ndterer jeg s\u00e5rbarheter i transitive avhengigheter?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Transitive avhengigheter kan ikke alltid fikses med <code>npm audit fix<\/code>. Bruk <code>overrides<\/code>-feltet i <code>package.json<\/code> for \u00e5 tvinge frem en spesifikk versjon av en transitiv avhengighet. Alternativt kan du oppgradere den direkte avhengigheten som drar inn den s\u00e5rbare pakken. Bruk <code>npm ls pakkenavn<\/code> for \u00e5 forst\u00e5 avhengighetstreet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hvor-ofte-bor-jeg-kjore-npm-audit\">Hvor ofte b\u00f8r jeg kj\u00f8re npm audit?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Kj\u00f8r <code>npm audit<\/code> ved: hvert nye installasjon av avhengigheter, f\u00f8r og etter enhver avhengighetsoppdatering, automatisk via daglige planlagte kj\u00f8ringer i CI\/CD, og som en del av code review-prosessen for PRer som endrer <code>package.json<\/code>. Nye s\u00e5rbarheter oppdages daglig, s\u00e5 periodisk overv\u00e5king er viktigere enn ad-hoc-kj\u00f8ringer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kan-jeg-stole-pa-at-npm-audit-finner-alle-sarbarheter\">Kan jeg stole p\u00e5 at npm audit finner alle s\u00e5rbarheter?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nei. <code>npm audit<\/code> sjekker kun mot kjente, publiserte s\u00e5rbarheter i GitHub Advisory Database. Den oppdager ikke nulldagss\u00e5rbarheter (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 <a href=\"https:\/\/docs.npmjs.com\/cli\/v10\/commands\/npm-audit\" rel=\"noopener noreferrer\" target=\"_blank\">npm audit signatures<\/a> for pakkeintegritetskontroll.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"bor-jeg-committe-package-lock-json-til-git\">B\u00f8r jeg committe package-lock.json til Git?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, alltid for applikasjoner. <code>package-lock.json<\/code> er avgj\u00f8rende for reproduserbare bygg og n\u00f8yaktige audit-resultater. Uten denne filen kan <code>npm ci<\/code> ikke fungere, og <code>npm audit<\/code> mangler informasjon om n\u00f8yaktig 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\u00f8se versjoner med sine egne constraints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-gjor-npm-audit-signatures\">Hva gj\u00f8r npm audit signatures?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>npm audit signatures<\/code> 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\u00e5rbarhetsscanning, og beskytter mot man-in-the-middle-angrep og kompromitterte CDN-er. Kj\u00f8r den separat fra vanlig audit: <code>npm audit signatures<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Prosjektet ditt har 47 kjente s\u00e5rbarheter. Tre av dem er kritiske. Det er meldingen utviklere ser etter en enkel npm install, og det er akkurat det npm audit er laget\u2026<\/p>\n","protected":false},"author":3,"featured_media":113,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-112","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/112","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/comments?post=112"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/112\/revisions"}],"predecessor-version":[{"id":114,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/112\/revisions\/114"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/media\/113"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/media?parent=112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/categories?post=112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/tags?post=112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}