Risikostyring i programvareleverandørkjeden

Risikostyring vs. sikkerhet

Sikkerhet i programvareleverandørkjeden er de tekniske kontrollene: SBOM-er, festede avhengigheter, begrensede bygg. Risikostyring ligger over det. Den spør hvilke leverandører og komponenter virksomheten din er avhengig av, hva som skjer hvis en av dem svikter, og om du har brukt innsatsen din på riktig sted.

Hva er risikoene?

Risiko	Eksempel	Viktigste kontroll
Sårbare komponenter	En feil i et mye brukt bibliotek	SBOM-er og kontinuerlig overvåking
Ondsinnede komponenter	En kapret pakke, eller typosquatting	Vurdering, forsinket innføring, begrensning av utgående trafikk
Forlatte prosjekter	En avhengighet med én vedlikeholder som har gått videre	Helsesjekker og en plan for å erstatte den
Lisensrisiko	En copyleft-komponent i et proprietært produkt	Lisenspolicy
Kompromittert bygg	En kapret GitHub Action når hemmelighetene dine	Festing, isolasjon, minste privilegium
Leverandørrisiko	Produktet eller oppdateringen til en leverandør blir kompromittert	Vurdering, kontrakter, SBOM-er fra leverandører
Regulatorisk risiko	En kunde eller en lov krever dokumentasjon du ikke kan fremlegge	Dokumentasjon per utgivelse

En prosess i seks steg

1. Bygg oversikten. List opp produktene du lager og programvaren du kjøper. For det du bygger, bør du ha en SBOM per utgivelse. Du kan ikke vurdere det du ikke kan se.
2. Ranger etter hva som betyr noe. Et bibliotek i betalingstjenesten din er ikke det samme som ett i et internt verktøy. Vurder produkter etter eksponering, data og forretningsmessig konsekvens.
3. Vurder risikoene. Se på sårbarheter, prosjekthelse, lisenser og hvordan hver leverandør håndterer sikkerhet. Gjør det grundig for det øverste nivået og enklere for alt annet.
4. Behandle dem. For hver risiko bestemmer du om du skal rette, bytte ut, legge til en kontroll eller akseptere. En akseptert risiko trenger en eier og en dato for ny vurdering.
5. Overvåk kontinuerlig. Risiko endrer seg uten at noe endres hos deg, for eksempel når en advisory publiseres eller en vedlikeholder slutter. Årlige gjennomganger går glipp av dette.
6. Rapporter. Gi ledelsen en kort oversikt: de største risikoene, eksponering over tid og hva som ble akseptert. Kunder og revisorer kommer til å be om detaljene.

Vurdering av leverandører

Spørreskjemaer alene forteller deg hva en leverandør sier. Be om ting som viser hva de gjør:

• En SBOM for produktet, med et oppgitt format og en måte å få oppdateringer på
• Hvordan de håndterer sårbarheter, og hvor raskt de varsler kunder
• En sikkerhetskontakt og en policy for offentliggjøring av sårbarheter
• Hvordan de bygger utgivelser, og om de kan vise hvor en utgivelse kom fra
• Hvor lenge en versjon får sikkerhetsrettinger
• Sertifiseringer og revisjonsrapporter som dekker produktet du kjøper

Bygg forventningene inn i kontraktene. Det er mye enklere å kreve en SBOM eller en varslingsfrist ved signering enn etter en hendelse.

Rammeverk å følge

• NIST SP 800-161 er hovedreferansen for risikostyring av cybersikkerhet i leverandørkjeden, eller C-SCRM. Den virker på alle nivåer i en organisasjon og bygger leverandørkjederisiko inn i den bredere risikostyringen.
• NIST SSDF dekker praksiser for sikker utvikling, noe som gjør den til et godt grunnlag for det du krever av leverandører, og av deg selv.
• SLSA gir deg et felles språk for hvor pålitelig et bygg er.
• ISO/IEC 27001:2022 har kontroller for sikkerhet i IKT-leverandørkjeden (Annex A 5.21) og tekniske sårbarheter (8.8). Den krever ikke en SBOM, men SBOM-er er god dokumentasjon for disse kontrollene.
• NIS2 nevner sikkerhet i leverandørkjeden som et påkrevd tiltak for virksomheter som omfattes, i artikkel 21(2)(d).

Slik måler du det

Velg noen få mål som fører til beslutninger:

• Andelen produkter med en SBOM for gjeldende utgivelse
• Tiden det tar å svare på «er vi berørt?» for en ny kritisk sårbarhet
• Eksponeringsvindu: hvor lenge en sårbar versjon var i produksjon
• Andelen leverandører på øverste nivå som er vurdert det siste året
• Antall aksepterte risikoer som har passert datoen for ny vurdering

Der CRACI hjelper

CRACI gir et risikoprogram dataene det vanligvis mangler for programvare du bygger. CRACI registrerer hva hvert GitHub Actions-bygg trakk inn, inkludert deklarerte lisenser, i SBOM-er du kan beholde per utgivelse og dele i CycloneDX eller SPDX. CRACI overvåker det som er levert, viser hvilke bygg som inneholdt en sårbar pakke, så du ser perioden du var berørt, og kan håndheve lisenspolicy og blokkere bygg med policy-gates. Se sikkerhet i programvareleverandørkjeden med CRACI og hvordan verktøyene står seg mot hverandre.

Leverandørvurdering og risikoregisteret ditt blir værende hos styringsverktøyene dine og teamet ditt.

Risikostyring i programvareleverandørkjeden: ofte stilte spørsmål

Hva er risikostyring i programvareleverandørkjeden?

Det er hvordan en organisasjon identifiserer, vurderer og reduserer risikoen fra programvare den ikke har skrevet selv, inkludert pakker med åpen kildekode, kommersielle produkter, SaaS-leverandører og byggeverktøy.

Hva er C-SCRM?

C-SCRM står for cybersecurity supply chain risk management, begrepet NIST bruker. NIST SP 800-161 er hovedveiledningen og dekker hvordan du finner, vurderer og reduserer cyberrisiko i hele leverandørkjeden på alle nivåer i en organisasjon.

Hva er de største risikoene i programvareleverandørkjeden?

Sårbare og ondsinnede komponenter med åpen kildekode, kompromitterte byggesystemer og CI-verktøy, forlatte prosjekter, lisensproblemer og leverandører som blir utsatt for sikkerhetsbrudd.

Hvordan skiller det seg fra risikostyring av tredjeparter?

Risikostyring av tredjeparter ser vanligvis på leverandører som selskaper. Risikostyring i programvareleverandørkjeden går ned på komponentene og byggeprosessene, inkludert prosjekter med åpen kildekode uten noen leverandør bak.

Hvem er ansvarlig for det?

Vanligvis setter sikkerhets- eller risikoledelsen opp programmet, produktsikkerhet eier det selskapet bygger, og innkjøp eller leverandørstyring eier det det kjøper. Utviklingsteamene retter det som blir funnet.