Mikä on ohjelmistoluettelo (SBOM)?

Ohjelmistoluettelo (SBOM) on yksityiskohtainen, kattava luettelo kaikista ohjelmistosovelluksen komponenteista, mukaan lukien avoimen lähdekoodin ohjelmistojen käyttö, komponenttiriippuvuudet, lisenssit ja tunnetut haavoittuvuudet. SBOM:t tarjoavat luettelon jokaisesta yksittäisestä komponentista, joka sisältää sovelluksen, aivan kuten reseptin ainesosaluettelo. SBOM:t alkoivat saada jalansijaa vuonna 2018 tietoturvayhteisön yhteistyönä, ja niitä ovat viime vuosina suurelta osin ajaneet National Telecommunications and Information Administration (NTIA) ja Yhdysvaltain hallitus.

SBOM:t ovat erittäin tärkeitä asiakirjoja, jotka tarjoavat kriittistä tietoa organisaatioille, jotka haluavat minimoida ja vähentää toiminnallisia, oikeudellisia ja ohjelmistojen toimitusketjuun liittyviä riskejä, mutta monilla organisaatioilla on edelleen haasteita SBOM:ien käyttöönotossa olemassa olevissa prosesseissaan tai ne eivät ole tietoisia niiden eduista. Tässä artikkelissa tarkastellaan, miten SBOM:t voivat auttaa organisaatioita saamaan parempaa tietoa käyttämistään ohjelmistoista ja miksi SBOM:t tulisi ottaa käyttöön parhaana käytäntönä.

Lue, miten UpGuard auttaa yrityksiä saamaan paremman näkyvyyden ohjelmistohaavoittuvuuksiinsa >

Miksi SBOM:t ovat tärkeitä?

Koska keskimääräinen yritys käyttää yli 130 SaaS-sovellusta päivittäisessä toiminnassaan ja suuremmat yritykset voivat käyttää yli 200 sovellusta päivittäin, SBOM:ista tulee entistä tärkeämpiä tietoturvariskien vähentämisessä. Mitä enemmän sovelluksia organisaatio käyttää päivittäin, sitä enemmän organisaatio altistuu riskeille. Jos yksittäinen sovellus tai komponentti murtautuisi haavoittuvuuden vuoksi, se voisi vaarantaa koko ohjelmiston toimitusketjun.

SBOM:t auttavat organisaatioita tunnistamaan tiettyihin ohjelmistoihin liittyviä toiminta- ja tietoturvariskejä sekä saamaan lisää näkyvyyttä ohjelmistokoostumuksiin. Organisaatiot voivat paremmin hallita haavoittuvuuksia, noudattaa lisenssejä ja suorittaa muita tärkeitä ohjelmistonhallintatehtäviä tietämällä tarkalleen, mitä ohjelmistotuotteen sisällä on. SBOM:ista on tulossa yhä tärkeämpi työkalu kyberturvallisuuden, ohjelmistokehityksen elinkaaren (SDLC) ja DevSecOps-prosessien maailmassa.

Toukokuussa 2021 Yhdysvaltain liittovaltion hallitus antoi toimeenpanomääräyksen 14028, joka edellyttää, että kaikki Yhdysvaltain valtion virastot ovat tekemisissä vain SBOM:ia tarjoavien ohjelmistotoimittajien kanssa. Tämä uusi laki oli osa laajempaa kyberturvallisuuspyrkimystä turvata maan digitaalinen infrastruktuuri ja saada useammat ohjelmistotoimittajat varmistamaan, että tuotteet rakennetaan turvallisesti. EO 14028 kannustaa myös toimittajia täyttämään liittovaltion kyberturvallisuusstandardit, koska valtion sopimukset ovat mahdollisesti tuottoisia mahdollisuuksia.

Nykyaikaiset ohjelmistosovellukset ja -palvelut rakennetaan erilaisista komponenteista ja riippuvuuksista useista lähteistä. Näitä komponentteja ja riippuvuuksia voivat olla avoimen lähdekoodin ohjelmistot, oma koodi, mukautetut ohjelmointirajapinnat, ohjelmointikielikehykset ja ohjelmistokirjastot. Ohjelmistosovellusten muodostavien lähteiden kokonaisuuden katsotaan olevan osa ohjelmistojen toimitusketjua.

Ohjelmistoluettelo eroaa ohjelmiston metatiedoista siinä, että ohjelmiston metatiedot voivat tarjota enemmän tietoa sovelluksen laajemmasta käytöstä ja tarkoituksesta, kun taas SBOM:t keskittyvät sovelluksen yksittäisiin komponentteihin ja niiden riippuvuuksiin.

Organisaatiot luottavat SBOM-järjestelmiinsä myös seuraavien asioiden korjaamiseksi:

Lakien noudattaminen
Kyberturvallisuuden suorituskyky
Riskinhallinta
Tapausten käsittely
Toiminnan tehokkuus
Haavoittuvuuksien hallinta

Mitä SBOM:t sisältävät?

National Telecommunications and Information Administration (NTIA) julkaisi ohjeet, joissa kerrotaan yksityiskohtaisesti SBOM:n vähimmäiselementit, mukaan lukien seuraavat perusalueet:

Komponenttien nimet ja versiot: Jokainen ohjelmistokomponentti on tunnistettava ja lueteltava, mukaan lukien sen nimi, versionumero, lisenssitiedot, toimittajan nimi, tekijä ja aikaleima, milloin SBOM-tiedot luotiin. Näiden tietojen avulla organisaatiot voivat varmistaa, että ne käyttävät kunkin komponentin uusimpia ja turvallisimpia versioita. Jos komponentti tai alikomponentti päivitetään, SBOM on päivitettävä ja julkaistava uudelleen.
Ohjelmistoriippuvuudet: SBOM:n on sisällettävä ohjelmistokomponenttien välinen riippuvuuspuu, mukaan lukien transitiiviset riippuvuudet, ohjelmiston toiminnallisuuden ylläpitämiseksi ja tehokkaiden riippuvuuksien hallintakäytäntöjen tukemiseksi. Jos riippuvuus muuttuu tai komponentti vanhenee, SBOM on päivitettävä vastaamaan tällaisia muutoksia.
Automaatio: NTIA suosittelee SBOM-tuotannon ja tiedonsiirron automaation vähimmäistasoja, jotta muut järjestelmät voivat ymmärtää ja käyttää luotuja SBOM-tietoja. Koska ohjelmistosovellukset voivat olla erittäin monimutkaisia, NTIA suosittelee vahvasti olemaan luomatta SBOM:ää manuaalisilla prosesseilla.
Prosessit: SBOM:t edellyttävät jatkuvia tiedonkeruuprosesseja, jotka määrittävät, miten SBOM:t luodaan, miten niitä käytetään ja kenellä on oikeus käyttää niitä.
Avoimen lähdekoodin ohjelmistolisenssit: Jos ohjelmisto käyttää avoimen lähdekoodin ohjelmistolisenssejä, on tärkeää dokumentoida kunkin komponentin lisenssityyppi sekä käyttöehdot oikeudellisten ongelmien välttämiseksi. Organisaatiot voivat varmistaa, että ne noudattavat komponentin luojien asettamia ehtoja seuraamalla kaikkia lisenssejä. Lisäksi lisensointitietojen avulla organisaatiot voivat seurata avoimen lähdekoodin haavoittuvuuksia tai hyväksikäyttöjä ja korjata ne ennen kuin ne voivat johtaa kybermurtoon.
Tunnetut haavoittuvuudet: Kunkin komponentin tunnettujen tietoturva-aukkojen luettelo auttaa organisaatioita vähentämään mahdollisia riskejä ja parantamaan ohjelmistojensa yleistä turvallisuutta. Näiden tietojen avulla IT-tiimit voivat priorisoida päivitykset ja korjaukset turvallisen ohjelmistoympäristön ylläpitämiseksi.

Vakiomuotoiset SBOM-muodot

SBOM:ien luomiseen ja jakamiseen on olemassa muutamia vakiomuotoja. Standardoidut muodot tarjoavat johdonmukaisuuden SBOM-tiedoille koko ohjelmiston toimitusketjussa, mikä edistää täyttä läpinäkyvyyttä ja yhteistyötä eri sidosryhmien välillä. Nykyään yleisimmin käytettyjä SBOM-muotoja ovat:

CycloneDX, jonka on kehittänyt Open Web Application Security Project (OWASP)
Ohjelmiston tunnistetunnisteet (SWID), NIST:n kehittämä

Ohjelmistopaketin tiedonvaihto (SPDX), jonka ISO/IEC on kehittänyt ISO/IEC 5962 -standardin mukaisesti

SBOM:ien käyttöönoton edut

SBOM:ien käyttöönotto voi olla vaikea prosessi, mutta se voi tarjota monia etuja, jotka voivat auttaa organisaatioita ylläpitämään tietoturvaansa paremmin ja minimoimaan riskejä pitkällä aikavälillä, mukaan lukien:

Parannetut suojausasennot: SBOM:t tarjoavat lisää syvyyttä ja näkyvyyttä ohjelmistokomponentteihin, mikä auttaa organisaatioita tunnistamaan, seuraamaan ja korjaamaan tunnettuja haavoittuvuuksia.
Lisensoinnin vaatimustenmukaisuus: SBOM:t auttavat organisaatioita täyttämään lisenssivaatimukset pitämällä kirjaa kaikista käytössä olevista patentoiduista ja avoimen lähdekoodin komponenteista. Nämä käyttöoikeustiedot auttavat myös organisaatioita täyttämään lakisääteiset vaatimukset ja säädösstandardit.
Toimitusketjun läpinäkyvyys: Ohjelmistojen läpinäkyvyyden lisääminen on erityisen tärkeää organisaatioille, kun ne alkavat skaalautua. Kunkin ohjelmistotuotteen lähteen ymmärtäminen antaa organisaatioille mahdollisuuden arvioida oikein kunkin komponentin luotettavuutta ja turvallisuutta.
Tehokkaat ohjelmistoauditoinnit: Ohjelmistotarkastuksia tulee suorittaa säännöllisesti tuotteen vaatimustenmukaisuuden, tehokkuuden, kriittisyyden ja tarpeellisuuden arvioimiseksi. SBOM:t auttavat helpottamaan tätä prosessia tarjoamalla kattavan luettelon jokaisesta käytetystä komponentista, mikä säästää aikaa ja resursseja, joita tarvitaan auditoinnin suorittamiseen.
Tehokas riskien ja haavoittuvuuksien hallinta: Jokaisen ohjelmistosovelluksissa käytetyn komponentin seurannan avulla yritykset voivat tunnistaa mahdolliset riskit ja lieventää tai korjata niitä ennen kuin niitä voidaan hyödyntää.

SBOM:ien käyttöönoton haasteet

Vaikka SBOM:t voivat auttaa yrityksen IT-ekosysteemiä pysymään järjestyksessä, monia prosesseja standardoidaan ja määritellään edelleen. Koska SBOM:ien luomisessa ja käytössä on edelleen vaihtelua, organisaatiot voivat kohdata joitain alkuvaiheen haasteita ja tehottomuutta, kuten:

Monimutkaiset toteutus- ja ylläpitoprosessit: Suuremmilla yrityksillä, jotka käyttävät laajaa valikoimaa ja määrää ohjelmistotuotteita ja koodikantoja, voi olla merkittäviä haasteita SBOM:ien hankkimisessa kullekin sovellukselle. Ohjelmistotoimittajien tehtävänä on puolestaan myös tehdä lisätyötä SBOM:ien luomisessa, varsinkin kun ohjelmistoa päivitetään. Usein päivitettävät ohjelmistotuotteet tarkoittavat, että myös SBOM:t on päivitettävä usein.
Standardoinnin puute: Koska SBOM:t ovat vielä suhteellisen uusi käytäntö, standardointiongelmia on edelleen, mikä voi johtaa epäjohdonmukaisuuksiin muotojen välillä ja yhteensopivuusongelmiin tiedontuotannossa käytettyjen työkalujen ja alustojen välillä.
Erittäin resurssiintensiivinen: SBOM:ien luomiseen ja ylläpitoon vaadittava suuri työmäärä tarkoittaa, että toimittajien on käytettävä tehtävään paljon aikaa ja resursseja. Lisäksi kussakin tietoturvatiimissä on koulutettava erikoishenkilöstöä, mikä voi olla haaste pienemmille organisaatioille, joilla on korkeammat prioriteetit. Ohjelmistoa käyttävät organisaatiot tarvitsevat myös omistettuja tiimejä tai henkilöitä jäljittämään SBOM:t, jotta ne voidaan sisällyttää hankinta- ja auditointiprosesseihin.
SBOM-tietoturva: Jokainen SBOM-dokumentti sisältää kriittistä tietoa ohjelmistokomponenteista, mikä voi johtaa uusiin tietomurtomahdollisuuksiin sekä sovellusta käyttävälle toimittajalle että organisaatiolle. SBOM-tiedot on pidettävä luottamuksellisina ja turvassa, ja uudet sisäiset tietoturvaprosessit määrittävät sen tietoturvan.
Integrointiominaisuuksien puute: Koska SBOM:t eivät ole vieläkään yleinen käytäntö, sen prosessien integrointi olemassa olevaan ohjelmistokehitykseen ja käyttöönottoon ei välttämättä ole mahdollista tai voi olla erittäin haastavaa. Ohjelmistojen integrointiominaisuuksia voidaan kuitenkin lisätä, kun yhä useammat organisaatiot ottavat SBOM:t käyttöön prosesseissaan.
Toimittajien osallistuminen: Koska organisaatiot voivat työskennellä satojen tai tuhansien ohjelmistosovelluksia toimittavien toimittajien kanssa, kolmannen osapuolen palveluntarjoajien saaminen ottamaan käyttöön uusia prosesseja ja tuottamaan päivitettyjä, tarkkoja SBOM-malleja voi osoittautua vaikeaksi, varsinkin jos he eivät näe etuja tai kokevat, että ylimääräinen työ on tarpeetonta. Lisäksi ohjelmistotoimittajat eivät ehkä halua antaa komponenttitietoja, jos he kokevat paljastavansa luottamuksellisia, omistusoikeudellisia tietoja.