Säkerhetschecklistan alla utvecklare bör gå igenom innan publicering

Att publicera paket till npm innebär att man lämnar över kod till en miljö där både legitima användare och illasinnade aktörer rör sig. Enskilda paket kan hamna i tusentals projekt och pipelines samtidigt, vilket gör dem till attraktiva mål för angrepp.

"Det funkar på min maskin" räcker inte längre som försvar. Det krävs ett systematiskt säkerhetstänkande redan innan paketet når publiken.

Varför säkerhetsgranskning är viktig redan innan publicering

npm-ekosystemet är både en styrka och en svaghet för JavaScript-utvecklare. Ett enda paket kan påverka stora delar av ett beroendeträd och få tillgång till känsliga delar av byggprocessen. Därför är det viktigt att tänka på vad som faktiskt händer när någon installerar din kod.

De flesta säkerhetsproblem går att undvika med rätt verktyg och rutiner.

De 12 vanligaste attackvektorerna mot npm-paket

1. Kontoövertagande och skadlig publicering

Om en angripare tar över ditt npm-konto kan de publicera en modifierad version av ditt paket. Användarna hämtar sedan den skadliga versionen automatiskt.

Hur du skyddar dig:

• Aktivera 2FA på ditt npm-konto
• Använd tokens med begränsad behörighet istället för huvudlösenordet
• Sätt upp godkännandeflöden för publicering
• Bevaka publiceringsloggarna noga

2. Livscykelhakar som kör kod vid installation

npm tillåter att kod körs redan under installationen via preinstall och postinstall. En angripare kan därmed exekvera godtycklig kod innan ditt paket ens har laddats.

Så hanterar du det:

• Granska alla livscykelhakar i package.json
• Fråga dig om du verkligen behöver köra kod vid installation
• Håll eventuella hakar så enkla och transparenta som möjligt
• Överväg att flytta logiken till byggtiden istället

3. Självreplikerande maskar i npm

En attack kan sprida sig genom att modifiera andra paket i node_modules. Detta skapar en kedjereaktion som sprider skadlig kod över hela beroendeträdet.

Så skyddar du dig:

• Undvik att ändra filer under installationen
• Rör inte andra paket eller deras kod
• Håll beroenden isolerade
• Använd npm audit och andra skanningsverktyg regelbundet

4. Angrepp via CI/CD-identiteter

CI/CD-pipelines innehåller ofta tokens och åtkomstnycklar. Om en attackerad paketversion kommer in i byggkedjan kan en angripare få tillgång till flera system samtidigt.

Försvar på djupet:

• Använd tokens med begränsad behörighet för varje steg
• Rotera tokens regelbundet
• Hardkoda aldrig hemligheter i skript
• Överväg OpenID Connect för autentisering
• Kontrollera vem som har tillgång till publiceringsnycklarna

5. Beroenden hämtade direkt från Git

Att hämta beroenden från Git-arkiv omdirigerar bypassar npm:s säkerhetssystem. En angripare kan skapa en skadlig gaffel och få användare att installera från den.

Motåtgärder:

• Fäst beroenden vid specifika versioner på npm istället för Git
• Om du måste använda Git-beroenden, verifiera commit-hashen
• Använd aldrig latest eller grenar från okända arkiv
• Dokumentera varför ett visst Git-beroende är nödvändigt

6. Dynamiska beroenden hämtade under körning

Vissa paket hämtar kod dynamiskt vid runtime. Det skapar en osynlig attackyta där ditt paket i essens blir en laddare för skadlig nyttolast.

Best practice:

• Deklarera alla beroenden statiskt i package.json
• Hämtar aldrig och exekverar kod dynamiskt
• Använd statiska analysverktyg för att detectera dynamic requires
• Om du behöver flexibilitet, designa lösningen utan code execution

7. Nätverkshot som ser legitima ut

Angripare kan använda npm-paket för att hämta phishing-sidor eller andra nätverkstypiska hot. A package may look legitimate while redirecting to fake login pages.

Hur du skyddar dina användare:

• Var transparent med vad ditt paket gör
• Klargör dina officiella domäner och dokumentationssidor
• Implementera CSP headers på webbsidor som kopplas till ditt paket
• Bevaka misstänkta varianter av ditt paketnamn
• Rapportera suspekta paket till npm