Ohjelmiston komponenttiluettelo (SBOM) puolustukseen: mitä hankinta nyt edellyttää

Ohjelmiston komponenttiluettelo (SBOM) on koneluettava inventaario kaikista ohjelmistokomponenteista, kirjastoista ja riippuvuuksista, joista ohjelmistotuote koostuu. Se on käytännössä ohjelmiston vastine fyysiselle valmistuksen komponenttiluettelolle: jäsennelty lista kaikista lopputuotteeseen käytetyistä ainesosista, mukaan lukien jokaisen komponentin versio ja kullakin versioilla toimitusvaiheessa tunnetut haavoittuvuudet.

SBOM-vaatimukset puolustushankinnoissa eivät enää ole vasta kehittymässä — ne ovat jo olemassa. Yhdysvaltain toimeenpanomääräys EO 14028 (toukokuu 2021) edellytti SBOM:n toimittamista liittovaltiolle myytävän ohjelmiston yhteydessä. DoD:n ohjelmistomodernisointistrategia viittaa SBOM:iin toimitusketjun turvallisuusvaatimuksena. EU:n kyberresilienssilaki (CRA), joka tuli voimaan vuonna 2024, edellyttää SBOM:ia digitaalisilla elementeillä varustetuista EU:n markkinoille myytävistä tuotteista — kattaen laajan joukon puolustukseen liittyviä tuotteita. Puolustuksen ohjelmistotoimittajat, jotka eivät pysty tuottamaan vaatimustenmukaisia SBOM:ja, suljetaan hankintamahdollisuuksien ulkopuolelle.

Mitä SBOM on: koneluettava komponentti-inventaario

SBOM listaa kaikki ohjelmistotuotteeseen sisältyvät komponentit joko suoraan (kirjasto, jonka kehitystiimi lisäsi suoraan riippuvuudeksi) tai transitiivisesti (kirjasto, johon jokin näistä suorista riippuvuuksista itse puolestaan riippuu). Nykyaikaisessa standardeilla avoimen lähdekoodin komponenteilla rakennetussa sovelluksessa transitiivinen riippuvuuspuu sisältää tyypillisesti satoja tai tuhansia komponentteja — liian monia seurattavaksi manuaalisesti.

NTIA:n (National Telecommunications and Information Administration) SBOM:n vähimmäiselementit määrittelevät, mitä jokaisen komponenttimerkinnän on sisällettävä: komponentin toimittajan nimi, komponentin nimi, komponentin versio, muut yksilölliset tunnisteet (paketti-URL tai tiivistearvo), riippuvuussuhde (miten komponentti sopii laajempaan komponenttipuuhun), SBOM-tietojen tekijä ja aikaleima.

SBOM:n operatiivinen arvo on sen käyttö haavoittuvuuksien hallinnassa. Kun uusi kriittinen haavoittuvuus ilmoitetaan — Log4Shell (CVE-2021-44228) on oppikirjaesimerkki — organisaatio, jolla on SBOM:t kaikesta käyttämästään ohjelmistosta, voi välittömästi tehdä kyselyitä näihin SBOM:eihin tunnistaakseen, mitkä järjestelmät sisältävät Log4j:n ja missä versiossa, mikä priorisoi korjauksia. Organisaatio ilman SBOM:ja joutuu tutkimaan jokaisen järjestelmän manuaalisesti, mikä suuressa puolustusympäristössä voi viedä viikkoja ja jättää kriittiset järjestelmät korjaamatta väliaikaisesti.

Sääntelykehys: EO 14028, NTIA ja EU:n kyberresilienssilaki

Yhdysvaltain toimeenpanomääräys EO 14028 (kansakunnan kyberturvallisuuden parantamisesta) allekirjoitettiin toukokuussa 2021 SolarWinds-toimitusketjuhyökkäyksen jälkeen, joka osoitti, miten yksittäinen vaarantunut ohjelmistopäivitysputkisto voi vaarantaa tuhansia alavirran organisaatioita, mukaan lukien useita liittovaltion virastoja. Määräyksen 4. pykälä edellyttää nimenomaisesti, että liittovaltiolle ohjelmistoja myyvät toimittajat toimittavat SBOM:n. OMB:n ohjeet EO 14028:n täytäntöönpanosta ovat asteittain tiukentaneet SBOM-vaatimuksia liittovaltion urakoitsijoille.

NTIA:n vähimmäiselementit (julkaistu kesäkuussa 2021) tarjoavat perustason standardin sille, mikä muodostaa vaatimustenmukaisen SBOM:n. Nämä elementit ovat minimi — sopimukset voivat määritellä lisävaatimuksia, kuten tietyt SBOM-formaatit, transitiivisten riippuvuuksien sisällyttäminen määritettyyn syvyyteen tai integraatio haavoittuvuuksien neuvontajärjestelmiin.

EU:n kyberresilienssilaki koskee EU:n markkinoille saatettuja digitaalisilla elementeillä varustettuja tuotteita. "Tärkeisiin" ja "kriittisiin" kategorioihin kuuluvat tuotteet (mukaan lukien monet puolustukseen liittyvät laitteet ja ohjelmistot) edellyttävät pakollisia kolmannen osapuolen vaatimustenmukaisuusarviointeja. Vaikka CRA ei kaikissa tapauksissa nimenomaisesti vaadi SBOM:ja, sen määrittelemät kyberturvallisuuden olennaiset vaatimukset — haavoittuvuuksien käsittely, tietoturvapäivitykset, turvallisuuteen liittyvien komponenttitietojen julkistaminen — toteutetaan käytännöllisimmin SBOM:n tuottamisen ja ylläpidon kautta. EU:n puolustusohjelmat ja EU:n markkinoille myytävät tuotteet tulisi suunnitella niin, että SBOM-vaatimukset sisältyvät CRA-vaatimustenmukaisuuteen.

SBOM-formaatit: SPDX vs CycloneDX

SBOM-ekosysteemiä hallitsevat kaksi formaattia: SPDX ja CycloneDX. Molemmat ovat avoimia standardeja, molemmat ovat koneluettavia ja molemmat voivat edustaa samaa taustalla olevaa komponenttidataa. Valinta niiden välillä on ensisijaisesti työkalutuen ja käyttötapauksen painotuksen kysymys.

SPDX (Software Package Data Exchange) on ISO-standardi (ISO/IEC 5962:2021). Linux Foundation kehitti sen alun perin, ja sillä on syvimmät juuret avoimen lähdekoodin lisenssimyönteisyysyhteisössä — SPDX alkoi lisenssin seurantaformaattina ja laajennettiin kattamaan tietoturvan käyttötapaukset. SPDX:ää tukee laaja valikoima työkaluja ja sillä on vahva integraatio NTIA:n vähimmäiselementtispesifikaation kanssa. SPDX-dokumentit voidaan sarjallistaa tunniste-arvo-, JSON-, YAML- tai RDF-XML-muodossa.

CycloneDX on OWASP-standardi, joka on suunniteltu alusta alkaen erityisesti tietoturvan käyttötapauksiin. CycloneDX:llä on vahvempi tuki haavoittuvuustietojen integrointiin (VEX-dokumentit, joita käsitellään alla), se tukee muita artefaktityyppejä (palvelut, laitteisto, koneoppimismallit) ja sillä on aktiivisempi työkaluekosysteemi, joka on suunnattu erityisesti DevSecOps-työnkulkuihin. CycloneDX sarjallistetaan JSON- tai XML-muodossa.

Puolustusohjelville käytännön ohje on: molemmat formaatit ovat hyväksyttäviä nykyisen Yhdysvaltain SBOM-ohjeistuksen mukaan; tarkista sopimuksesta ja ohjelma-asiakirjoista erityiset formaattivaatimukset; tuota molemmat, jos työkalutuki sen sallii (Syft, jota käsitellään alla, tuottaa molemmat); ja varmista, että SBOM-hallinta-alustasi pystyy käyttämään tuottamaasi formaattia.

SBOM:n tuottaminen CI/CD-ympäristössä: Syft ja cdxgen

Syft (Anchore) on johtava avoimen lähdekoodin SBOM-tuotantotyökalu konttikuville ja tiedostojärjestelmille. Se tukee sekä SPDX- että CycloneDX-tulostusformaatteja ja käsittelee laajaa valikoimaa pakettiympäristöjä: npm, PyPI, Maven/Gradle, NuGet, Go-moduulit, RubyGems, Cargo, Alpine APK, Debian/Ubuntu DPKG ja RPM. CI/CD-putkistossa Syft suoritetaan build-vaiheen askeleena sen jälkeen, kun konttikuva on rakennettu mutta ennen kuin se työnnetään rekisteriin, tuottaen SBOM:n, joka julkaistaan build-artefaktina kuvan rinnalla.

cdxgen on OWASP:n ylläpitämä CycloneDX-tuotantotyökalu, jolla on erityisen vahva tuki polyglot-repositorioille (useilla ohjelmointikielillä kirjoitettua koodia sisältäville repositorioille). cdxgen läpikäy useiden pakettihallintatyökalujen riippuvuusmanifestit samanaikaisesti ja tuottaa yhtenäisen CycloneDX SBOM:n, joka kattaa kaikki komponentit kaikista kielijärjestelmistä repositoriossa. Tämä on erityisen tärkeää puolustuksen ohjelmistoprojekteille, jotka yhdistävät esimerkiksi Python-taustajärjestelmän TypeScript-käyttöliittymään ja Java-välikerrossovellukseen.

VEX: haavoittuvuuden hyödynnettävyysvaihto

SBOM kertoo, mitkä komponentit ovat läsnä. VEX (Vulnerability Exploitability eXchange) -dokumentti kertoo, ovatko kyseisten komponenttien haavoittuvuudet tosiasiassa hyödynnettävissä kyseisessä tuoteympäristössä. Ero on tärkeä, koska ohjelmistokoostumuksen analyysi tuottaa tyypillisesti pitkiä luetteloita transitiivisissa riippuvuuksissa olevista CVE-haavoittuvuuksista, jotka eivät tosiasiassa ole hyödynnettävissä: haavoittuva koodipolku ei ole sovelluksessa tavoitettavissa, haavoittuvaa komponenttia käytetään vain testausympäristössä tai haavoittuvuuden mahdollistava konfiguraatio ei ole käytössä käyttöönotetussa tuotteessa.

VEX-tilat jokaiselle CVE-komponenttiparille ovat: "affected" (haavoittuvuus on läsnä ja hyödynnettävissä), "not affected" (haavoittuvuus on komponentissa mutta ei ole hyödynnettävissä tässä tuotteessa), "fixed" (korjattu versio on saatavilla ja käyttöönotettu) tai "under investigation" (hyödynnettävyyttä ei ole vielä määritetty). Puolustuksen hankintasopimukset edellyttävät yhä useammin sekä SBOM:ia että VEX-dokumenttia täydellisenä toimitusketjun turvallisuuden toimituskokonaisuutena. CISA on julkaissut ohjeistuksen VEX-formaateista ja vähimmäissisällöstä.