Riskhantering i mjukvarans leveranskedja

Riskhantering vs säkerhet

Säkerhet i mjukvarans leveranskedja är uppsättningen tekniska kontroller: SBOM:er, låsta beroenden, begränsade byggen. Riskhantering ligger ovanför det. Den frågar vilka leverantörer och komponenter din verksamhet är beroende av, vad som händer om en av dem fallerar och om du har lagt din insats på rätt ställe.

Vilka är riskerna?

Risk	Exempel	Främsta kontroll
Sårbara komponenter	En brist i ett allmänt använt bibliotek	SBOM:er och löpande bevakning
Skadliga komponenter	Ett kapat paket, eller typosquatting	Granskning, fördröjd användning, begränsning av utgående trafik
Övergivna projekt	Ett beroende med en enda underhållare som har gått vidare	Hälsokontroller och en ersättningsplan
Licensrisk	En copyleft-komponent i en proprietär produkt	Licenspolicy
Komprometterat bygge	En kapad GitHub Action når dina hemligheter	Låsning, isolering, minsta möjliga behörighet
Leverantörsrisk	En leverantörs produkt eller uppdatering komprometteras	Bedömning, avtal, SBOM:er från leverantörer
Regulatorisk risk	En kund eller en lag kräver underlag som du inte kan ta fram	Registreringar som sparas per release

En process i sex steg

1. Bygg förteckningen. Lista produkterna du gör och programvaran du köper. För det du bygger, ha en SBOM per release. Du kan inte bedöma det du inte kan se.
2. Rangordna efter vad som är viktigt. Ett bibliotek i din betalningstjänst är inte detsamma som ett i ett internt verktyg. Bedöm produkter utifrån exponering, data och affärspåverkan.
3. Bedöm riskerna. Titta på sårbarheter, projekthälsa, licenser och hur varje leverantör hanterar säkerhet. Gör det grundligt för den översta nivån och översiktligt för allt annat.
4. Hantera dem. Bestäm för varje risk om du ska åtgärda, ersätta, lägga till en kontroll eller acceptera. En accepterad risk behöver en ägare och ett datum för omprövning.
5. Bevaka löpande. Risken ändras utan att något ändras på din sida, till exempel när ett säkerhetsmeddelande publiceras eller en underhållare slutar. Årliga genomgångar missar det.
6. Rapportera. Ge ledningen en kort översikt: de största riskerna, exponering över tid och vad som har accepterats. Kunder och revisorer kommer att fråga efter detaljerna.

Bedöma leverantörer

Frågeformulär visar bara vad en leverantör säger. Be om sådant som visar vad de gör:

• En SBOM för produkten, med ett angivet format och ett sätt att få uppdateringar
• Hur de hanterar sårbarheter och hur snabbt de informerar kunder
• En säkerhetskontakt och en policy för sårbarhetsrapportering
• Hur de bygger releaser och om de kan visa var en release kommer ifrån
• Hur länge en version får säkerhetsuppdateringar
• Certifieringar och revisionsrapporter som täcker produkten du köper

Skriv in förväntningarna i avtalen. Det är mycket lättare att kräva en SBOM eller en tidsgräns för underrättelse vid avtalstecknandet än efter en incident.

Ramverk att följa

• NIST SP 800-161 är den främsta referensen för riskhantering för cybersäkerhet i leveranskedjan, eller C-SCRM. Den fungerar på alla nivåer i en organisation och bygger in leveranskedjerisk i den bredare riskhanteringen.
• NIST SSDF täcker arbetssätt för säker utveckling, vilket gör den till en bra grund för vad du begär av leverantörer, och av dig själv.
• SLSA ger dig ett gemensamt språk för hur pålitligt ett bygge är.
• ISO/IEC 27001:2022 innehåller kontroller för säkerhet i IKT-leveranskedjan (Annex A 5.21) och tekniska sårbarheter (8.8). Standarden kräver ingen SBOM, men SBOM:er är bra underlag för de kontrollerna.
• NIS2 anger säkerhet i leveranskedjan som en obligatorisk åtgärd för berörda entiteter, i artikel 21(2)(d).

Så mäter du det

Välj några få mått som leder till beslut:

• Andel produkter med en SBOM för den aktuella releasen
• Tid att svara på ”är vi drabbade?” för en ny kritisk sårbarhet
• Exponeringsfönster: hur länge en sårbar version fanns i produktion
• Andel leverantörer på den översta nivån som bedömts under det senaste året
• Antal accepterade risker som passerat sitt omprövningsdatum

Där CRACI hjälper till

CRACI ger ett riskprogram de data som det oftast saknar för programvara du bygger. CRACI registrerar vad varje GitHub Actions-bygge drog in, inklusive deklarerade licenser, i SBOM:er som du kan spara per release och dela i CycloneDX eller SPDX. CRACI bevakar det som levererats, visar vilka byggen som innehöll ett sårbart paket så att du ser under vilken period du var drabbad, och kan upprätthålla licenspolicy och stoppa byggen med policykontroller. Se säkerhet i mjukvarans leveranskedja med CRACI och hur verktygen står sig mot varandra.

Leverantörsbedömningen och ditt riskregister ligger kvar hos dina styrningsverktyg och ditt team.

Riskhantering i mjukvarans leveranskedja: vanliga frågor

Vad är riskhantering i mjukvarans leveranskedja?

Det är hur en organisation identifierar, bedömer och minskar risken från programvara den inte har skrivit själv, inklusive open source-paket, kommersiella produkter, SaaS-leverantörer och byggverktyg.

Vad är C-SCRM?

C-SCRM står för cybersecurity supply chain risk management, begreppet som NIST använder. NIST SP 800-161 är den främsta vägledningen och täcker hur du hittar, utvärderar och minskar cyberrisker i leveranskedjan på alla nivåer i en organisation.

Vilka är de största riskerna i mjukvarans leveranskedja?

Sårbara och skadliga open source-komponenter, komprometterade byggsystem och CI-verktyg, övergivna projekt, licensproblem och leverantörer som blir utsatta för intrång.

Hur skiljer det sig från hantering av tredjepartsrisker?

Hantering av tredjepartsrisker ser oftast på leverantörer som företag. Riskhantering i mjukvarans leveranskedja går ner till komponenterna och byggprocesserna, inklusive open source-projekt utan någon leverantör bakom sig.

Vem ansvarar för det?

Oftast utformar säkerhets- eller riskledningen programmet, produktsäkerhet äger det företaget bygger, och inköp eller leverantörshantering äger det företaget köper. Utvecklingsteamen åtgärdar det som hittas.