SBOM ir VEX: kas jie yra ir kuo jie skiriasi
SBOM nurodo, iš ko produktas pagamintas. VEX nurodo, ar žinomas pažeidžiamumas jį iš tikrųjų veikia. Jie atsako į skirtingus klausimus.
Du dokumentai, du klausimai
SBOM (programinės įrangos medžiagų sąraše) išvardijami komponentai, iš kurių sukurtas produktas – bibliotekos, jų versijos ir kaip jos yra susijusios. Jame atsakoma į klausimą: „ar mes tiekiame šį komponentą ir kokią versiją?“
VEX (pažeidžiamumų išnaudojimo mainų) dokumente įrašoma, ar konkretus žinomas pažeidžiamumas iš tikrųjų paveikia konkretų produktą ir kodėl. Jame atsakoma į klausimą: „šis CVE yra mūsų tiekiamame komponente – ar tai čia svarbu?“
Šis skirtumas yra svarbus, nes dauguma priklausomybėje randamų pažeidžiamumų nėra pasiekiami produkte, kuriame ji yra. Be VEX kiekvienas CVE kiekviename komponente tampa kliento klausimu. Naudojant VEX, tiekėjas vieną kartą pareiškia poziciją, pagrįstą argumentais, forma, kurią gali perskaityti mašina.
Ką SBOM suteikia ir ko neduoda
Praktinė vertė yra matomumas: kai plačiai naudojama biblioteka pasirodo esanti pažeidžiama, tikslus SBOM atsako į klausimą „ar esame paveikti ir kur?“ per kelias minutes, o ne dienas. Būtent dėl šios priežasties SBOM tapo reikalavimu, o ne gera idėja.
Ko SBOM nepasako:
- Ar išvardytas komponentas iš tikrųjų pasiekiamas veikiančiame produkte. Daugelis jų yra kompiliuojami, bet niekada iškviečiami jokiu užpuoliko kontroliuojamu keliu.
- Ar jūsų konfigūracijoje galima išnaudoti komponento pažeidžiamumą.
- Ar sąrašas vis dar teisingas. SBOM aprašo vieną versiją; kita versija gali skirtis.
- Viskas apie paslaugų komponentus, į kuriuos produktas kreipiasi, bet nesiunčia.
Du įprasti formatai yra SPDX (ISO standartas, ISO/IEC 5962) ir CycloneDX (OWASP projektas, taip pat standartizuotas per „Ecma“). Abu yra plačiai palaikomi; pasirinkimas paprastai priklauso nuo to, ką jau naudoja jūsų klientai ir įrankiai. SBOM generavimas iš sukurtos versijos yra patikimesnis nei generavimas nuskaitant baigtą artefaktą, nes sukurtos versijos sistema žino, kas iš tikrųjų buvo įtraukta.
Ką sudaro VEX sakinys
VEX teiginys susieja produkto versiją su pažeidžiamumu ir įrašo būseną. Keturios būsenos yra šios:
- Nepaveikta – pažeidžiamumas yra komponente, bet šiame produkte juo pasinaudoti negalima. Šiai būsenai reikalingas pagrindimas, pavyzdžiui, pažeidžiamas kodas niekada nevykdomas arba nepasiekiamas iš jokios įvesties.
- Paveiktas – pažeidžiamumas yra. Pareiškime turėtų būti nurodyta, ką daryti.
- Ištaisyta – šioje versijoje yra pataisymas.
- Vykdomas tyrimas – tiekėjas dar nenustatė atsakymo.
Pagrindimas yra esmė. „Nepaveikta“ be jokios priežasties yra teiginys; „nepaveikta, nes pažeidžiamos funkcijos nėra kompiliuojamame dvejetainiame faile“ yra įrodymas, kurį klientas gali pasverti. VEX galima išreikšti „CycloneDX“ viduje, kartu su SPDX, arba CSAF – OASIS patariamajame formate, kurį naudoja daugelis tiekėjų ir CISA.
CISA paskelbė darbo grupės dokumentus, kuriuose apibrėžiamas VEX ir jo būsenos: CISA VEX ištekliai ↗ . Minimalių elementų apibrėžimas SBOM yra paimtas iš NTIA ↗ .
Kaip jie veikia kartu
Būtent šis poravimas ir daro abu šiuos duomenis naudingus dideliu mastu. SBOM pateikia informaciją, o VEX ją filtruoja iki to, kas nusipelno dėmesio.
CVE patenka į jūsų išsiųstą biblioteką.
SBOM rodo, kuriose produkto versijose yra paveikta biblioteka ir kurioje versijoje.
Inžinerija tikrina, ar pažeidžiama funkcija pasiekiama iš bet kokios įvesties, kurią produktas pateikia.
VEX ataskaitoje įrašoma išvada ir priežastis pagal paveiktą produkto versiją.
Išvada pakartotinai patikrinama, kai keičiasi produktas, nes pasiekiamumas gali pasikeisti nekeičiant komponento.
Iliustracinis darbo eigos pavyzdys, o ne užbaigtas kliento atvejis.
Iš kur kyla reikalavimas
ES parduodamiems produktams Kibernetinio atsparumo akte (Reglamentas (ES) 2024/2847) I priede numatytas SBOM reikalavimas kaip pažeidžiamumų valdymo dalis, o pagrindiniai įpareigojimai taikomi nuo 2027 m. gruodžio 11 d., o 14 straipsnio nuostatos įsigalioja nuo 2026 m. rugsėjo 11 d. Jungtinėse Amerikos Valstijose vykdomuoju įsakymu Nr. 14028 SBOM reikalavimai buvo įtraukti į federalinius programinės įrangos pirkimus.
Nei vienas režimas SBOM nelaiko sertifikatu. Tai vienas iš kelių įrašų, ir vien jo pateikimas neįrodo, kad produktas yra saugus ar kad įvykdytos ataskaitų teikimo pareigos.
Dažnai užduodami klausimai
Ar VEX gali pakeisti pažeidžiamumo taisymą?
Ne. VEX įrašo vertinimą. Jei pažeidžiamumas yra išnaudojamas, jam suteikiama būsena „paveiktas“, o taisomosios priemonės vis tiek taikomos. VEX pašalina triukšmą iš pažeidžiamumų, kurie netaikomi; jis nepašalina tų, kurie yra.
Ar turime viešai skelbti savo SBOM?
Nebūtinai. Reikalavimai paprastai yra susiję su įrašo rengimu ir tvarkymu bei jo pateikimu atitinkamoms šalims, o tai daugelio produktų atveju reiškia jo pateikimą klientams arba valdžios institucijoms paprašius, o ne viešą skelbimą.
SPDX ar CycloneDX?
Abu yra priimami. „CycloneDX“ turi VEX, o tai patogu, jei ketinate skelbti išnaudojimo teiginius kartu su inventoriumi. SPDX yra plačiau naudojamas licencijų atitikčiai. Vadovaujantis tuo, ką jau gauna jūsų klientai, išvengiama konvertavimo darbo.
Kaip dažnai reikia regeneruoti SBOM?
Kiekvienam išleistam kūriniui. SBOM aprašo vieną artefaktą; jei artefaktas pasikeičia, ankstesnis įrašas nebeaprašo to, ką išsiuntėte.
O kaip dėl paslaugų komponentų, kuriuos mes iškviečiame, o ne siunčiame?
Jie neįeina į produkto SBOM ir vis tiek kelia riziką. Jie turėtų būti įtraukti į tiekėjo ir architektūros peržiūrą, o ne į artefakto medžiagų sąrašą.
Jums nereikia žinoti techninių terminų.
Papasakokite, kas vyksta, kokį poveikį tai daro ir kada jums reikia pagalbos. Aptarsime, ar galime padėti ir koks būtų naudingas pirmasis darbas.