Sist oppdatert: 25. juni 2026
En moderne nettside eller webapplikasjon består typisk av noen tusen linjer kode som utvikleren har skrevet selv, og hundretusenvis av linjer fra åpne biblioteker som andre har skrevet. Det er ikke juks. Det er slik all moderne programvare bygges, og det er grunnen til at en liten bedrift i dag kan få løsninger som ville kostet millioner å bygge fra bunnen av.
Men det betyr også noe de færreste tenker over: mesteparten av koden bedriften din kjører på, har verken du eller utvikleren din lest.
Hva som har skjedd det siste året
Frem til nylig var angrep mot disse åpne byggeklossene mest et irritasjonsmoment for utviklere. Det har endret seg. Sikkerhetsselskapet Sonatype har nå blokkert over 1,2 millioner ondsinnede pakker i åpne kodebiblioteker totalt. Over 450 000 av dem kom bare i 2025, en økning på 75 prosent fra året før.
Og 2026 har vært verre. Noen eksempler fra de siste månedene:
- I mars ble axios, et av verdens mest brukte JavaScript-biblioteker med rundt 100 millioner ukentlige nedlastinger, kapret via én kompromittert vedlikeholder-konto. I omtrent tre timer fikk alle som installerte biblioteket med seg skadevare på kjøpet.
- I mai ble node-ipc, et grunnbibliotek med over 10 millioner ukentlige nedlastinger, publisert i tre forgiftede versjoner designet for å stjele passord og nøkler.
- I juni ble 32 pakker i Red Hats offisielle navnerom kompromittert, via en ansatt sin kaprede konto, utenom all kodegjennomgang.
Fellesnevneren: angriperne går ikke lenger etter bedriften din direkte. De forgifter byggeklossene alle bruker, og lar programvaren selv bære smitten videre. Flere av årets angrep har vært selvreplikerende: skadevare som automatisk sprer seg til nye pakker.
Hvorfor dette angår en liten bedrift i Norge
Det er fristende å tenke at dette er et problem for de store. Det er det ikke, av en enkel grunn: angrepene er automatiserte. En forgiftet byggekloss skiller ikke mellom en global nettbutikk og en lokal bedrift på Haugalandet. Den kjører der den havner.
Konsekvensene lander uansett hos deg. Er nettbutikken din bygget på en kompromittert komponent, kan betalingsinformasjon skimmes i kassen. Har kontaktskjemaet ditt en forgiftet avhengighet, kan kundedata lekke. Og ansvaret for personopplysningene ligger hos bedriften din, ikke hos et anonymt kodebibliotek.
En gjennomsnittlig kommersiell kodebase inneholder i dag over 900 åpne komponenter, og ni av ti har komponenter som er mer enn fire år gamle. Det er mye kode ingen følger med på.
Hva en ansvarlig utvikler faktisk gjør
Den gode nyheten er at forsvaret ikke er magi. Det er disiplin, og det ser omtrent slik ut:
- Låste versjoner. Prosjektet installerer nøyaktig de versjonene som er testet og godkjent, aldri «nyeste versjon, hva enn det måtte være». Da hjelper det ikke om en forgiftet versjon publiseres i morgen; den blir ikke med.
- Gjennomgang før oppdatering. Avhengigheter oppdateres bevisst og kontrollert, ikke automatisk og blindt. Nye versjoner får modne litt før de tas i bruk.
- Færrest mulig avhengigheter. Hver byggekloss som ikke trengs, fjernes. Mindre kode fra andre betyr mindre angrepsflate.
- Installasjonsskript slås av der det er mulig. Det er nettopp disse skriptene de fleste av årets angrep bruker for å kjøre skadevare i det pakken installeres.
- Jevnlige sikkerhetsrevisjoner. Automatiske sjekker som varsler når en komponent i løsningen får kjente sårbarheter.
Dette er ikke eksotiske tiltak. Det er håndverk. Vi bruker dem selv på alt vi bygger og drifter, og det er en del av grunnen til at vi sikkerhetstester løsninger før de lanseres.
Dette er ikke et argument mot åpen kildekode
La det være helt tydelig: åpen kildekode er fundamentet for moderne programvareutvikling, og det er et gode. Alternativet, at hver utvikler skriver alt selv, ville gitt dyrere, dårligere og mindre sikker programvare. Problemet er ikke de åpne byggeklossene. Problemet er å bruke dem uten disiplin.
Spørsmålene du kan stille leverandøren din
Du trenger ikke være teknisk for å ta dette på alvor. Tre spørsmål holder lenge:
- Hvordan håndterer dere avhengigheter i løsningen vår? Et godt svar nevner låste versjoner og kontrollerte oppdateringer. Et dårlig svar er «det oppdaterer seg selv».
- Får vi beskjed hvis en komponent i løsningen vår får en kjent sårbarhet? Svaret bør være ja, og helst automatisk.
- Hvem har ansvaret for å holde dette ved like over tid? Hvis svaret er uklart, er det i praksis ingen.
En leverandør som tar disse spørsmålene på strak arm, tar sannsynligvis også resten av håndverket på alvor. En som blir vag, bør du følge opp.