Ohjelmistotoimitusketjun riskienhallinta

Riskienhallinta vs. tietoturva

Ohjelmistotoimitusketjun tietoturva on joukko teknisiä kontrolleja: SBOM:t, kiinnitetyt riippuvuudet, rajoitetut buildit. Riskienhallinta on tätä ylemmällä tasolla. Se kysyy, mistä toimittajista ja komponenteista liiketoimintasi on riippuvainen, mitä tapahtuu, jos jokin niistä pettää, ja oletko käyttänyt panoksesi oikeaan paikkaan.

Mitä riskit ovat?

Riski	Esimerkki	Pääkontrolli
Haavoittuvat komponentit	Virhe laajasti käytetyssä kirjastossa	SBOM:t ja jatkuva valvonta
Haitalliset komponentit	Kaapattu paketti tai typosquatting	Tarkastus, viivästetty käyttöönotto, lähtevän liikenteen rajoitukset
Hylätyt projektit	Riippuvuus, jonka ainoa ylläpitäjä on siirtynyt muihin tehtäviin	Kuntotarkistukset ja korvaussuunnitelma
Lisenssiriski	Copyleft-komponentti suljetun lähdekoodin tuotteessa	Lisenssikäytäntö
Buildin vaarantuminen	Kaapattu GitHub Action pääsee käsiksi salaisuuksiisi	Kiinnitys, eristys, vähimmät oikeudet
Toimittajariski	Toimittajan tuote tai päivitys on vaarantunut	Arviointi, sopimukset, toimittajien SBOM:t
Sääntelyriski	Asiakas tai laki vaatii näyttöä, jota et pysty tuottamaan	Julkaisukohtaisesti säilytetyt tallenteet

Kuusivaiheinen prosessi

1. Kokoa inventaario. Listaa valmistamasi tuotteet ja ostamasi ohjelmistot. Pidä rakentamistasi ohjelmistoista SBOM jokaista julkaisua kohden. Et voi arvioida sitä, mitä et näe.
2. Järjestä tärkeyden mukaan. Maksupalvelusi kirjasto ei ole sama asia kuin sisäisen työkalun kirjasto. Luokittele tuotteet altistumisen, datan ja liiketoimintavaikutusten mukaan.
3. Arvioi riskit. Tarkastele haavoittuvuuksia, projektien kuntoa, lisenssejä ja sitä, miten kukin toimittaja hoitaa tietoturvan. Tee se perusteellisesti tärkeimmälle tasolle ja kevyesti kaikelle muulle.
4. Käsittele ne. Päätä jokaisesta riskistä, korjaatko sen, korvaatko komponentin, lisäätkö kontrollin vai hyväksytkö riskin. Hyväksytyllä riskillä on oltava omistaja ja tarkistuspäivä.
5. Valvo jatkuvasti. Riski muuttuu ilman mitään muutosta sinun puolellasi, esimerkiksi kun tietoturvatiedote julkaistaan tai ylläpitäjä lähtee. Vuosittaiset katselmukset eivät huomaa tätä.
6. Raportoi. Anna johdolle lyhyt näkymä: suurimmat riskit, altistuminen ajan myötä ja mitä on hyväksytty. Asiakkaat ja auditoijat kysyvät yksityiskohtia.

Toimittajien arviointi

Pelkät kyselylomakkeet kertovat, mitä toimittaja sanoo. Pyydä asioita, jotka osoittavat, mitä se tekee:

• Tuotteen SBOM, jolla on ilmoitettu formaatti ja tapa saada päivitykset
• Miten toimittaja käsittelee haavoittuvuudet ja kuinka nopeasti se kertoo niistä asiakkaille
• Tietoturvayhteyshenkilö ja julkistamiskäytäntö
• Miten se rakentaa julkaisunsa ja pystyykö se osoittamaan, mistä julkaisu on peräisin
• Kuinka kauan versio saa tietoturvakorjauksia
• Sertifioinnit ja auditointiraportit, jotka kattavat ostamasi tuotteen

Kirjaa odotukset sopimuksiin. SBOM:n tai ilmoitusajan vaatiminen on paljon helpompaa sopimusta allekirjoitettaessa kuin tietoturvapoikkeaman jälkeen.

Noudatettavat viitekehykset

• NIST SP 800-161 on tärkein viiteaineisto kyberturvallisuuden toimitusketjuriskien hallintaan (C-SCRM). Se toimii organisaation kaikilla tasoilla ja liittää toimitusketjuriskit osaksi laajempaa riskienhallintaa.
• NIST SSDF kattaa turvallisen kehityksen käytännöt, joten se on hyvä pohja sille, mitä vaadit toimittajilta – ja itseltäsi.
• SLSA antaa yhteisen kielen sille, kuinka luotettava buildi on.
• ISO/IEC 27001:2022 sisältää kontrollit ICT-toimitusketjun tietoturvalle (liite A 5.21) ja teknisille haavoittuvuuksille (8.8). Se ei vaadi SBOM:ia, mutta SBOM:t ovat hyvää näyttöä näistä kontrolleista.
• NIS2 nimeää toimitusketjun tietoturvan pakolliseksi toimenpiteeksi soveltamisalaan kuuluville toimijoille artiklan 21 kohdan 2 d alakohdassa.

Mitä SBOM:t todistavat kunkin viitekehyksen alla kontrolli kontrollilta, katso SBOM:t ISO 27001-, SOC 2- ja NIS2-näyttönä.

Miten sitä mitataan

Valitse muutama mittari, jotka johtavat päätöksiin:

• Niiden tuotteiden osuus, joiden nykyisestä julkaisusta on SBOM
• Aika vastata kysymykseen ”koskeeko tämä meitä?”, kun uusi kriittinen haavoittuvuus julkaistaan
• Altistumisikkuna: kuinka kauan haavoittuva versio oli tuotannossa
• Viimeisen vuoden aikana arvioitujen tärkeimpien toimittajien osuus
• Niiden hyväksyttyjen riskien määrä, joiden tarkistuspäivä on ohitettu

Missä CRACI auttaa

CRACI antaa riskienhallintaohjelmalle ne tiedot, jotka siltä yleensä puuttuvat itse rakentamistasi ohjelmistoista. Se tallentaa, mitä kukin GitHub Actions -buildi haki, ilmoitetut lisenssit mukaan lukien, SBOM:eiksi, jotka voit säilyttää julkaisukohtaisesti ja jakaa CycloneDX- tai SPDX-muodossa. Se valvoo toimitettua ohjelmistoa, näyttää, mitkä buildit sisälsivät haavoittuvan paketin, jotta näet ajanjakson, jolloin olit altistunut, ja voi valvoa lisenssikäytäntöä ja estää buildeja käytäntöporteilla. Katso ohjelmistotoimitusketjun tietoturva CRACI:lla ja miten työkalut vertautuvat.

Toimittajien arviointi ja riskirekisteri jäävät hallintotyökaluillesi ja tiimillesi.

Ohjelmistotoimitusketjun riskienhallinta: usein kysytyt kysymykset

Mitä ohjelmistotoimitusketjun riskienhallinta on?

Sillä organisaatio tunnistaa, arvioi ja vähentää riskiä, joka syntyy ohjelmistoista, joita se ei ole itse kirjoittanut, kuten avoimen lähdekoodin paketeista, kaupallisista tuotteista, SaaS-toimittajista ja build-työkaluista.

Mitä C-SCRM tarkoittaa?

C-SCRM tulee sanoista cybersecurity supply chain risk management eli kyberturvallisuuden toimitusketjuriskien hallinta; termi on NISTin käyttämä. NIST SP 800-161 on sen tärkein ohjeistus, ja se kattaa, miten kyberriskejä löydetään, arvioidaan ja vähennetään koko toimitusketjussa organisaation kaikilla tasoilla.

Mitkä ovat suurimmat ohjelmistotoimitusketjun riskit?

Haavoittuvat ja haitalliset avoimen lähdekoodin komponentit, vaarantuneet build-järjestelmät ja CI-työkalut, hylätyt projektit, lisenssiongelmat ja toimittajat, joihin murtaudutaan.

Miten se eroaa kolmansien osapuolten riskienhallinnasta?

Kolmansien osapuolten riskienhallinta tarkastelee yleensä toimittajia yrityksinä. Ohjelmistotoimitusketjun riskienhallinta menee komponentteihin ja build-prosesseihin asti, mukaan lukien avoimen lähdekoodin projektit, joiden takana ei ole toimittajaa.

Kuka siitä vastaa?

Tyypillisesti tietoturva- tai riskijohto määrittää ohjelman, tuoteturvallisuus vastaa siitä, mitä yritys rakentaa, ja hankinta tai toimittajahallinta siitä, mitä se ostaa. Kehitystiimit korjaavat löydökset.