Mitä on ohjelmistotoimitusketjun tietoturva?

Mikä on ohjelmistotoimitusketju?

Ohjelmistotoimitusketju on kaikki ne ihmiset ja asiat, jotka tarvitaan ohjelmiston viemiseksi kehittäjän editorista tuotantoon. Sen voi jakaa neljään vaiheeseen, joilla kullakin on omat riskinsä.

Vaihe	Mitä siihen kuuluu	Mikä menee pieleen
Lähdekoodi	Oma koodisi, repositoriot ja kehittäjien tilit	Varastetut tunnukset, haitalliset commitit, vuotaneet salaisuudet
Riippuvuudet	Avoimen lähdekoodin paketit, peruskuvat, kolmansien osapuolten koodi	Haavoittuvat versiot, haitalliset julkaisut, typosquatting
Buildi	CI-runnerit, GitHub Actions, build-työkalut, välimuistit	Vaarantuneet actionit, myrkytetyt välimuistit, varastetut CI/CD-putken salaisuudet
Julkaisu	Artefaktit, rekisterit, käyttöönotot, päivitykset	Vaihdetut artefaktit, peukaloidut päivitykset, ei kirjausta siitä, mitä toimitettiin

Miksi sillä on merkitystä nyt

Suurinta osaa toimittamastasi koodista et ole kirjoittanut itse. Moderni sovellus on enimmäkseen avointa lähdekoodia, ja jokainen suora riippuvuus tuo mukanaan muita, joita kukaan tiimistäsi ei valinnut. Nämä paketit toimivat samoilla oikeuksilla kuin oma koodisi, ja niiden asennusskriptit voivat ajautua CI/CD-putkessasi salaisuuksiesi vieressä.

Viime vuosien tapaukset näyttävät, miten tätä käytetään hyväksi:

• SolarWinds: buildi vaarannettiin, joten puhtaasta lähdekoodista syntyi myrkytetty julkaisu.
• Log4Shell: yhden lokikirjaston haavoittuvuus ulottui tuotteisiin, jotka eivät edes tienneet käyttävänsä sitä.
• xz utils: luotettu kontribuuttori ujutti takaoven projektiin, joka on mukana Linux-jakeluissa.
• tj-actions: kaapattu GitHub Action ajoi hyökkääjän koodia sitä käyttäneissä putkissa, salaisuudet ulottuvilla.
• Shai-Hulud: mato levisi npm-pakettien kautta ja varasti tokeneita koneilta ja CI-jobeilta, jotka asensivat ne.

Miten nämä hyökkäykset etenevät vaihe vaiheelta, katso mikä on toimitusketjuhyökkäys.

Miten ohjelmistotoimitusketjun tietoturva toimii

Ohjelma tarvitsee neljä asiaa. Kaikki muu on yksityiskohtia.

1. Tiedä, mitä toimitat. Pidä jokaisesta julkaisusta tarkka SBOM, joka on peräisin sen tuottaneesta buildista, transitiiviset riippuvuudet mukaan lukien.
2. Hallitse, mitä sisään pääsee. Kiinnitä versiot, käytä lukitustiedostoa (lockfile), rajaa, mistä buildit saavat hakea, ja tarkasta uudet paketit.
3. Suojaa buildi. Eristä jobit, rajaa salaisuuksia, kiinnitä actionit commitin perusteella ja rajoita lähtevää liikennettä, jotta vaarantunut paketti ei voi lähettää tokeneitasi minnekään. Katso runnereiden tietoturva ja miksi toimitusketjun tietoturva kuuluu CI:hin.
4. Seuraa jatkuvasti, mitä toimitettiin. Uudet haavoittuvuudet koskevat myös tuotannossa jo olevaa ohjelmistoa. Seuraa sitä, jäljitä, mitkä julkaisut ovat haavoittuvia, ja vie jokainen korjaus uuteen julkaisuun asti.

Yksityiskohtainen tarkistuslista löytyy sivulta ohjelmistotoimitusketjun tietoturvan parhaat käytännöt.

Viitekehykset ja sääntely

Nimi	Mikä se on	Sopii parhaiten
SLSA	Tasot buildin eheydelle ja alkuperätiedoille	Ohjelmiston build-prosessin koventamiseen
NIST SSDF	Turvallisen kehityksen käytännöt, SP 800-218	Kokonaiseen turvallisen kehityksen ohjelmaan
NIST SP 800-161	Kyberturvallisuuden toimitusketjuriskien hallinta	Koko organisaation riskienhallintaan
OpenSSF Scorecard	Avoimen lähdekoodin projektien kunnon automaattiset tarkistukset	Riippuvuuksien arviointiin
Cyber Resilience Act	EU:n kyberkestävyyssäädös digitaalisia elementtejä sisältäville tuotteille	Myyntiin EU:ssa. Katso mikä on CRA

Mitä työkaluja tähän tarvitaan?

Mikään yksittäinen tuote ei kata tätä kaikkea. Kategoria jakautuu SCA-työkaluihin, SBOM-työkaluihin, CI/CD:n ja runnereiden tietoturvaan, pakettipalomuureihin, sovellusten tietoturvatilanteen hallintaan (ASPM) ja binäärianalyysiin. Mitä kukin tekee ja kuka niitä myy, katso ohjelmistotoimitusketjun tietoturvatyökalut vertailussa ja mitä ne maksavat.

Mistä aloittaa

1. Generoi tärkeimmälle tuotteellesi SBOM sen CI-buildista ja lue se.
2. Ota käyttöön riippuvuuksien haavoittuvuushälytykset ja päätä, kuka niistä vastaa.
3. Kiinnitä GitHub Actionsisi commitin perusteella ja käy läpi salaisuudet, joihin työnkulkusi pääsevät käsiksi.
4. Rajoita buildiesi lähtevä liikenne niihin palvelimiin, joita ne oikeasti tarvitsevat.
5. Ota käyttöön seuranta sille, mitä olet toimittanut, ei vain sille, mitä olet buildaamassa.

Miten CRACI lähestyy asiaa

CRACI aloittaa buildista, koska buildi on ainoa paikka, joka näkee kaiken. Se korvaa GitHubin ylläpitämät runnerisi nopeammilla ja edullisemmilla runnereilla, jotka tallentavat jokaisen paketin, jonka kukin jobi hakee, riippuvuuspuun jokaisella tasolla ja myös CI-välimuisteista palautetut paketit. Egress-käytäntö estää yhteydet, joita buildisi ei tarvitse, joten se suojaa sinua jopa hyökkäykseltä, jota kukaan ei ole ennen nähnyt. Sen jälkeen CRACI tarkistaa toimitetun ohjelmiston jatkuvasti uusia haavoittuvuuksia vasten ja seuraa jokaista triagesta korjattuun julkaisuun. Katso ohjelmistotoimitusketjun tietoturva CRACI:lla.

Ohjelmistotoimitusketjun tietoturva: usein kysytyt kysymykset

Mitä on ohjelmistotoimitusketjun tietoturva?

Se tarkoittaa kaiken sen suojaamista, mitä ohjelmistoosi menee ennen kuin se päätyy käyttäjille: avoimen lähdekoodin riippuvuudet, build-järjestelmät, CI/CD-putken työkalut ja julkaisut.

Mikä on esimerkki ohjelmistotoimitusketjuun kohdistuneesta hyökkäyksestä?

SolarWinds-hyökkäyksessä buildi vaarannettiin, joten asiakkaat saivat luotetulta toimittajalta myrkytetyn päivityksen. Shai-Hulud-hyökkäyksissä mato levisi npm-pakettien kautta ja varasti tokeneita koneilta, jotka asensivat ne.

Mitä eroa on toimitusketjun tietoturvalla ja sovellusturvallisuudella?

Sovellusturvallisuus tarkastelee kirjoittamasi koodin haavoittuvuuksia. Toimitusketjun tietoturva tarkastelee sitä, mitä et ole itse kirjoittanut, ja sitä, miten ohjelmistosi buildataan ja julkaistaan. Ohjelma tarvitsee molempia.

Riittääkö SBOM toimitusketjun tietoturvaan?

Ei. SBOM kertoo, mitä toimitat, ja se on perusta. Lisäksi sinun on hallittava, mitä sisään pääsee, suojattava buildi ja seurattava jatkuvasti, mitä olet julkaissut.

Mitkä ovat tärkeimmät viitekehykset?

SLSA buildin eheyteen, NIST SSDF turvallisen kehityksen käytäntöihin ja NIST SP 800-161 toimitusketjun riskienhallintaan. EU:ssa kyberkestävyyssäädös (Cyber Resilience Act) asettaa lakisääteiset vaatimukset digitaalisia elementtejä sisältäville tuotteille.

Kuka vastaa ohjelmistotoimitusketjun tietoturvasta?

Yleensä sovellus- tai tuoteturvallisuustiimi yhdessä CI/CD-putkia ajavien alusta- ja DevOps-tiimien kanssa. Korjaukset menevät sitten kunkin palvelun omistaville kehitystiimeille.