Bästa praxis för säkerhet i mjukvarans leveranskedja

Källkod

• Kräv stark autentisering. Använd flerfaktorsautentisering för varje konto på kodhostingtjänster.
• Skydda huvudgrenen. Kräv granskning före merge, och låt ingen pusha direkt till en releasegren.
• Håll hemligheter borta från koden. Skanna efter dem vid varje push, och rotera allt som har exponerats.
• Behandla arbetsflödesfiler som kod. En ändring i en pipeline kan nå dina hemligheter, så kräv att ägare granskar dem.

Beroenden

• Checka in en lockfile och installera från den. Använd npm ci och dess motsvarigheter, så att byggen inte plockar upp nya versioner av misstag. En lockfile har begränsningar, men det är där du ska börja.
• Lägg in en väntetid för nya versioner. Skadliga releaser upptäcks ofta kort efter att de dykt upp, så om du inte börjar använda en version samma dag som den publiceras får det en chans att hända.
• Begränsa installationsskript. Stäng av dem där du kan. Skript som körs vid installation är hur npm-maskar sprids.
• Granska nya beroenden. Kontrollera namnet för typosquatting, och titta på underhåll och popularitet. OpenSSF Scorecard automatiserar en del av detta.
• Skydda interna paketnamn. Använd scopes och registerkonfiguration, så att ett publikt paket inte kan ta ett internt pakets plats genom dependency confusion.
• Ta bort det du inte behöver. Varje beroende är ytterligare något att bevaka.

Bygge och CI/CD

• Lås GitHub Actions till en fullständig commit-hash. Taggar kan flyttas, vilket komprometteringen av tj-actions visade.
• Begränsa vad varje jobb kan göra. Ge arbetsflödets token minsta möjliga behörighet, och använd kortlivade inloggningsuppgifter i stället för långlivade hemligheter.
• Begränsa utgående trafik. Ett bygge behöver paket från kända källor och publicerar till kända platser. Blockera allt annat, så har stulna hemligheter ingenstans att ta vägen. Se egress-policy för GitHub Actions.
• Kör varje jobb i en ny, isolerad miljö. Inget ska följa med från ett jobb till nästa, allra minst från en pull request av en extern bidragsgivare.
• Behandla cachar som indata. En förgiftad cache överlever mellan byggen, och det den återställer är lätt att förbise. Se GitHub Actions-cache.

För hela listan, se checklistan för säkerhet i CI/CD-pipelinen och hur runner-säkerhet står sig i jämförelse.

Release

• Generera en SBOM för varje release, från bygget. Spara den med artefakten. Se bästa praxis för SBOM.
• Signera artefakter och publicera proveniens. Då kan användarna kontrollera var en release kommer ifrån. SLSA beskriver nivåerna.
• Bygg releaser bara i CI. En release från en laptop har ingen tillförlitlig registrering bakom sig.
• Använd samma artefakt från test till produktion. Flytta vidare det du testade i stället för att bygga om det, så att registreringen förblir korrekt.

Efter release

• Bevaka det du levererat. Fortsätt att kontrollera SBOM:erna för releaser som stöds mot nya sårbarheter.
• Prioritera med mer än CVSS. Använd CISA KEV, EPSS och kontext. Se så prioriterar du sårbarheter.
• Vet hur länge du var exponerad. Bygghistoriken visar vilka releaser som innehöll ett paket, och från när.
• Ha en plan innan du behöver den. Bestäm vem som triagerar, vem som åtgärdar och vem som pratar med kunder. Se livscykeln för sårbarhetshantering.
• Öva med ett verkligt scenario. Fråga hur lång tid det skulle ta att hitta varje release med ett visst paket. Om svaret är dagar, börja där.

Vad du ska göra först

När	Gör det här
Den här veckan	Flerfaktorsautentisering, lockfiler i CI, låsta GitHub Actions, arbetsflödestokens med minsta möjliga behörighet
Den här månaden	SBOM från varje releasebygge, beroendevarningar med en ägare, skanning efter hemligheter
Det här kvartalet	Regler för utgående trafik från byggen, bevakning av levererade releaser, en testad incidentplan
Därefter	Signerad proveniens, en formell genomgång av täckningen mot SLSA eller NIST SSDF, SBOM:er från leverantörer

Vilka av dessa CRACI hanterar

CRACI täcker bygget och allt som kommer efter det. Som din GitHub Actions-runner kör CRACI varje jobb i en egen isolerad virtuell maskin, registrerar varje paket som jobbet hämtar i en SBOM, markerar paket som återställs från CI-cachar och upprätthåller en egress-policy som blockerar anslutningar som ditt bygge inte behöver. CRACI fortsätter sedan att kontrollera det som levererats, visar vilka byggen som innehöll ett sårbart paket och kan stoppa byggen med policykontroller.

Resten ligger kvar hos dina andra verktyg: CRACI skannar inte källkod eller hemligheter, upptäcker inte nya skadliga paket utifrån beteende och signerar inte SBOM:er eller proveniens. Se verktyg för säkerhet i mjukvarans leveranskedja i jämförelse för vad som fyller varje lucka.

Bästa praxis för säkerhet i mjukvarans leveranskedja: vanliga frågor

Hur säkrar du en mjukvaruleveranskedja?

Vet vad du levererar med en SBOM från varje releasebygge, styr vad som kommer in med lockfiler och granskning, skydda bygget genom att begränsa hemligheter och utgående trafik, och fortsätt att bevaka det du har släppt.

Vad bör ett litet team göra först?

Slå på flerfaktorsautentisering, installera från lockfiler i CI, lås GitHub Actions till commit-hashar och ge arbetsflödestokens minsta möjliga behörighet. De stegen tar några dagar och stänger vanliga attackvägar.

Hur förhindrar du skadliga paket?

Inget enskilt steg gör det. Vänta med att börja använda nya versioner, begränsa installationsskript och granska nya beroenden. Att begränsa utgående trafik från byggen minskar skadan om ett skadligt paket slinker igenom.

Varför låsa GitHub Actions till en commit-hash?

Eftersom en versionstagg kan flyttas till annan kod. En fullständig commit-hash pekar alltid på samma kod, så en kapad tagg når inte din pipeline.

Hur ofta bör du granska din leveranskedja?

Bevakningen ska vara löpande. Gå igenom din beroendepolicy, arbetsflödesbehörigheter och incidentplan minst en gång om året, och efter varje incident i din stack.