Risikostyring i softwareforsyningskæden

Risikostyring vs. sikkerhed

Forsyningskædesikkerhed for software er de tekniske kontroller: SBOM'er, fastlåste afhængigheder, begrænsede builds. Risikostyring ligger et niveau over. Den spørger, hvilke leverandører og komponenter din forretning afhænger af, hvad der sker, hvis en af dem svigter, og om du har brugt dine kræfter det rigtige sted.

Hvad er risiciene?

Risiko	Eksempel	Vigtigste kontrol
Sårbare komponenter	En fejl i et meget brugt bibliotek	SBOM'er og løbende overvågning
Ondsindede komponenter	En kapret pakke eller typosquatting	Vurdering, forsinket ibrugtagning, begrænsning af udgående trafik
Forladte projekter	En afhængighed med én enkelt maintainer, der er gået videre	Sundhedstjek og en plan for udskiftning
Licensrisiko	En copyleft-komponent i et proprietært produkt	Licenspolitik
Kompromittering af buildet	En kapret GitHub Action når dine secrets	Fastlåsning, isolation, mindste rettigheder
Leverandørrisiko	En leverandørs produkt eller opdatering bliver kompromitteret	Vurdering, kontrakter, SBOM'er fra leverandører
Regulatorisk risiko	En kunde eller en lov kræver dokumentation, du ikke kan fremskaffe	Registreringer gemt pr. release

En proces i seks trin

1. Opbyg fortegnelsen. List de produkter, du laver, og den software, du køber. For det, du bygger, skal du have en SBOM pr. release. Du kan ikke vurdere det, du ikke kan se.
2. Rangér efter det, der betyder noget. Et bibliotek i din betalingstjeneste er ikke det samme som et i et internt værktøj. Vurdér produkter efter eksponering, data og forretningspåvirkning.
3. Vurdér risiciene. Se på sårbarheder, projektets sundhed, licenser og hvordan hver leverandør håndterer sikkerhed. Gå i dybden med det øverste lag og let hen over alt andet.
4. Behandl dem. For hver risiko beslutter du at rette, udskifte, tilføje en kontrol eller acceptere. En accepteret risiko skal have en ejer og en dato for næste gennemgang.
5. Overvåg løbende. Risiko ændrer sig, uden at noget ændrer sig hos dig, for eksempel når en advisory offentliggøres, eller en maintainer stopper. Årlige gennemgange overser det.
6. Rapportér. Giv ledelsen et kort overblik: de største risici, eksponering over tid og hvad der blev accepteret. Kunder og revisorer vil bede om detaljerne.

Vurdering af leverandører

Spørgeskemaer alene fortæller dig, hvad en leverandør siger. Bed om ting, der viser, hvad de gør:

• En SBOM for produktet med et angivet format og en måde at få opdateringer på
• Hvordan de håndterer sårbarheder, og hvor hurtigt de fortæller det til kunderne
• En sikkerhedskontakt og en disclosure-politik
• Hvordan de bygger releases, og om de kan vise, hvor en release kommer fra
• Hvor længe en version modtager sikkerhedsrettelser
• Certificeringer og revisionsrapporter, der dækker det produkt, du køber

Skriv forventningerne ind i kontrakterne. Det er meget lettere at kræve en SBOM eller en varslingsfrist ved underskrivelsen end efter en hændelse.

Rammeværker at følge

• NIST SP 800-161 er hovedreferencen for risikostyring af cybersikkerhed i forsyningskæden, eller C-SCRM. Den fungerer på alle niveauer af en organisation og bygger forsyningskæderisiko ind i den bredere risikostyring.
• NIST SSDF dækker praksis for sikker udvikling, hvilket gør det til et godt grundlag for det, du kræver af leverandører og af dig selv.
• SLSA giver dig et fælles sprog for, hvor troværdigt et build er.
• ISO/IEC 27001:2022 indeholder kontroller for sikkerhed i ikt-forsyningskæden (Annex A 5.21) og tekniske sårbarheder (8.8). Den kræver ikke en SBOM, men SBOM'er er god dokumentation for de kontroller.
• NIS2 nævner i artikel 21, stk. 2, litra d, forsyningskædesikkerhed som en påkrævet foranstaltning for omfattede enheder.

Sådan måler du det

Vælg nogle få mål, der fører til beslutninger:

• Andel af produkter med en SBOM for den aktuelle release
• Tid til at svare på "er vi berørt?" ved en ny kritisk sårbarhed
• Eksponeringsvindue: hvor længe en sårbar version var i produktion
• Andel af de vigtigste leverandører, der er vurderet det seneste år
• Antal accepterede risici, hvor datoen for næste gennemgang er passeret

Hvor CRACI hjælper

CRACI giver et risikoprogram de data, det som regel mangler om software, du bygger. Det registrerer, hvad hvert GitHub Actions-build trak ind, inklusive deklarerede licenser, i SBOM'er, du kan gemme pr. release og dele i CycloneDX eller SPDX. Det overvåger det leverede, viser, hvilke builds der indeholdt en sårbar pakke, så du kan se den periode, du var berørt, og kan håndhæve licenspolitik og blokere builds med policy gates. Se forsyningskædesikkerhed for software med CRACI og hvordan værktøjerne klarer sig i sammenligning.

Leverandørvurdering og dit risikoregister bliver hos dine governance-værktøjer og dit team.

Risikostyring i softwareforsyningskæden: ofte stillede spørgsmål

Hvad er risikostyring i softwareforsyningskæden?

Det er den måde, en organisation identificerer, vurderer og mindsker risikoen ved software, den ikke selv har skrevet, herunder open source-pakker, kommercielle produkter, SaaS-leverandører og build-værktøjer.

Hvad er C-SCRM?

C-SCRM står for cybersecurity supply chain risk management, det udtryk NIST bruger. NIST SP 800-161 er den vigtigste vejledning og dækker, hvordan du finder, vurderer og mindsker cyberrisici i hele forsyningskæden på alle niveauer af en organisation.

Hvad er de største risici i softwareforsyningskæden?

Sårbare og ondsindede open source-komponenter, kompromitterede build-systemer og CI-værktøjer, forladte projekter, licensproblemer og leverandører, der rammes af et sikkerhedsbrud.

Hvordan adskiller det sig fra styring af tredjepartsrisiko?

Styring af tredjepartsrisiko ser som regel på leverandører som virksomheder. Risikostyring i softwareforsyningskæden går helt ned til komponenter og build-processer, herunder open source-projekter uden en leverandør bag sig.

Hvem har ansvaret for det?

Typisk fastlægger sikkerheds- eller risikoledelsen programmet, produktsikkerhed ejer det, virksomheden bygger, og indkøb eller leverandørstyring ejer det, den køber. Engineering-teams retter det, der bliver fundet.