Vad är säkerhet i mjukvarans leveranskedja?

Vad är mjukvarans leveranskedja?

Mjukvarans leveranskedja är alla och allt som är inblandat i att få programvara från en utvecklares editor till produktion. Tänk på den som fyra steg, vart och ett med sina egna risker.

Steg	Vad det omfattar	Vad som går fel
Källa	Din kod, dina repon och utvecklarkonton	Stulna inloggningsuppgifter, skadliga commits, läckta hemligheter
Beroenden	Open source-paket, basavbilder, tredjepartskod	Sårbara versioner, skadliga releaser, typosquatting
Bygge	CI-runners, GitHub Actions, byggverktyg, cachar	Komprometterade actions, förgiftade cachar, stulna hemligheter från pipelinen
Release	Artefakter, register, driftsättningar, uppdateringar	Utbytta artefakter, manipulerade uppdateringar, ingen registrering av vad som levererades

Varför det är viktigt nu

Det mesta du levererar har du inte skrivit själv. En modern applikation består till största delen av öppen källkod, och varje direkt beroende drar med sig andra som ingen i ditt team har valt. Paketen körs med samma åtkomst som din egen kod, och deras installationsskript kan köras i din CI-pipeline, bredvid dina hemligheter.

De senaste årens incidenter visar hur det utnyttjas:

• SolarWinds: bygget komprometterades, så ett rent källkodsträd gav en förgiftad release.
• Log4Shell: en brist i ett enda loggningsbibliotek nådde produkter som aldrig visste att de använde det.
• xz utils: en betrodd bidragsgivare smög in en bakdörr i ett projekt som finns i Linux-distributioner.
• tj-actions: en kapad GitHub Action körde angriparens kod i pipelines som använde den, med hemligheter inom räckhåll.
• Shai-Hulud: en mask spreds genom npm-paket och stal tokens från datorer och CI-jobb som installerade dem.

För hur attackerna fungerar steg för steg, se vad är en attack mot leveranskedjan.

Så fungerar säkerhet i mjukvarans leveranskedja

Ett säkerhetsprogram behöver fyra saker. Allt annat är detaljer.

1. Vet vad du levererar. Ha en korrekt SBOM för varje release, från bygget som producerade den, inklusive transitiva beroenden.
2. Styr vad som kommer in. Lås versioner, använd en lockfile, begränsa varifrån byggen kan hämta och granska nya paket.
3. Skydda bygget. Isolera jobb, begränsa hemligheter, lås actions till en commit och begränsa utgående trafik, så att ett komprometterat paket inte kan skicka dina tokens någonstans. Se runner-säkerhet och därför hör säkerhet i leveranskedjan hemma i CI.
4. Fortsätt att bevaka det som levererats. Nya sårbarheter påverkar programvara som redan är i produktion. Bevaka den, spåra vilka releaser som berörs och följ varje åtgärd fram till en ny release.

För den detaljerade checklistan, se bästa praxis för säkerhet i mjukvarans leveranskedja.

Ramverk och regelverk

Namn	Vad det är	Bäst för
SLSA	Nivåer för byggintegritet och proveniens	Att härda hur programvara byggs
NIST SSDF	Arbetssätt för säker utveckling, SP 800-218	Ett fullständigt program för säker utveckling
NIST SP 800-161	Riskhantering för cybersäkerhet i leveranskedjan	Riskhantering i hela organisationen
OpenSSF Scorecard	Automatiska kontroller av open source-projekts hälsa	Att granska beroenden
Cyber Resilience Act	EU-lag för produkter med digitala element	Försäljning i EU. Se vad är CRA

Vilka verktyg ingår?

Ingen enskild produkt täcker allt detta. Kategorin delas upp i SCA-verktyg, SBOM-verktyg, säkerhet för CI/CD och runners, paketbrandväggar, application security posture management och binäranalys. För vad vart och ett gör och vem som säljer det, se verktyg för säkerhet i mjukvarans leveranskedja i jämförelse och vad de kostar.

Var du ska börja

1. Generera en SBOM för din viktigaste produkt från dess CI-bygge, och läs den.
2. Slå på varningar för sårbarheter i beroenden, och bestäm vem som äger dem.
3. Lås dina GitHub Actions till en commit och granska vilka hemligheter dina arbetsflöden kan nå.
4. Begränsa utgående trafik från dina byggen till de värdar de faktiskt behöver.
5. Sätt upp bevakning av det du har levererat, inte bara det du bygger.

Så angriper CRACI problemet

CRACI börjar i bygget, eftersom bygget är det enda stället som ser allt. CRACI ersätter dina GitHub-hostade runners med snabbare och billigare runners som registrerar varje paket som varje jobb hämtar, i alla led av beroendeträdet och inklusive paket som återställs från CI-cachar. Egress-policyn blockerar anslutningar som ditt bygge inte behöver, så den skyddar dig även mot en attack som ingen har sett tidigare. CRACI fortsätter sedan att kontrollera det som levererats mot nya sårbarheter och följer varje sårbarhet från triagering till en åtgärdad release. Se säkerhet i mjukvarans leveranskedja med CRACI.

Säkerhet i mjukvarans leveranskedja: vanliga frågor

Vad är säkerhet i mjukvarans leveranskedja?

Det innebär att skydda allt som går in i din programvara innan den når användarna: open source-beroenden, byggsystem, verktyg i pipelinen och releaser.

Vad är ett exempel på en attack mot mjukvarans leveranskedja?

I SolarWinds-attacken komprometterades bygget, så kunderna fick en förgiftad uppdatering från en betrodd leverantör. I Shai-Hulud-attackerna spreds en mask genom npm-paket och stal tokens från datorerna som installerade dem.

Vad är skillnaden mellan säkerhet i leveranskedjan och applikationssäkerhet?

Applikationssäkerhet handlar om brister i koden du skriver. Säkerhet i leveranskedjan handlar om det du inte har skrivit och om hur din programvara byggs och släpps. Ett säkerhetsprogram behöver båda.

Räcker en SBOM för säkerhet i leveranskedjan?

Nej. En SBOM visar vad du levererar, vilket är grunden. Du behöver också styra vad som kommer in, skydda bygget och fortsätta att bevaka det du har släppt.

Vilka är de viktigaste ramverken?

SLSA för byggintegritet, NIST SSDF för arbetssätt för säker utveckling och NIST SP 800-161 för riskhantering i leveranskedjan. I EU ställer Cyber Resilience Act rättsliga krav på produkter med digitala element.

Vem äger säkerheten i mjukvarans leveranskedja?

Den ligger oftast hos applikations- eller produktsäkerhet, i samarbete med plattforms- och DevOps-team som driver pipelinerna. Åtgärderna går sedan till utvecklingsteamen som äger varje tjänst.