SBOMit ISO 27001-, NIS2- ja DORA-varmennuksessa

On perjantai kello 07.42, kun nopeasti kasvavan FinTech-yhtiön tietoturvajohtaja Amelia saa hälytyksen, jota yksikään tietoturvajohtaja ei halua nähdä.

Laajasti käytetyssä avoimen lähdekoodin paketissa on kriittinen etäkoodin suorittamisen haavoittuvuus. Ohjelmistokoostumusanalyysin työkalu kertoo, että komponentti saattaa olla todennuspalvelussa, mahdollisesti laskutuksessa ja ehkä myös maksutyönkulun käyttämässä kolmannen osapuolen API-kääreessä. Kehitystiimi tarvitsee aikaa varmistamiseen. Lakiasiat kysyy, onko NIS2-ilmoitusten määräaika alkanut kulua. DORA-ohjelmapäällikkö kysyy, tukeeko vaikutuksen kohteena oleva palvelu finanssialan toimijan kriittistä tai tärkeää toimintoa. Myynti kysyy, estääkö tämä sopimuksen uusimisen. Hallitus esittää yksinkertaisimman ja vaikeimman kysymyksen: ”Olemmeko alttiina?”

Ilman ohjelmiston materiaaliluetteloa rehellinen vastaus on usein: ”Emme vielä tiedä.”

Vuonna 2026 tällainen vastaus ei ole vain tekninen puute. Se on hallinnointiheikkous, sopimusriski, auditointialtistus ja säännellyille toimijoille häiriönsietokyvyn ongelma. SBOMit ovat siirtyneet DevSecOps-hygieniasta hallitustason näytöksi ohjelmistojen toimitusketjun varmentamisessa, ISO/IEC 27001:2022 -hallintakeinojen toimivuudessa, NIS2:n kyberturvallisuusriskien hallinnassa, DORA:n ICT-kolmansien osapuolten hallinnassa, GDPR:n osoitusvelvollisuudessa ja asiakkaiden toimittajahuolellisuusarvioinneissa.

Ratkaisevaa ei ole pelkkä SBOM-tiedoston tuottaminen. Ratkaisevaa on osoittaa, että ohjelmistokomponentit tunnistetaan, hyväksytään, niitä seurataan, ne riskiluokitellaan, korjataan, niitä hallitaan sopimuksellisesti ja ne ovat jäljitettävissä vastuullisiin omistajiin. Tässä Clarysecin politiikkakirjasto, Zenith Blueprint: auditoijan 30 vaiheen tiekartta ja Zenith Controls: vaatimustenmukaisuuden poikkikartoituksen opas muuttavat kehittäjän artefaktin puolustettavaksi vaatimustenmukaisuusnäytöksi.

Miksi SBOMit ovat nyt näyttöä ohjelmistojen toimitusketjun varmentamisesta

SBOM on ohjelmistokomponenttien inventaario, joka sisältää avoimen lähdekoodin paketit, kaupalliset kirjastot, versiot, lähteet, lisenssit ja riippuvuussuhteet. Hyödyllinen SBOM auttaa vastaamaan neljään kysymykseen, joista viranomaiset, asiakkaat ja hallitukset ovat nykyisin kiinnostuneita:

1. Mitä ohjelmistomme sisältää?
2. Mihin se on otettu käyttöön?
3. Onko se haavoittuva, tukematon, lisensoimaton tai hyväksymätön?
4. Kuka omistaa korjaavat toimenpiteet, lieventämisen tai riskin hyväksymisen?

Nämä kysymykset kytkeytyvät suoraan nykyaikaisiin oikeudellisiin ja sääntelyyn perustuviin odotuksiin.

NIS2 koskee monia keskisuuria ja suuria toimijoita keskeisillä ja tärkeillä toimialoilla, kuten digitaalista infrastruktuuria, pilvipalveluntarjoajia, datakeskuspalvelujen tarjoajia, hallinnoitujen palvelujen tarjoajia (MSP), hallinnoitujen tietoturvapalvelujen tarjoajia, verkkomarkkinapaikkoja, hakukoneita, sosiaalisen verkostoitumisen alustoja ja tiettyjä digitaalisia palveluntarjoajia. Sitä voidaan soveltaa myös kansallisen nimeämisen ja toimialakohtaisen täytäntöönpanon perusteella. Soveltamisalaan kuuluvilta toimijoilta NIS2 edellyttää, että johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niiden toteutusta. Article 21 sisältää toimitusketjun turvallisuuden, turvallisen hankinnan, turvallisen kehittämisen ja ylläpidon, haavoittuvuuksien käsittelyn ja julkistamisen, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, omaisuudenhallinnan, pääsynhallinnan, kryptografian, vaikuttavuuden arvioinnin ja kyberhygienian.

DORA, jota sovelletaan 17. tammikuuta 2025 alkaen, luo finanssialan toimijoille yhtenäisen EU:n digitaalisen operatiivisen häiriönsietokyvyn viitekehyksen. Se kattaa ICT-riskien hallinnan, ICT:hen liittyvien poikkeamien raportoinnin, häiriönsietokyvyn testauksen, ICT-kolmansien osapuolten riskienhallinnan, sopimusjärjestelyt sekä kriittisten ICT-kolmannen osapuolen palveluntarjoajien valvonnan. DORA odottaa finanssialan toimijoiden tunnistavan ICT-omaisuuserät, ICT:n tukemat liiketoimintatoiminnot, riippuvuudet, yhteydet, haavoittuvuudet, riskiskenaariot, muutokset ja kolmansien osapuolten tukemat prosessit.

GDPR lisää tietosuojakerroksen. Jos haavoittuva komponentti vaikuttaa henkilötietoja käsitteleviin järjestelmiin, kysymykseksi tulee, onko henkilötietoihin voitu päästä käsiksi, onko niitä voitu muuttaa, kadottaa, luovuttaa tai muuten vaarantaa. Rekisterinpitäjät ja käsittelijät tarvitsevat näyttöä siitä, että ne pystyvät tunnistamaan vaikutuksen kohteena olevat järjestelmät, tietovirrat, alikäsittelijät ja loukkauksen vaikutukset.

NIST CSF 2.0 vahvistaa saman toimintamallin toimintojen GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER kautta. Sen toimitusketjuun liittyvät tulokset edellyttävät toimittajavastuita, kriittisyyttä, sopimusvaatimuksia, huolellisuutta, seurantaa, poikkeamasuunnittelua ja suhteen päättämistä koskevia ehtoja.

Kun Amelian hallitus kysyy, onko FinTech-yhtiö alttiina, SBOMeja hyödyntävä organisaatio voi vastata näytöllä:

• Mitkä tuotteet ja julkaisut sisältävät haavoittuvan komponentin
• Mitkä käyttöönotetut ympäristöt ovat vaikutuksen kohteena
• Mitkä asiakkaat, alueet, toiminnot ja tietovirrat liittyvät siihen
• Mikä toimittaja tai sisäinen omistaja on vastuussa
• Mitkä korvaavat kontrollit ovat aktiivisia
• Voivatko NIS2-, DORA-, GDPR- tai sopimuskynnykset täyttyä
• Mikä korjaus, lieventäminen, poikkeus tai riskin hyväksyminen on hyväksytty

Tämä erottaa komponenttiluettelon kontrollijärjestelmästä.

ISO 27001:2022 on SBOM-hallinnoinnin selkäranka

ISO/IEC 27001:2022 on vahva perusta SBOM-hallinnoinnille, koska se on hallintajärjestelmästandardi eikä pelkkä tekninen tarkistuslista. Sen kohdat edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmät, soveltamisalan, johdon sitoutumisen, politiikan, roolit, riskien arvioinnin, riskien käsittelyn, tavoitteet, suorituskyvyn arvioinnin, sisäisen auditoinnin, johdon katselmoinnin ja jatkuvan parantamisen.

SBOM-ohjelmat epäonnistuvat, kun ne jäävät ISMS:n ulkopuolelle. Kehitystiimi voi tuottaa tiedostoja, mutta kukaan ei valvo haavoittuvuuksien korjaamisen palvelutasosopimuksia, toimittajavelvoitteita, näytön säilyttämistä, riskin hyväksymistä tai asiakkaille tehtäviä ilmoituksia. ISO 27001 korjaa tämän tekemällä SBOMeista osan organisaation riskienhallintajärjestelmää.

Kohtien 4.1–4.4 mukaan organisaatio määrittää sisäiset ja ulkoiset kysymykset, sidosryhmien vaatimukset, lakisääteiset ja sääntelyvelvoitteet, sopimusperusteiset odotukset ja ISMS:n soveltamisalan. SBOM-varmennuksen soveltamisalan tulee nimenomaisesti sisältää:

• Asiakkaille toimitettavat tuotteet ja palvelut
• Pilvi- ja SaaS-tuotantoympäristöt
• CI/CD-putket, lähdekoodirepositoriot ja artefaktirekisterit
• Avoimen lähdekoodin ja kaupalliset ohjelmistokomponentit
• Ulkoistetun kehittämisen ja integraation kumppanit
• ICT-kolmannen osapuolen palveluntarjoajat ja alihankkijat
• Asiakkaiden tietoturvavaatimukset DORA:n, NIS2:n, GDPR:n ja sopimusten perusteella

Kohdat 5.1–5.3 tekevät ohjelmistojen toimitusketjuriskistä johdon asian. Johdon tulee sovittaa tietoturvatavoitteet liiketoiminnan suuntaan, osoittaa resurssit, määrittää vastuut ja viestiä politiikasta. Kohdat 6.1.2 ja 6.1.3 muuttavat SBOM-havainnot riskien arvioinnin ja riskien käsittelyn näytöksi. Kriittinen haavoittuva komponentti internetiin avautuvassa todennuspalvelussa ei ole vain tiketti. Se on riskiskenaario, joka vaikuttaa luottamuksellisuuteen, eheyteen, saatavuuteen, sopimussitoumuksiin, sääntelyraportointiin ja operatiiviseen häiriönsietokykyyn.

SBOM-varmennuksen kannalta olennaisimmat ISO/IEC 27001:2022 liite A:n hallintakeinot ovat:

Clarysec kartoittaa nämä suhteet ISO/IEC 27002:2022 -attribuuttien kautta Zenith Controls -ratkaisussa. Esimerkiksi Zenith Controls käsittelee ISO/IEC 27002:2022 -hallintakeinoa 5.21, ”Tietoturvallisuuden hallinta ICT-toimitusketjussa”, ennaltaehkäisevänä, luottamuksellisuutta, eheyttä ja saatavuutta suojaavana, Identify-kyberturvallisuuskäsitteeseen kohdistuvana sekä hallinnoinnin, ekosysteemin ja suojauksen osa-alueilla toimivana kontrollina. Se käsittelee hallintakeinoa 8.25, ”Turvallisen kehittämisen elinkaari”, ennaltaehkäisevänä ja Protect-toimintoon kohdistuvana. Se käsittelee hallintakeinoa 8.8, ”Teknisten haavoittuvuuksien hallinta”, ennaltaehkäisevänä sekä Identify- ja Protect-toimintoihin kohdistuvana ja yhdistää haavoittuvuuksien hallinnan hallinnointiin, ekosysteemiin, suojaukseen ja puolustukseen.

Tällä käännöksellä on merkitystä, koska eri arvioijat kysyvät eri kysymyksiä. ISO-auditoija voi kysyä, sisältyykö komponenttiriski soveltuvuuslausuntoon. DORA-arvioija voi kysyä, tukeeko komponentti kriittistä tai tärkeää toimintoa. Asiakas voi kysyä, ylittävätkö ratkaisemattomat haavoittuvuudet sopimuksen palvelutasosopimukset. Sama SBOM-näyttö voi tukea kaikkia kolmea, jos sitä hallinnoidaan oikein.

Clarysecin politiikkakerros auditointivalmiille SBOMeille

Luotettava SBOM-ohjelma tarvitsee politiikkatekstin. Kehittäjien tulee tietää, mitä on kirjattava. Hankinnan tulee tietää, mitä toimittajien tulee toimittaa. Tietoturvan tulee tietää, mitkä havainnot käynnistävät eskaloinnin. Vaatimustenmukaisuustoiminnon tulee tietää, mikä näyttö on säilytettävä.

Pienemmille organisaatioille Turvallisen kehityksen politiikka - pk-yritys luo vähimmäiskelpoisen SBOM-kontrollin:

Toimitusjohtajan tai nimetyn kehittäjän tulee ylläpitää luetteloa kaikista käytetyistä ulkoisista komponenteista, mukaan lukien: 6.6.2.1 Versio ja lähde 6.6.2.2 Tunnetut haavoittuvuudet tai korjauspäivitysten tila 6.6.2.3 Viimeisin päivitys- tai katselmointipäivä

Vaatimus on yksinkertainen mutta vaikuttava. Se luo näkyvyyden versioihin, lähteiden jäljitettävyyden, haavoittuvuuksien tilan ja katselmointirytmin.

Sovellusturvallisuusvaatimusten politiikka - pk-yritys lisää elinkaarikatselmoinnin:

Kaikki sovelluksessa käytettävät kolmannen osapuolen työkalut, lisäosat tai ulkoiset koodikirjastot on kirjattava ja katselmoitava vuosittain tietoturvavaikutuksen ja korjauspäivitysten tilan osalta.

Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys yhdistää SBOMit korjaaviin toimenpiteisiin:

Kehittäjien tulee seurata ja päivittää kolmannen osapuolen kirjastoja, esimerkiksi avoimen lähdekoodin paketteja

Yritysympäristöissä Turvallisen kehityksen politiikka nostaa vaatimustasoa:

Avoimen lähdekoodin tai kolmannen osapuolen koodin käyttö on hyväksyttävä, seurattava ja validoitava seuraavien kautta:

Se tekee myös skannauksesta pakollista:

Kaikki kolmannen osapuolen komponentit on skannattava haavoittuvuuksien varalta ennen käyttöönottoa ja ajon aikana automatisoiduilla työkaluilla.

Ulkoistetun kehittämisen tulee noudattaa samaa standardia. Ulkoistetun kehittämisen politiikka edellyttää:

Avoimen lähdekoodin kirjastojen turvallinen käyttö haavoittuvuusskannauksen ja hyväksynnän alaisena

Toimittajasopimukset tarvitsevat täytäntöönpanokelpoiset näyttöoikeudet. Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys edellyttää sopimuslausekkeita, jotka kattavat luottamuksellisuuden, tietoturvavelvoitteet, loukkauksista ilmoittamisen määräajat, auditointioikeudet, alihankintarajoitukset ja turvallisen päättämisen:

Sopimusten tulee sisältää pakolliset lausekkeet, jotka kattavat: 5.3.1 Luottamuksellisuus ja salassapito 5.3.2 Tietoturvavelvoitteet 5.3.3 Henkilötietojen tietoturvaloukkausten ilmoitusmääräajat, esimerkiksi 24–72 tunnin kuluessa 5.3.4 Auditointioikeudet tai vaatimustenmukaisuusnäytön saatavuus 5.3.5 Rajoitukset jatkoalihankinnalle ilman hyväksyntää 5.3.6 Päättämisehdot, mukaan lukien tietojen turvallinen palautus tai hävittäminen

Yritysasiakkaille Kolmansien osapuolten ja toimittajien tietoturvapolitiikka sisältää:

Oikeudet auditoida, tarkastaa ja pyytää tietoturvanäyttöä

Jos SaaS-palveluntarjoaja, ulkoistetun kehittämisen kumppani tai kaupallinen ohjelmistotoimittaja ei toimita tietoturvanäyttöä, haavoittuvuuden tilaa, ilmoitussitoumuksia tai auditointipääsyä, ohjelmistojen toimitusketjun varmentamiseen jää sokea piste.

Toimittajariippuvuuksien riskienhallintapolitiikka muuttaa riippuvuuksien keskittymät mitattavaksi häiriönsietokyvyn riskiksi:

Toimittajariippuvuusrekisteri: toimittajahallintatoiminnon (VMO) tulee ylläpitää ajantasaista rekisteriä kaikista kriittisistä toimittajista, mukaan lukien tiedot, kuten toimitetut palvelut tai tuotteet; onko toimittaja ainoa lähde; käytettävissä olevat vaihtoehtoiset toimittajat tai korvattavuus; nykyiset sopimusehdot; sekä arvio vaikutuksesta, jos toimittaja epäonnistuu tai vaarantuu. Rekisterin tulee selkeästi tunnistaa suuren riippuvuuden toimittajat, esimerkiksi ne, joille ei ole nopeasti käyttöönotettavaa vaihtoehtoa.

Tämä rekisteri tulee yhdistää SBOMeihin. Jos kriittinen kirjasto tulee yhden lähteen toimittajalta, tukee säänneltyä asiakastyönkulkua eikä sille ole nopeaa korvaajaa, se ei ole pelkkä paketti. Se on häiriönsietokyvyn riippuvuus.

SBOM-tiedostosta operatiiviseksi kontrolliksi yhdessä sprintissä

Käytännöllinen SBOM-ohjelma kannattaa aloittaa yhdestä tuotelinjasta ja yhdestä tuotantoympäristöstä. Koko organisaatiota ei tule yrittää inventoida ensimmäisenä päivänä. Jos Amelian FinTech aloittaa asiakkaiden perehdytys- ja maksutyönkulusta, tiimi voi luoda toistettavan näyttömallin ennen laajentamista.

Vaihe 1: Määritä SBOM-soveltamisala ISMS:n sisällä

Laadi soveltamisalakuvaus, joka on kytketty ISMS:n soveltamisalaan ja sääntelyajureihin:

• Tuote: asiakkaiden perehdytys- ja maksu-SaaS-alusta
• Ympäristö: EU-tuotanto
• Tietovarastot: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Koontijärjestelmät: Git-palveluntarjoaja, CI/CD-alusta, konttirekisteri
• Käyttöönotto: Kubernetes-klusteri, hallittu tietokanta, objektitallennus
• Data: tilitiedot, todennuslokit, laskutuksen metatiedot, maksuviitteet
• Asiakkaat: EU:n finanssialan toimijat ja kaupalliset asiakkaat
• Sääntelyajurit: ISO 27001:2022, NIS2-asiakasvarmennus, DORA ICT-kolmansia osapuolia koskeva huolellisuusarviointi, GDPR:n tietoturvan osoitusvelvollisuus

Tämä on linjassa ISO 27001:n kohdan 4 soveltamisalalogiikan ja NIST CSF Profile -rajauksen kanssa.

Vaihe 2: Tuota ja säilytä SBOMit koontivaiheessa

Määritä CI/CD-putket tuottamaan SBOM jokaiselle koontiartefaktille, mukaan lukien konttikuvat. CycloneDX:n ja SPDX:n kaltaisia vakioformaatteja käytetään yleisesti. Säilytä jokainen SBOM hallitussa näyttötietovarastossa, joka on kytketty koontitunnisteeseen, commit-hajautusarvoon, käyttöönoton tallenteeseen ja julkaisuversionumeroon.

Tämä tukee suoraan Turvallisen kehityksen politiikka - pk-yritys -vaatimusta ylläpitää tietoa versiosta, lähteestä, tunnetusta haavoittuvuudesta tai korjauspäivitysten tilasta ja katselmointipäivästä.

Vaihe 3: Rikasta SBOM-tiedot hyväksikäytettävyydellä ja liiketoimintakontekstilla

Älä pysähdy pakettiluetteloon. Lisää operatiivinen riskikonteksti:

• Onko komponentti haavoittuva?
• Onko haavoittuva toiminto saavutettavissa?
• Onko palvelu internetiin avautuva?
• Käsitteleekö palvelu henkilötietoja?
• Tukeeko se DORA-asiakkaan kriittistä tai tärkeää toimintoa?
• Onko korjauspäivitys saatavilla?
• Onko käytössä korvaava kontrolli?
• Onko riskinomistaja hyväksynyt riskin hyväksymisen?

Kriittinen CVE vain testikäytössä olevassa paketissa on eri asia kuin kriittinen CVE tuotannon todennuspalvelussa. ISO 27001:n riskien arviointia ja käsittelyä koskevat kohdat auttavat tekemään erottelusta puolustettavan.

Vaihe 4: Kytke SBOMit toimittaja- ja ulkoistetun kehittämisen kontrolleihin

Jos komponentin toimittaa kaupallinen toimittaja tai ulkoistetun kehittämisen kumppani, päivitä toimittajatiedot:

Tämä tukee NIS2 Article 21:n toimitusketjun turvallisuutta sekä DORA Article 28:n odotuksia ICT-kolmansien osapuolten riskistrategiasta, huolellisuudesta, sopimusperusteisista suojatoimista, tietorekistereistä, auditointisuunnittelusta, päättämisoikeuksista ja irtautumisstrategioista.

Vaihe 5: Määritä korjaussäännöt ja näyttö

Sido korjaamisen palvelutasosopimukset liiketoimintavaikutukseen, ei pelkästään CVSS-pisteisiin.

Tässä SBOMeista tulee hyödyllisiä NIS2-, DORA- ja GDPR-vaatimuksille. Korjaustyönkulussa tulee huomioida merkittävän poikkeaman mahdollisuus, merkittävän ICT:hen liittyvän poikkeaman vaikutus, henkilötietojen tietoturvaloukkauksen kriteerit, sopimusperusteiset ilmoitusvelvoitteet ja operatiivisen häiriönsietokyvyn vaikutus.

Vaihe 6: Lisää julkaisuportti

Ennen käyttöönottoa edellytä, että CI/CD-putki tai muutosprosessi vahvistaa seuraavat asiat:

• SBOM on tuotettu onnistuneesti
• Kriittisiä hyväksymättömiä haavoittuvuuksia ei ole jäljellä
• Uudet kolmannen osapuolen komponentit on hyväksytty
• Lisenssipolitiikan tarkastus on läpäisty
• SCA, SAST, DAST tai muu vaadittu testaus on valmis
• Muutostiketti on linkitetty
• Palautussuunnitelma on dokumentoitu korkean riskin julkaisuille

Tämä yhdistää A.8.25:n turvallisen kehittämisen, A.8.29:n tietoturvatestauksen ja A.8.32:n muutoksenhallinnan yhdeksi auditoitavaksi työnkuluksi.

Vaihe 7: Kokoa julkaisun näyttöpaketti

Säilytä jokaisesta julkaisusta:

• SBOM-tiedosto
• Koontitunniste ja commit-hajautusarvo
• SCA-skannaustulos
• Haavoittuvuuden triage-tallenne
• Hyväksytyt poikkeukset
• Muutoksen hyväksyntä
• Käyttöönoton tallenne
• Testitulokset
• Toimittajan näyttö, jos sovellettavissa
• Poikkeama- tai ongelmatallenne, jos julkaisu korjasi haavoittuvuuden

Kun auditoija kysyy, miten kolmannen osapuolen kirjastoja hallitaan tuotannossa, Amelian tiimin ei tarvitse etsiä tietoja Slack-ketjuista. Tiimi avaa julkaisun näyttöpaketin.

Vaatimustenmukaisuuden poikkikartoitus: yksi SBOM-ohjelma, monta velvoitetta

SBOM-ohjelman kaupallinen arvo kasvaa, kun se kartoitetaan kerran ja käytetään uudelleen eri viitekehyksissä. Clarysecin poikkivaatimustenmukaisuuden lähestymistapa välttää päällekkäistä työtä kääntämällä saman näytön eri varmentamiskielille.

NIS2-poikkeamaraportointi voi edetä nopeasti, kun hyväksikäyttö aiheuttaa tai voi aiheuttaa vakavan operatiivisen häiriön, taloudellisen menetyksen tai huomattavan aineellisen tai aineettoman vahingon. NIS2 käyttää vaiheittaista raportointia, mukaan lukien varhaisvaroitus 24 tunnin kuluessa tietoisuudesta, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti kuukauden kuluessa poikkeamailmoituksesta. SBOMit auttavat määrittämään, esiintyykö vaikutuksen kohteena oleva komponentti, vaikuttaako se asiakaspalveluihin ja onko rajat ylittävä vaikutus uskottava.

DORA käyttää jäsenneltyä ICT-poikkeaman elinkaarta, johon kuuluvat havaitseminen, kirjaaminen, luokittelu, juurisyyanalyysi, eskalointi, viestintäsuunnitelmat, eskalointi johtoelimelle ja sääntelyraportointi merkittävistä ICT:hen liittyvistä poikkeamista. SBOM-näyttö tukee luokittelua, koska se yhdistää haavoittuvan komponentin vaikutuksen kohteena oleviin asiakkaisiin, käyttökatkoon, maantieteelliseen laajuuteen, tietojen menetyksiin, palvelun kriittisyyteen ja taloudelliseen vaikutukseen.

NIST CSF 2.0 lisää hyödyllistä kieltä asiakasvarmennukseen. Zenith Controls kartoittaa A.5.21:n toimitusketjun hallinnoinnin tuloksiin, kuten GV.SC-05:een, jossa toimittajien kyberturvallisuusvaatimukset määritetään, viestitään ja sisällytetään sopimuksiin ja muihin järjestelyihin. SBOMeja, haavoittuvuuksien julkistamista, auditointinäyttöä ja korjausmääräaikoja koskevat vaatimukset muuttuvat sopimuskontrolliksi, eivät ad hoc -pyynnöksi.

Miten Zenith Blueprint vaiheistaa työn

Zenith Blueprint muuntaa kontrollikielen toteutuksen tiekartaksi.

Riskienhallintavaiheessa vaihe 14 yhdistää turvallisen kehittämisen, CI/CD-kontrollit, riippuvuusskannauksen, muutoksenhallinnan, poikkeamien käsittelyn ja kehittäjien koulutuksen. Controls in Action -vaiheessa vaihe 20 käsittelee nimenomaisesti kolmannen osapuolen ja avoimen lähdekoodin komponentteja:

Tämä hallintakeino koskee myös kolmannen osapuolen ja avoimen lähdekoodin komponentteja. Ulkoisiin kirjastoihin tukeutuminen on vakiintunut käytäntö, mutta jokainen sisällyttäminen on luottamuspäätös. Kehittäjien tulee arvioida riippuvuuksia maineen, ylläpitotiheyden, tunnettujen haavoittuvuuksien ja lisenssi- rajoitusten perusteella. SBOMien (Software Bill of Materials) kaltaiset työkalut ovat yhä tärkeämpiä sen seuraamiseksi, mitä teknologiapinoon on sisällytetty.

Vaihe 21 kehystää tietoturvatestauksen kontekstisidonnaiseksi ja suosittelee kerroksellista testausta liiketoimintakriittisille tai internetiin altistuville järjestelmille, mukaan lukien ohjelmistokoostumusanalyysi kolmannen osapuolen kirjastoille, staattinen ja dynaaminen analyysi, penetraatiotestaus, uhkamallinnuksen validointi, väärinkäyttötapausten testaus, fuzz-testaus ja manuaalinen tutkiva testaus.

Vaihe 23 käsittelee toimittajasopimuksia, mukaan lukien luottamuksellisuusvelvoitteet, pääsynhallinnan vastuut, tekniset ja organisatoriset toimenpiteet, poikkeamien raportointimääräajat, auditointioikeus, alihankkijakontrollit ja sopimuksen päättymistä koskevat ehdot.

Käytännön oppi on yksinkertainen. SBOMit kuuluvat riskienhallintaan, turvalliseen kehittämiseen, testaukseen, toimittajahallinnointiin, tietoturvapoikkeamiin reagointiin ja johdon raportointiin.

Auditointinäkökulma: mitä eri arvioijat testaavat

Kypsän SBOM-ohjelman tulee kestää erilaisia auditointityylejä.

ISO 27001:2022 -auditoija aloittaa ISMS:stä. Hän kysyy, kuuluuko ohjelmistojen toimitusketjuriski soveltamisalaan, sisältävätkö sidosryhmävaatimukset NIS2:n, DORA-asiakkaat, GDPR:n ja sopimukset, onko komponenttiriski osa riskimenetelmää, sisältääkö soveltuvuuslausunto olennaiset liite A:n hallintakeinot ja onko politiikkoja toteutettu ajan kuluessa. Hän voi ottaa otoksen yhdestä julkaisusta ja jäljittää sen politiikasta CI/CD-putkeen, SBOMiin, haavoittuvuusskannaukseen, muutoksen hyväksyntään, käyttöönottoon ja julkaisun jälkeiseen seurantaan.

DORA-arvioija tai finanssialan asiakas keskittyy operatiiviseen häiriönsietokykyyn ja ICT-kolmansien osapuolten riskiin. Hän voi kysyä, mitkä komponentit tukevat finanssialan toimijan käyttämää palvelua, tukeeko palvelu kriittistä tai tärkeää toimintoa, miten ICT-omaisuuserät ja riippuvuudet on dokumentoitu, seurataanko haavoittuvuuksia, kattaako vuosittainen testaus kriittiset järjestelmät ja sisältävätkö sopimukset avun, auditointioikeudet, poikkeamailmoitukset, tietojen sijainnin, alihankinnan ja päättämisehdot.

NIST CSF -arvioija etsii tuloksia. GOVERN-toiminnossa hän testaa oikeudellista, sääntelyyn perustuvaa, sopimusperusteista, tietosuoja- ja toimitusketjun hallinnointia. IDENTIFY-toiminnossa hän odottaa omaisuuden, ohjelmistojen ja palvelujen näkyvyyttä. PROTECT-toiminnossa hän testaa turvallista kehittämistä ja CI/CD-kontrolleja. DETECT- ja RESPOND-toiminnoissa hän tarkastelee haavoittuvuushälytyksiä, analyysia, eskalointia ja viestintää. RECOVER-toiminnossa hän kysyy, miten komponentin vaarantuminen vaikuttaa palauttamiseen ja asiakasviestintään.

COBIT- tai ISACA-tyyppinen auditoija keskittyy hallinnointiin, osoitusvelvollisuuteen, riskinomistajuuteen, kontrollien suunnitteluun ja näytön luotettavuuteen. Hän voi testata, ovatko SBOMit täydellisiä, suljetaanko haavoittuvuustiketit politiikan mukaisesti, vanhenevatko poikkeukset, onko toimittajien näyttö ajantasaista ja saako johto merkityksellistä raportointia.

Yleiset SBOM-virheet, joita tulee välttää

SBOM-ohjelmat epäonnistuvat yleensä ennakoitavista syistä.

Ensimmäinen virhe on SBOMien tuottaminen mutta niiden säilyttämättä jättäminen hallittuna näyttönä. Jos tiedosto ylikirjoitetaan jokaisessa koonnissa eikä sitä voi kytkeä julkaisuun, se on heikkoa auditointinäyttöä.

Toinen virhe on SBOMien erottaminen haavoittuvuuksien hallinnasta. Komponenttiluettelo ilman triagea, omistajuutta, korjaavia toimenpiteitä tai riskin hyväksymistä ei osoita kontrollin toimintaa.

Kolmas virhe on transitiivisten riippuvuuksien jättäminen ulkopuolelle. Haavoittuvuudet piiloutuvat usein suoran riippuvuuskerroksen alle.

Neljäs virhe on ulkoistetun kehittämisen jättäminen prosessin ulkopuolelle. Jos toimittaja toimittaa koodia ilman komponenttien julkistamista, skannausnäyttöä tai hyväksyntäkirjauksia, ohjelmistojen toimitusketjuun jää hallitsematon sokea piste.

Viides virhe on toimittajasopimusten allekirjoittaminen ilman näyttöoikeuksia. Hankinta allekirjoittaa sopimuksen, kehitystiimi käyttää palvelua ja tietoturva huomaa myöhemmin, ettei auditointioikeutta, haavoittuvuuksien julkistamisvelvoitetta, alihankkijarajoitusta eikä irtautumistukea ole.

Kuudes virhe on komponenttien kartoittamatta jättäminen liiketoimintapalveluihin. Haavoittuva paketti ei merkitse paljon, ennen kuin tiedetään, vaikuttaako se todennukseen, maksuihin, raportointiin, potilastietoihin, pilvihallintaan, asiakkaiden perehdytykseen tai säänneltyyn finanssityönkulkuun.

Seitsemäs virhe on ratkaisemattomien kriittisten haavoittuvuuksien piilottaminen johdolta. Sekä NIS2 että DORA tekevät johdon osoitusvelvollisuudesta nimenomaisen. Kriittisen komponenttiriskin tulee näkyä hallinnointifoorumeissa, ei hautautua kehitystiimin työjonoihin.

Miltä hyvä näyttää vuonna 2026

Auditointivalmiilla SBOM-ohjelmalla on selkeät tunnusmerkit.

Organisaatiolla on hyväksytty politiikka, joka edellyttää kolmannen osapuolen ja avoimen lähdekoodin komponenttien hyväksymistä, seurantaa, skannausta ja katselmointia. CI/CD-putki tuottaa SBOMit automaattisesti. SCA-skannaukset suoritetaan ennen käyttöönottoa ja soveltuvin osin ajon aikana. Kriittiset haavoittuvuudet käynnistävät määritellyn eskaloinnin. Poikkeuksilla on omistajat, voimassaolon päättymispäivät, korvaavat kontrollit ja riskin hyväksyntä.

Toimittajasopimukset sisältävät tietoturvavelvoitteet, loukkauksista ilmoittamisen määräajat, auditointioikeudet, alihankintakontrollit ja päättämisehdot. Kriittiset toimittajat katselmoidaan vähintään vuosittain. Toimittajariippuvuudet ja keskittymäriskit ovat näkyvissä. Ulkoistetun kehittämisen tiimit noudattavat samoja turvallisen kehittämisen ja komponenttien hyväksynnän sääntöjä kuin sisäiset tiimit.

Johdon raportointi yhdistää teknisen riskin liiketoimintavaikutukseen:

• Kriittiset haavoittuvat komponentit tuotteittain
• Altistus asiakkaan tai säännellyn palvelun mukaan
• Avoimet korjaavat toimenpiteet palvelutasosopimuksen yli
• Komponentit ilman hyväksyttyä lähdettä
• Tukemattomat tai elinkaarensa päässä olevat kirjastot
• Toimittajan näytön puutteet
• Poikkeukset, jotka odottavat uusimista tai sulkemista
• Komponenttihaavoittuvuuksiin liittyvät poikkeamat

Tässä vaiheessa SBOMit lakkaavat olemasta vaatimustenmukaisuusartefakti ja niistä tulee johtamisen väline.

Muunna SBOMit puolustettavaksi vaatimustenmukaisuusnäytöksi

Seuraavan kerran, kun kriittinen komponenttihälytys saapuu kello 07.42, vastauksen ei tulisi olla: ”Tarvitsemme kaksi tuntia selvittääksemme, missä se on.”

Vastauksen tulisi olla: ”Tässä on vaikutuksen kohteena oleva komponentti, tässä palvelut, tässä asiakkaat, tässä riskiluokitus, tässä korjaussuunnitelma ja tässä näyttö.”

Clarysec voi auttaa suunnittelemaan tämän kontrollijärjestelmän. Autamme organisaatioita määrittämään SBOM-soveltamisalan ISMS:n sisällä, kartoittamaan ISO 27001:2022 liite A:n hallintakeinot NIS2-, DORA-, GDPR-, NIST CSF 2.0- ja COBIT-tyyppisiin auditointiodotuksiin, toteuttamaan turvallisen kehittämisen ja toimittajapolitiikat, rakentamaan julkaisujen näyttöpaketit ja valmistelemaan auditointivalmista varmentamista Zenith Controls- ja Zenith Blueprint -ratkaisujen avulla.

Oletko valmis muuttamaan ohjelmistojen toimitusketjun epävarmuuden lähteestä häiriönsietokyvyn osoitukseksi?

Lataa asiaankuuluvat Clarysec-politiikat, vaiheista toteutus Zenith Blueprint -ratkaisulla ja kartoita näyttösi ISO 27001:2022-, NIS2-, DORA- ja asiakasvarmennusvaatimuksiin Zenith Controls -ratkaisulla. Ota yhteyttä Claryseciin, aloita kohdennetulla SBOM-valmiusarvioinnilla ja rakenna käytännöllinen, auditointivalmis ohjelmistojen toimitusketjun varmennusohjelma.