CRApreparedPreverite pripravljenost na CRA

Rešitve · SBOM Management

SBOM Management za EU Cyber Resilience Act

Cyber Resilience Act zahteva bistveno večjo preglednost dobavne verige programske opreme. Proizvajalec mora vedeti, katere programske komponente so vključene v njegov izdelek, katere ranljivosti vplivajo nanje ter kako se te ranljivosti obravnavajo skozi celoten življenjski cikel izdelka.

CRAprepared pomaga organizacijam vzpostaviti proces upravljanja SBOM ter ga povezati z obravnavo ranljivosti in dokumentacijo CRA.

Pogovorite se s strokovnjakom za CRA Vse rešitve

Zakaj potrebujete SBOM?

SBOM (Software Bill of Materials, kosovnica za programsko opremo) je strukturiran seznam programskih komponent, knjižnic in odvisnosti, ki sestavljajo digitalni izdelek. Priloga I, del II(1) CRA zahteva, da proizvajalec pripravi SBOM v splošno uporabni in strojno berljivi obliki, ki zajema vsaj najpomembnejše odvisnosti.

Pri CRA je pomemben predvsem zato, ker omogoča:

  • pregled nad uporabljenimi programskimi komponentami
  • prepoznavanje odprtokodnih knjižnic in knjižnic tretjih oseb
  • spremljanje znanih ranljivosti
  • hitrejšo oceno vpliva novih ranljivosti CVE
  • upravljanje dobavne verige programske opreme
  • podporo procesu obravnave ranljivosti
  • pripravo informacij za tehnično dokumentacijo CRA
  • sledljivost sprememb med različicami izdelka
SBOM ni samo datoteka

Prava vrednost nastane, ko SBOM postane del neprekinjenega procesa obravnave ranljivosti. Več v vodiču CRA in SBOM: kaj je dejansko zahtevano in v članku Ali je SBOM dovolj za CRA?

Regulativna opomba

CRA ne zahteva, da se SBOM javno objavi, in ne predpisuje določenega komercialnega izdelka ali formata. SBOM je del tehnične dokumentacije in se organu za nadzor trga predloži na obrazloženo zahtevo.

Tehnološka rešitev

Keysight SBOM Manager

Keysight SBOM Manager je ena od tehnoloških rešitev, ki jih lahko CRAprepared vključi v program CRA. Keysight zmogljivosti za SBOM ponuja v rešitvah SBOM Manager, SBOM Generator in SBOM Studio. V javnih gradivih proizvajalca sta opisana dva gradnika: SBOM Generator za ustvarjanje SBOM in SBOM Studio kot plast za upravljanje življenjskega cikla SBOM. Kako so moduli paketirani pod imenom SBOM Manager, preverite pri proizvajalcu.

Glavne zmogljivosti po dokumentaciji proizvajalca

  • Ustvarjanje SBOM iz prevedenih binarnih datotek, firmware slik in vsebnikov, brez dostopa do izvorne kode ali sistemov za gradnjo.
  • Prepoznavanje komponent: odprtokodnih in zaprtokodnih, z imeni, različicami in identifikatorji CPE in PURL.
  • Formati SPDX 2.3 in CycloneDX 1.6.
  • Upravljanje več dokumentov SBOM: sprejem SBOM iz različnih virov, tudi od dobaviteljev, preverjanje popolnosti in pravilnosti, normalizacija in ocena kakovosti.
  • Stalno spremljanje ranljivosti in licenčnih tveganj iz virov, kot so NVD, CISA KEV, OSV in obvestila proizvajalcev.
  • VEX: izjave o vplivu ranljivosti na izdelek, usklajene z življenjskim ciklom.
  • Pregledi in poročila: nadzorne plošče po portfelju izdelkov, revizijske sledi in generiranje dokazil. Proizvajalec v svojih gradivih navaja podporo regulativam, med njimi CRA.
  • Vključitev v CI/CD in procese varnosti izdelkov.
Opomba

Proizvajalec navaja, da je popolnost metapodatkov odvisna od informacij, ki jih je mogoče zanesljivo prepoznati v analizirani binarni datoteki. Pred odločitvijo preverite obseg modulov in licenčne pogoje pri proizvajalcu.

Binarna analiza

Kaj če nimamo dostopa do izvorne kode?

Pri številnih izdelkih proizvajalec ne razvija vseh komponent sam. Del programske opreme prihaja od zunanjih dobaviteljev, partnerjev OEM ali je vključen v firmware. V takšnih primerih klasična analiza izvorne kode ni vedno mogoča.

Rešitve za binarno analizo lahko pomagajo prepoznati programske komponente neposredno iz firmware slik, binarnih datotek, programske distribucije in končnega artefakta programske opreme. Takšen SBOM odraža, kar je dejansko dobavljeno, ne le kar je deklarirano.

To je še posebej pomembno za:

  • naprave IoT,
  • vgrajene sisteme,
  • industrijsko opremo,
  • medicinske naprave,
  • omrežno opremo,
  • naprave z vgrajenim firmware-om.
Od firmware slike do SBOM in ranljivostiFirmware slika vsebuje več komponent: odprtokodno knjižnico, statično vezano knjižnico in zaprtokodni blok dobavitelja. Iz njih nastane SBOM. Komponente se povežejo z ranljivostmi (CVE), za vsako pa se zabeleži odločitev VEX: prizadeto, ni prizadeto ali odpravljeno. Prikaz je ilustrativen.Firmwareslika / izdelekKomponenta Aodprta kodaKomponenta Bstatično vezanaKomponenta Czaprta koda OEMCVEVEX: prizadetoCVEVEX: ni prizadetoCVEVEX: odpravljenoSBOMkomponenteranljivosti, VEX
Ilustrativen prikaz. Komponente in oznake niso resnični izdelki ali CVE identifikatorji.

Potek dela

SBOM in obravnava ranljivosti: od izdelka do dokumentacije

Devet korakov, ki se po izdaji ponavljajo. Zadnji korak se vrne na prvega.

  1. Izdelek / firmware

    Izhodišče je dejansko dobavljeni artefakt.

  2. Ustvarjanje SBOM

    Iz izvorne kode, gradnje ali binarne datoteke.

  3. Prepoznavanje komponent

    Ime, različica, identifikatorji (PURL, CPE).

  4. Analiza CVE in ranljivosti

    Povezava komponent z viri ranljivosti.

  5. Ocena vpliva na izdelek

    Ali ranljivost v tem izdelku sploh deluje.

  6. Odprava ali omilitev

    Popravek, zamenjava ali drug ukrep.

  7. VEX in dokumentiranje odločitve

    Prizadeto, ni prizadeto, odpravljeno, v preiskavi.

  8. Tehnična dokumentacija CRA

    Povezava z mapo po Prilogi VII.

  9. Stalno spremljanje

    Nove ranljivosti v celotnem obdobju podpore.

Stalno spremljanje sproži nov krog, kadar se spremenita izdelek ali kontekst groženj.

Orodje je samo del programa

Orodje je samo del CRA programa.

CRAprepared poleg tehnološke platforme pomaga tudi pri vzpostavitvi celotnega procesa.

  1. 01

    Analiza okolja

    Pregled izdelkov, razvojnega procesa, CI/CD, repozitorijev izvorne kode, firmware-a, komponent tretjih oseb in obstoječega procesa obravnave ranljivosti.

  2. 02

    Strategija SBOM

    Kako SBOM nastaja, kdo je zanj odgovoren, kdaj se ustvari, kako se verzionira, preverja in shranjuje.

  3. 03

    Uvedba orodja

    Vzpostavitev ustreznega orodja, na primer Keysight ali Qualys, in vključitev v obstoječe procese.

  4. 04

    Potek obravnave ranljivosti

    Zaznati, analizirati, razvrstiti po prioriteti, odpraviti, preveriti in dokumentirati.

  5. 05

    Dokumentacija CRA

    Povezava tehničnih procesov z zahtevami CRA in tehnično dokumentacijo.

  6. 06

    Stalno spremljanje

    Spremljanje novih ranljivosti v celotnem obdobju podpore izdelka.

Neodvisna izbira orodja

CRAprepared pomaga izbrati in uvesti ustrezno tehnološko podporo glede na izdelek in razvojno okolje naročnika. Keysight in Qualys sta rešitvi, ki ju lahko vključimo v takšno okolje. Tehnološko orodje podpira izvajanje procesov CRA, skladnost pa zahteva kombinacijo organizacijskih, tehničnih in dokumentacijskih ukrepov.

Povezane vsebine

Avtor: ekipa CRApreparedStrokovnjak: Dejan Trop, Strateg kibernetske varnostiZadnji pregled: Uredniška politika

Keysight je blagovna znamka njenega lastnika. Omemba ne pomeni uradnega partnerstva ali podpore. Opisi zmogljivosti povzemajo javna gradiva proizvajalca.

Ne veste, kaj za CRA dejansko potrebujete?

Vsak izdelek in razvojno okolje sta drugačna. Pred nakupom orodij lahko pregledamo vaš trenutni razvojni proces in proces obravnave ranljivosti ter določimo, katere zahteve CRA že izpolnjujete in katere je treba še urediti.

Dogovorite se za CRA pregled Preverite, ali CRA velja