Vuonna 2026 raportoitiin päivässä 131% enemmän CVE:itä kuin edellisenä vuonna.

SBOM

Asiakkaasi haluaa SBOM:n: opas komponentti- ja ohjelmistotoimittajille

Yleensä kyllä, sinun on toimitettava se, ja syy on enemmän asiakkaasi sääntelyssä ja sopimuksessa kuin omissa velvoitteissasi. Tämä opas näyttää, miten kukin sääntelykehys ulottuu toimittajaan, mitä OEM:t odottavat sinun toimittavan, mitä sopia ennen ensimmäistä toimitusta, miten jakaa SBOM paljastamatta immateriaalioikeuksiasi ja miten SBOM:sta tehdään jokaisen julkaisun rutiinivaihe.

Päivitetty

Tämä opas on tarkoitettu valmistavan teollisuuden toimitusketjun toimittajille: ohjainlaitteet (ECU), näytöt, ohjaimet, yhdyskäytävät, taajuusmuuttajat, sulautetut Linux-pinot ja laiteohjelmistomoduulit. Jos myyt ohjelmistoa ja asiakas lähetti kertaluonteisen pyynnön, aloita sivulta miten vastata asiakkaan SBOM-pyyntöön, joka käsittelee sen tapauksen.

Miksi OEM:t kysyvät nyt

OEM:n SBOM-pyyntö on yleensä OEM:n oma sääntely, joka saapuu ovellesi sopimuksen kautta. Se, mistä sääntelystä on kyse, ratkaisee, mitä OEM:llä on oltava ja kuinka paljon siitä siirretään sinulle.

Kyberkestävyyssäädös

EU:n kyberkestävyyssäädöksen (Cyber Resilience Act, CRA), asetuksen (EU) 2024/2847, mukaan digitaalisia elementtejä sisältäviin tuotteisiin kuuluvat myös erikseen markkinoille saatettavat ohjelmisto- tai laitteistokomponentit (3 artiklan 1 alakohta). Komponentti, jota myyt sellaisenaan EU:hun, on oma tuotteensa, ja sinä olet sen valmistaja, jolla on oma SBOM-velvoitteensa: liitteen I osan II 1 kohta edellyttää SBOM:ia yleisesti käytetyssä ja koneluettavassa muodossa, joka kattaa vähintään tuotteiden ylimmän tason riippuvuudet. Jos komponentti on tarkoitettu integroitavaksi muihin tuotteisiin, ohjeidesi on myös annettava tiedot, joita integroija tarvitsee olennaisten vaatimusten noudattamiseen (liitteen II 8 kohdan f alakohta).

Myös OEM:llä on velvoitteita, jotka ulottuvat sinuun. Sen on noudatettava asianmukaista huolellisuutta integroidessaan kolmansilta osapuolilta hankittuja komponentteja (13 artiklan 5 kohta), ja kun se löytää haavoittuvuuden integroimastaan komponentista, sen on ilmoitettava siitä komponentin valmistavalle tai ylläpitävälle henkilölle tai taholle (13 artiklan 6 kohta). Komission heinäkuun 2026 CRA-ohjeistuksen mukaan huolellisuuden näyttö voi koostua komponentin valmistajalta saadusta dokumentaatiosta, eikä se mainitse SBOM:eja; käytännössä SBOM on usein juuri se dokumentaatio, jota OEM:t pyytävät. Raportointivelvoitteita sovelletaan 11.9.2026 alkaen, ja asetusta sovelletaan kokonaisuudessaan 11.12.2027 alkaen. Varaosat, jotka on valmistettu samojen eritelmien mukaan kuin niiden korvaamat komponentit, on rajattu ulkopuolelle (2 artiklan 6 kohta). Asetuksen muista osista kerrotaan sivuilla mikä CRA on ja CRA-opas.

Ajoneuvot

CRA:ta ei sovelleta tuotteisiin, jotka kuuluvat ajoneuvojen tyyppihyväksyntää koskevan asetuksen (EU) 2019/2144 soveltamisalaan (2 artiklan 2 kohdan c alakohta). Tyyppihyväksyttyjen ajoneuvojen komponentit tulevat markkinoille sen sijaan ajoneuvosääntöjen mukaan, eivätkä ne säännöt mainitse SBOM:ia lainkaan.

  • YK:n säännön nro 155 (kyberturvallisuus) mukaan valmistajan on kerättävä ja varmennettava tietoja koko toimitusketjusta osoittaakseen, että toimittajiin liittyvät riskit on tunnistettu ja niitä hallitaan (5.1.1(a)), näytettävä, miten sen kyberturvallisuuden hallintajärjestelmä hallitsee riippuvuuksia, joita voi olla sopimustoimittajiin, palveluntarjoajiin tai valmistajan alaorganisaatioihin (7.2.2.5), sekä tunnistettava ja hallittava hyväksyttävän ajoneuvotyypin osalta toimittajiin liittyvät riskit (7.3.2).
  • YK:n sääntö nro 156 (ohjelmistopäivitykset) edellyttää, että kaikki alkuperäiset ja päivitetyt ohjelmistoversiot ovat yksilöllisesti tunnistettavissa (7.1.1.2), ja jokaiselle RX Software Identification Numberille (RXSWIN) auditoitavaa rekisteriä, joka kuvaa kaikki RXSWIN:iin liittyvät ohjelmistot (7.1.2.3).
  • ISO/SAE 21434 järjestää OEM:n ja toimittajan välisen kyberturvallisuustyön hajautettuina toimintoina, ja työnjako sovitaan kyberturvallisuuden rajapintasopimuksessa (cybersecurity interface agreement).
  • Auto-ISACin SBOM Informational Report (helmikuu 2025) on alan oma ohjeistus.

Autoteollisuudessa SBOM tulee sopimusvaatimuksena, ei lakisääteisenä.

Teollisuusautomaatio

IEC 62443-4-1 koskee teollisuusautomaation ja ohjausjärjestelmien tuotteiden toimittajia. Se ei mainitse SBOM:eja, mutta käytäntö 6, tietoturvaan liittyvien asioiden hallinta (DM-1–DM-6), ja käytäntö 7, tietoturvapäivitysten hallinta (SUM-1–SUM-5, mukaan lukien SUM-3, "Dependent component or operating system security update documentation"), ovat kohtia, joissa SBOM toimii näyttönä.

Koneet

Koneasetusta (EU) 2023/1230 sovelletaan 20.1.2027 alkaen, eikä se mainitse SBOM:eja. Sen olennaiset vaatimukset, liitteen III kohta 1.1.9 "Suojaus tietojen turmeltumista vastaan", edellyttävät, että vaatimustenmukaisuuden kannalta kriittinen ohjelmisto tunnistetaan ja suojataan, että kone pystyy tunnistamaan siihen asennetun ohjelmiston, jota se tarvitsee toimiakseen turvallisesti, ja että näyttöä tuohon ohjelmistoon kohdistuneista toimenpiteistä kerätään. Digitaalisia elementtejä sisältävät koneet kuuluvat myös CRA:n piiriin, toisin kuin tyyppihyväksytyt ajoneuvot, ja siksi koneiden OEM:t pyytävät toimittajiltaan SBOM:eja jo nyt. Lue CRACI koneiden valmistajille ja teollinen IoT.

NIS2 ja sertifioidut asiakkaat

Jos toimitat keskeisille tai tärkeille toimijoille, esimerkiksi puolijohdealalla, NIS2-direktiivin 21 artiklan 2 kohdan d alakohta edellyttää, että asiakkaasi huolehtii toimitusketjun turvallisuudesta. Se ei mainitse SBOM:eja. Asiakkaat muuttavat sen kyselylomakkeiksi, ja ISO/IEC 27001:n liitteen A hallintakeinot 5.21 ja 8.8 ovat kohtia, joissa SBOM toimii näyttönä. Lue SBOM:t ISO 27001-, SOC 2- ja NIS2-näyttönä.

Sääntelykehykset rinnakkain

Kehys Koskee Mainitseeko SBOM:n? Mitä toimittajaan ulottuu
Kyberkestävyyssäädös (CRA) Digitaalisia elementtejä sisältäviä tuotteita EU:n markkinoilla, myös erikseen myytäviä komponentteja Kyllä, liitteen I osa II (1) Suoraan, jos saatat komponentin markkinoille; OEM:n huolellisuusvelvoitteen (13 art. 5 kohta) ja haavoittuvuusilmoitusten (13 art. 6 kohta) kautta
UN R155 ja R156 Tyyppihyväksyntää hakevia ajoneuvovalmistajia Ei Toimittajariskien hallinta (R155 7.2.2.5, 7.3.2) ja ohjelmistojen tunnistus (R156) sopimusten kautta
ISO/SAE 21434 Tieajoneuvojen kyberturvallisuussuunnittelua, OEM:iä ja toimittajia Ei julkisessa kuvauksessaan Hajautetut toiminnot ja kyberturvallisuuden rajapintasopimus
IEC 62443-4-1 Teollisuusautomaation ja ohjausjärjestelmien tuotteiden toimittajia Ei Suoraan, jos olet tuotteen toimittaja; SBOM:t toimivat näyttönä DM- ja SUM-käytännöille
Koneasetus Koneita ja niihin liittyviä tuotteita EU:n markkinoilla Ei Ohjelmiston tunnistus ja suojaus (liite III 1.1.9); CRA:ta sovelletaan rinnalla
NIS2 Keskeisiä ja tärkeitä toimijoita Ei Toimitusketjun turvallisuutta koskevat kyselyt ja sopimusehdot (21 art. 2 kohdan d alakohta, 21 art. 3 kohta)

Reitistä riippumatta asiakas tarvitsee saman asian: tarkan SBOM:n jokaisesta toimittamastasi ohjelmistoversiosta.

Mitä OEM:t tyypillisesti pyytävät

Vaatimukset vaihtelevat OEM:ittäin, mutta ne päätyvät samaan luetteloon. Tarkista SBOM:si sitä vasten ennen ensimmäistä toimitusta.

Vaatimus Tyypillinen odotus
Muoto CycloneDX tai SPDX, JSON tai XML, vähimmäisversiolla. BSI TR-03183-2 edellyttää CycloneDX 1.6:ta tai uudempaa tai SPDX 3.0.1:tä tai uudempaa.
Kentät CISA 2026 Minimum Elements- tai BSI TR-03183-2 -linjausten mukaiset: tekijä, aikaleima sekä kustakin komponentista nimi, versio, tuottaja ja tunnisteet
Tunnisteet Package URL aina, kun ekosysteemissä sellainen on, ja CPE, kun ei ole, jotta komponentit voidaan yhdistää haavoittuvuustietokantoihin
Lisenssit SPDX-lisenssitunnisteet. OEM:n lisenssiasiantuntija lukee ne arvioidakseen copyleft- ja muut lisenssiriskit.
Tiivisteet Jokaisen toimitetun binäärin tiiviste, jotta OEM voi varmistaa, että SBOM kuvaa sen vastaanottamaa tiedostoa. BSI edellyttää SHA-512:ta.
Syvyys Transitiiviset riippuvuudet, ei vain ylin taso
Tarkkuustaso Yksi SBOM jokaista toimitettua ohjelmistoversiota tai osanumeroa kohden
Toimitus ja vasteajat Toimituskanava ja vasteajat haavoittuvuuksia koskeviin kysymyksiin

Monet OEM:t tarkistavat nämä automaattisesti vastaanoton yhteydessä. SBOM:n laadun tarkistuslista kertoo, mitä asiakkaasi tarkistaa ja millä työkaluilla, ja SBOM-esimerkit näyttävät, miltä kentät näyttävät tiedostossa.

SBOM, kun avointa lähdekoodia on vähän tai ei lainkaan

Bare metal -ohjainlaitteen tai -ohjaimen, jonka suljettu laiteohjelmisto on tuotettu mallipohjaisella koodigeneroinnilla, rehellinen SBOM voi olla lyhyt: suljettu sovellus, oma käynnistyslataimesi, piirivalmistajan kirjastot tai kalibrointi sekä mahdollinen avoin lähdekoodi, kuten kryptografiakirjasto. Se on pätevä vastaus. Säännöt:

  • Listaa suljetut komponentit omilla tunnisteillasi: nimi, versio ja sinä tuottajana.
  • Kerro tunnetut tuntemattomat, kuten toimittajan kirjasto, jonka sisältöä et näe.
  • Älä koskaan paisuta SBOM:ia näyttääksesi perusteelliselta, äläkä koskaan jätä avoimen lähdekoodin kirjastoa pois siksi, että se on pieni.

Linux-pohjaisissa näytöissä ja yhdyskäytävissä tilanne on päinvastainen: satoja tai tuhansia komponentteja, mukaan lukien ydin, käynnistyslatain ja perusjärjestelmän paketit (lue verkkoon kytketyt laitteet). SBOM, joka listaa vain sovelluksesi ja muutaman kirjaston, on ensimmäinen asia, johon vastaanottava tiimi puuttuu. Jos buildaat Yoctolla, lue miksi skannerit eivät näe, mitä Yocto-buildeissa on.

Sopimukset: mitä sopia ennen ensimmäistä toimitusta

Ehto Miksi sillä on merkitystä
Kattavat tuotteet ja ohjelmistoversiot Jottei kukaan myöhemmin kiistele siitä, tarvitsiko variantti tai huoltojulkaisu SBOM:n
Muoto ja määrittelyn versio Heidän vastaanottoputkensa voi hylätä kaiken muun
Kentät ja kehys, jota ne noudattavat "BSI TR-03183-2 v2.1.0" tai "CISA 2026 Minimum Elements" on testattavissa; "kattava SBOM" ei ole
Toimituksen laukaisija Jokainen julkaisu, jokainen OEM:lle toimitettu ohjelmistoversio ja jokainen korjaus
Toimituskanava OEM:n toimittajaportaali, suojattu tiedostonvaihto tai sähköposti salassapitosopimuksen alaisena
Luottamuksellisuus Salassapitosopimus (NDA) tai voimassa oleva toimitussopimus, jossa SBOM nimetään luottamukselliseksi tiedoksi
Käyttörajoitukset Vain haavoittuvuuksien hallintaan ja vaatimustenmukaisuuteen, ei edelleen jakamista ilman suostumusta
Haavoittuvuusilmoitukset molempiin suuntiin OEM ilmoittaa komponentistasi löytämänsä haavoittuvuudet (CRA 13 art. 6 kohta); sinä ilmoitat sille omasi
VEX-odotukset Mikä muoto ja kuinka nopeasti arvioit uuden CVE:n
Säilytys Kuinka kauan säilytät kunkin version SBOM:n, sovitettuna tuotteen tukiaikaan
Tarkkuus ja tunnetut tuntemattomat Rehellinen ehto siitä, mitä SBOM voi kattaa ja mitä ei, suojaa molempia osapuolia

CISA:n SBOM Sharing Primer kuvaa autoteollisuuden tapauksen samalla tavalla: SBOM-pyynnöt sisällytettäisiin tavanomaisiin tiedonvaihtosopimuksiin (esimerkiksi salassapitosopimus, kyberturvallisuuden rajapintasopimus, kehitysrajapintasopimus).

Jakaminen paljastamatta immateriaalioikeuksia

SBOM ei ole lähdekoodisi. Se listaa komponenttien nimet, versiot, tuottajat, lisenssit, tiivisteet ja suhteet. Se ei sisällä koodiasi, algoritmejasi, kalibrointitietojasi eikä suunnitteluasi.

  • CRA ei velvoita valmistajia julkaisemaan SBOM:ia (johdanto-osan 77 kappale). Se toimitetaan markkinavalvontaviranomaiselle perustellusta pyynnöstä (liitteen VII 8 kohta).
  • CISA:n jakamisohjeistus kuvaa suljetun ohjelmiston tavalliset kanavat: sähköposti salassapitosopimuksen alaisena, asiakkaan toimittajaportaali tai suojattu dokumenttienvaihto tai oma pääsynhallittu portaalisi, ja sopimukset säätelevät luottamuksellisuutta ja pääsyä.
  • Käytännön vaihtoehdot: yksi täysi SBOM kullekin OEM:lle sopimuksen nojalla; suljettujen osien tunnisteet, jotka eivät paljasta sisäisiä projektinimiä; ja erillinen VEX-dokumentti, jotta voit päivittää haavoittuvuuden tilan lähettämättä SBOM:ia uudelleen.

Kuinka usein, ja mitä toimituksen jälkeen tapahtuu

  • Uusi SBOM jokaisesta toimittamastasi ohjelmistoversiosta samalla tunnisteella, jonka OEM flashaa tai rekisteröi. Ajoneuvoissa se liittyy R156:n ohjelmistotunnistukseen.
  • Korjattu SBOM, kun löydät virheen lähettämästäsi.
  • VEX-lausunto tai tietoturvatiedote, kun olet arvioinut haavoittuvuuden.

Jatkokysymys "koskeeko CVE-X teitä?" saapuu seuraavan ison haavoittuvuuden mukana. Ole valmis vastaamaan siihen toimitettu versio kerrallaan, mikä on mahdollista vain, jos säilytit jokaisen version SBOM:n.

VEX: mitä asiakkaasi odottaa seuraavaksi

VEX-dokumentti kertoo, koskeeko haavoittuvuus tuotetta. CISA:n Minimum Requirements for VEX (huhtikuu 2023) määrittelee neljä tilaa: not_affected, affected, fixed ja under_investigation. not_affected-lausunnon tulee antaa yksi viidestä perusteesta tai muuten vaikutuslausunto:

  • component_not_present
  • vulnerable_code_not_present
  • vulnerable_code_not_in_execute_path
  • vulnerable_code_cannot_be_controlled_by_adversary
  • inline_mitigations_already_exist

affected-lausunto tarvitsee toimenpidelausunnon: mitä asiakkaan pitäisi tehdä. VEX:iä on kolmessa muodossa: CSAF 2.0 -standardin VEX-profiili, CycloneDX VEX ja OpenVEX. Yocton SPDX 3.0 -tuloste sisältää VEX-tiedot oletuksena (muuttuja SPDX_INCLUDE_VEX).

Esimerkki. Linux-pohjaisessa näytössä on OpenSSL 3.0.8. CVE-2023-0464 kuvaa liiallista resurssien käyttöä varmennettaessa X.509-varmenneketjuja, jotka sisältävät käytäntörajoitteita. Käytäntöjen käsittely on oletuksena pois päältä, eikä näytön ohjelmisto koskaan ota sitä käyttöön. Toimittaja lähettää havainnollistavan OpenVEX-lausunnon:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

SBOM:ien tuottaminen toistettavasti

Miten buildaat Realistinen tapa tuottaa SBOM
CI:ssä buildattu ohjelmisto Generoi SBOM samassa buildissa, joka tuottaa toimitettavan ohjelmiston, ja säilytä se julkaisun kanssa
Yocto-pohjainen sulautettu Linux Yocton oma SPDX-tuloste (create-spdx) tarkistettuna sen suhteen, mitä se jättää pois, tai Yocto-buildin tallenne
Mallipohjaisilla työkaluilla tuotettu bare metal -laiteohjelmisto Generaattorikirjasto tai -työkalu, ei koskaan tekstieditori, ylläpidettynä jokaisen julkaisun kanssa ja validoituna ennen lähettämistä
Integroimasi kolmansien osapuolten binäärit Pyydä omalta toimittajaltasi sen SBOM; binäärianalyysi väliaikaisena korvikkeena, kunnes se saapuu

Reitistä riippumatta validoi tiedosto ennen lähettämistä. SBOM:n laadun tarkistuslista listaa validaattorit, joita asiakkaasi todennäköisesti ajaa, CycloneDX vs. SPDX auttaa muodon valinnassa, ja SBOM-generoinnin standardointi käsittelee sen yhtenäistämistä tiimien kesken.

Miten CRACI sopii kuvaan

Toimittajille, jotka buildaavat GitHub Actionsilla, CRACI korvaa GitHubin ylläpitämät runnerit ja tallentaa SBOM:n jokaisesta buildista, joten jokaisella toimitetulla versiolla on se jo valmiina.

  • SBOM listaa sen, mitä buildi todella haki mukaansa, transitiiviset riippuvuudet mukaan lukien, ja jokaisella paketilla on package URL ja jokaisella komponentilla ilmoitettu lisenssi.
  • Jokaisen jobin SBOM:lla on kattavuustila, joten tiedät, mitä lähetät, ennen kuin lähetät sen.
  • SBOM:t viedään CycloneDX- tai SPDX-muodossa, ja CRACI tukee VEX:iä.
  • Valvotut SBOM:t arvioidaan uudelleen, kun uusia haavoittuvuuksia julkaistaan, ja buildihistoria näyttää säilytysaikasi puitteissa, mitkä buildit sisälsivät haavoittuvan riippuvuuden.
  • Yocto-buildit toimivat CRACI:n runnereilla ja on dokumentoitu.
  • Kolmansien osapuolten SBOM:ja voi lisätä, joten ostamiasi komponentteja valvotaan omien buildiesi rinnalla.

Milloin CRACI ei ole oikea vastaus

  • Sinulla ei ole CI:tä, tai buildaat GitLabilla, Jenkinsillä tai build-palvelimella. CRACI tukee toistaiseksi vain GitHub Actionsia; muut CI-järjestelmät ovat tiekartalla.
  • Laiteohjelmistosi generoidaan mallipohjaisilla työkaluilla ilman pakettien hakua. Buildin tallennin tuo siihen vähän lisää.
  • Sinun on hostattava SBOM:eja monelle OEM:lle jakoportaalissa tai allekirjoitettava SBOM:eja. CRACI ei tarjoa kumpaakaan.
  • Buildiesi on toimittava omalla infrastruktuurillasi. Asiakkaan ylläpitämät runnerit ovat tiekartalla.
  • Asiakkaasi haluaa näyttöä organisaatiosi tietoturvan hallinnasta, kuten ISO 27001 -sertifikaatin tai vastaukset NIS2-kyselyyn. SBOM on näyttöä osasta sitä, ei sertifiointi. CRACI:n oma ISO 27001 -sertifikaatti kattaa CRACI:n palvelun, ei sinun palveluasi.

SBOM:t toimittajille: usein kysytyt kysymykset

Asiakkaani, OEM, pyysi SBOM:ia. Onko minun pakko toimittaa se?

Usein sitä edellyttää sopimus eikä laki. Jos saatat digitaalisia elementtejä sisältävän komponentin itse EU:n markkinoille, kyberkestävyyssäädös (CRA) edellyttää omaa SBOM:iasi. Muuten velvoite on OEM:n, joka siirtää sen sinulle huolellisuusvelvoitteen ja toimitussopimuksen kautta.

Koskeeko CRA komponentteja, joita myyn valmistajalle?

Jos saatat komponentin erikseen EU:n markkinoille, kyllä: 3 artiklan 1 alakohta kattaa erikseen markkinoille saatettavat ohjelmisto- tai laitteistokomponentit. Jos se tulee markkinoille vain OEM:n tuotteen sisällä, OEM on valmistaja ja sen on noudatettava asianmukaista huolellisuutta komponenttisi suhteen (13 artiklan 5 kohta). Tyyppihyväksyttyjen ajoneuvojen komponentit ovat CRA:n ulkopuolella (2 artiklan 2 kohdan c alakohta).

Edellyttääkö UN R155 tai ISO/SAE 21434 SBOM:ia?

Ei. R155 ei mainitse SBOM:ia lainkaan; se edellyttää, että ajoneuvovalmistaja hallitsee toimittajiin liittyviä riskejä. ISO/SAE 21434 järjestää kyberturvallisuustyön toimittajien kanssa rajapintasopimusten kautta. Autoteollisuudessa SBOM:t tulevat sopimusvaatimuksena.

Mitä muotoa ja kenttiä OEM odottaa?

Yleensä CycloneDX:ää tai SPDX:ää JSON- tai XML-muodossa, CISA 2026 Minimum Elements- tai BSI TR-03183-2 -linjausten mukaisesti: tekijä ja aikaleima sekä kustakin komponentista nimi, versio, tuottaja, package URL tai CPE, lisenssi ja tiiviste, transitiiviset riippuvuudet mukaan lukien.

Kuinka usein minun on lähetettävä päivitetty SBOM?

Jokaisesta toimittamastasi ohjelmistoversiosta, aina kun korjaat virheen, sekä VEX-lausunnon tai tietoturvatiedotteen kanssa, kun olet arvioinut haavoittuvuuden. Sovi laukaisija sopimuksessa.

Paljastaako SBOM:n jakaminen immateriaalioikeuksiamme?

Ei. SBOM listaa komponenttien nimet, versiot, tuottajat, lisenssit, tiivisteet ja suhteet, ei lähdekoodia, algoritmeja tai kalibrointitietoja. Jaa se salassapitosopimuksen tai toimitussopimuksen alaisena niin, että käyttö on rajattu haavoittuvuuksien hallintaan ja vaatimustenmukaisuuteen. CRA ei edellytä sen julkaisemista.

Mikä VEX on, ja pyytääkö asiakkaani sitä?

VEX kertoo, koskeeko haavoittuvuus tuotetta: not_affected, affected, fixed tai under_investigation, ja not_affected-tilalle annetaan peruste. Varaudu siihen, että sitä pyydetään seuraavan laajasti uutisoidun haavoittuvuuden jälkeen, joka koskee toimittamaasi komponenttia.

ECU-laiteohjelmistossamme ei ole avointa lähdekoodia. Miltä SBOM:imme näyttää?

Lyhyeltä ja rehelliseltä: suljettu sovellus, käynnistyslatain, mahdolliset piirivalmistajan kirjastot tai kalibrointi sekä mahdollinen avoin lähdekoodi, kuten kryptografiakirjasto, kukin omilla tunnisteillasi, sekä tunnetut tuntemattomat. Älä paisuta sitä.

Pidä SBOM valmiina jokaisesta toimittamastasi versiosta

Varaa demo ja aja yksi GitHub Actions -buildisi CRACI:lla. Saat SBOM:n siitä, mitä buildi haki mukaansa, kattavuustiloineen.

Varaa demo