Asiakkaan SBOM-pyyntö: näin vastaat siihen

Toimitatko komponentteja tai sulautettua ohjelmistoa valmistajille? Katso SBOM-opas toimittajille, joka käsittelee sopimukset, VEX:n ja SBOM:n jokaiselle toimitetulle ohjelmistoversiolle.

Miksi asiakkaat kysyvät nyt

• EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA). EU:ssa myyvät valmistajat tarvitsevat SBOM:n omasta tuotteestaan, ja niiden on noudatettava huolellisuutta hankkimiensa komponenttien kanssa, joten kysymys siirtyy alaspäin toimitusketjussa.
• NIS2. Keskeisten ja tärkeiden toimijoiden on huolehdittava toimitusketjun tietoturvasta. Direktiivi ei mainitse SBOM:eja, mutta SBOM on yksi tapa, jolla ostaja näkee, mitä toimittaja toimittaa. Katso SBOM:t NIS2-, ISO 27001- ja SOC 2 -näyttönä.
• Toimialakohtaiset säännöt. FDA:n section 524B edellyttää SBOM:ia kyberlaitteilta, ja muilla toimialoilla on omat sääntönsä.
• Asiakkaan oma haavoittuvuustyö. Asiakas, joka tietää, mitä tuotteessasi on, voi itse päätellä, koskeeko uusi CVE häntä, avaamatta tukipyyntöä.

Mistä sopia ennen kuin lähetät mitään

Kysymys	Miksi sillä on väliä
Mikä tuote ja versio?	SBOM kuvaa yhden julkaisun. Lähetä se, jota asiakas käyttää, älä uusinta buildia.
Mikä formaatti?	Useimmat pyynnöt hyväksyvät CycloneDX:n tai SPDX:n. Kysy, tarvitaanko tiettyä versiota.
Kuinka syvälle?	Ylimmän tason riippuvuudet eivät välttämättä riitä. Varaudu siihen, että myös transitiivisia pyydetään.
Kerran vai joka julkaisusta?	Sopimus voi edellyttää uutta SBOM:ia jokaisesta julkaisusta, mikä sulkee pois kaiken käsin tehdyn.
Millä ehdoilla?	SBOM näyttää, miten tuotteesi on rakennettu. Sopikaa luottamuksellisuusehdoista ja siitä, miten tiedosto toimitetaan.

Mitä hyvä vastaus sisältää

• SBOM:n sovitussa formaatissa juuri siitä julkaisusta, jota asiakas käyttää.
• Jokaisen komponentin nimen, version, toimittajan, lisenssin ja pakettitunnisteen kanssa.
• Riippuvuussuhteet, jotta transitiivinen paketti voidaan jäljittää siihen, mikä sen toi mukaan.
• Päivämäärän, sen tuottaneen työkalun ja buildin, josta se on peräisin.
• Rehellisen maininnan kaikesta, mitä SBOM ei kata (katso SBOM:n kattavuus).

Millaisia tiedostot ovat, näet sivulta SBOM-esimerkit. Kahdesta formaatista kerrotaan sivulla CycloneDX vs. SPDX. Mitä asiakas todennäköisesti tarkistaa vastaanottaessaan, kertoo SBOM:n laadun tarkistuslista.

Virheet, jotka kostautuvat myöhemmin

• Uusimman buildin lähettäminen toimitetun sijaan. Buildit eivät ole oletuksena toistettavia, joten saman commitin buildaaminen uudelleen ei takaa samaa SBOM:ia. Vain julkaisun tuottaneen buildin SBOM näyttää, mitä asiakas sai.
• Sen kokoaminen käsin tilannetta varten. Se täyttää pyynnön kerran, ja työ on toistettava seuraavalle asiakkaalle ja seuraavalle julkaisulle. Katso SBOM-automaatio.
• Lupaaminen enemmän kuin pystyt toistamaan. "Lähetämme sellaisen joka julkaisun yhteydessä" on helppo lause sopimukseen ja vaikea pitää ilman automaatiota.
• SBOM:n pitäminen asian päätepisteenä. Jatkokysymys on "koskeeko tämä CVE teitä?", ja se tulee silloin, kun seuraava iso haavoittuvuus tulee.

Näin olet valmis seuraavaan pyyntöön

Pyynnöistä tulee helppoja, kun SBOM on jo olemassa. Tuota sellainen jokaisesta julkaisusta siinä CI/CD-putkessa, joka sen buildaa, säilytä se julkaisun yhteydessä ja seuraa sitä uusien haavoittuvuuksien varalta. Silloin pyyntöön riittää lataus ja lyhyt saate, ja voit vastata jatkokysymykseen samasta tallenteesta.

Näin CRACI hoitaa tämän

CRACI tallentaa SBOM:n jokaisesta GitHub Actions -buildista, joka ajetaan sen runnereilla, joten jokaisella julkaisulla on jo sellainen, kun joku sitä pyytää.

• Vienti CycloneDX- tai SPDX-muodossa, mukaan lukien transitiiviset riippuvuudet ja komponenteista löydetyt haavoittuvuudet.
• Näyttö suoraan buildista. Jokainen SBOM:n komponentti oli buildissa, ja piilossa olevat riippuvuudet, jotka lukitustiedostoon perustuvilta työkaluilta jäävät huomaamatta, tallennetaan.
• Kattavuustila jokaiselle jobille, joten tiedät, mitä lähetät, ennen kuin lähetät sen.
• Build-historia. Näet aiemmat buildit ja niiden SBOM:t sekä sen, mitkä buildit sisälsivät haavoittuvan riippuvuuden, säilytysaikasi puitteissa.
• Vastaukset jatkokysymyksiin. CRACI arvioi seurattuja SBOM:eja jatkuvasti uudelleen, tukee VEX:iä ja näyttää inventaarionäkymässä, missä tuotteissa on mitkäkin versiot käytössä.

Asiakkaan SBOM-pyynnöt: usein kysytyt kysymykset

Onko meidän pakko antaa SBOM asiakkaille?

Se riippuu markkinastasi ja sopimuksistasi. Kyberkestävyyssäädös tekee SBOM:sta osan teknistä dokumentaatiota, joka toimitetaan markkinavalvontaviranomaiselle pyynnöstä, eikä se edellytä SBOM:n julkaisemista. Asiakkaan oikeus siihen perustuu yleensä sopimukseen, joten tarkista, mitä sopimuksessa on sovittu.

Missä formaatissa SBOM kannattaa lähettää?

CycloneDX tai SPDX, sen mukaan, kumpaa asiakas pyytää. Jos asiakkaalla ei ole toivetta, kumpi tahansa käy. Kysy, tarvitsevatko heidän työkalunsa tietyn version.

Pitääkö transitiiviset riippuvuudet ottaa mukaan?

Kyberkestävyyssäädös edellyttää vähintään ylimmän tason riippuvuudet, mutta monet ostajat odottavat koko puuta, ja haavoittuvuudet ovat usein transitiivisissa paketeissa. Täysi SBOM on turvallisempi vastaus.

Pitäisikö SBOM antaa asiakkaalle salassapitosopimuksella?

Se on sinun ja asiakkaasi päätös. SBOM näyttää, mistä tuotteesi koostuu, joten monet toimittajat jakavat sen olemassa olevan sopimuksen tai salassapitosopimuksen (NDA) nojalla julkaisemisen sijaan.

Kuinka usein päivitetty SBOM pitäisi lähettää?

Niin usein kuin sovitte. Riippuvuudet muuttuvat joka julkaisussa, joten uusi SBOM jokaisesta julkaisusta on rehellinen oletus, ja se on käytännössä mahdollista vain, jos SBOM syntyy buildista.

Entä jos asiakas kysyy vanhemmasta julkaisusta?

Tarvitset SBOM:n siitä buildista, joka tuotti kyseisen julkaisun. CRACI säilyttää build-historian säilytysaikasi puitteissa, oletuksena 180 päivää ja Enterprisessa mukautetulla säilytysajalla, joten vie kaikki, mitä sinun on säilytettävä pidempään.

Emme ole koskaan tehneet SBOM:ia. Mistä aloitamme?

Aloita julkaisusta, jota asiakkaasi käyttää, ja työkalusta, joka toimii oikean buildisi pohjalta. Jos käytät GitHub Actionsia, buildin siirtäminen CRACI-runnereille antaa sinulle tallennetun SBOM:n ensimmäisestä ajosta lähtien.