Lühidalt
SBOM on masinloetav loend tarkvara komponentidest, versioonidest ja nende vahelistest sõltuvustest. See aitab vastata küsimusele „kas meid mõjutab see CVE?“ ilma kogu koodibaasi käsitsi läbi kammimata. CRA nõuab, et tootja tuvastaks ja dokumenteeriks komponendid ning tegeleks haavatavustega kogu tugiperioodi jooksul; SBOM on selle protsessi üks osa, mitte sertifikaat.
Hea SBOM on seotud konkreetse tooteversiooniga, sisaldab otseseid ja kaudseid sõltuvusi, on masinloetav ning uueneb iga väljalaske juures. PDF või käsitsi täidetud Excel võib olla parem kui mitte midagi, kuid ei toeta automaatset haavatavuste jälgimist.
Mis on SBOM
Software Bill of Materials on tarkvara „koostisosade loend“. Sarnaselt toiduainete koostisosade loetelule näitab see, millised teegid, raamistikud ja komponendid tootes on, millistes versioonides ning millistest allikatest need pärinevad. Erinevalt tavalisest sõltuvusfailist peab SBOM olema masinloetav ja seotud konkreetse buildi või väljalaskega.
SBOM-i põhikasutus on haavatavuste haldus. Kui avaldatakse uus CVE mõnele laialt kasutatavale teegile, saab SBOM-i päringuga tuvastada, millised tooted ja versioonid on mõjutatud. See lühendab aega, mis kulub tarnijate ja klientide teavitamisele, ning annab tõendi, et organisatsioon teab oma tarkvara koostist.
SBOM ei ole ainult turvameeskonna tööriist. See puudutab arendust, hanget, juriidilist vastavust ja klienditoe protsessi. Kui keegi küsib „kas teie tootes on log4j?“, peaks vastus tulema loendist, mitte mälust.
CRA, NIS2 ja ISO 27001
CRA nõuab tootjalt riskianalüüsi, komponentide tuvastamist ja dokumenteerimist ning haavatavuste käsitlemist kogu tugiperioodi jooksul. SBOM on selle nõude praktiline väljund: see aitab tuvastada mõjutatud komponente, hinnata mõju ja planeerida turvauuendusi. CRA ei ütle, et iga toote SBOM peab olema avalik, ega tee SBOM-ist eraldi sertifikaati.
NIS2/KüTS ei nimeta SBOM-i alati sõnasõnaliselt, kuid tarneahela turvalisus ja tõendid tarnijate kohta on osa nõuetest. SBOM aitab vastata küsimustele, milliseid komponente tarnija tootes kasutab ja kuidas ta haavatavustest teavitab. See ei asenda lepingulisi nõudeid ega tarnija riskianalüüsi.
ISO/IEC 27001 nõuab tarnijate ja tehnoloogiliste varade juhtimist. SBOM võib olla tõend komponentide jälgitavuse kohta, kuid standard ei kohusta ühte konkreetset formaati. Mõistlik on siduda SBOM riskiregistri, muudatuste halduse ja tarnijate hindamisega.
Oluline vahe: SBOM ütleb, mida tootes on. See ei ütle, kas komponent on turvaline, kas see on konfigureeritud õigesti ega kas tootes on äriloogika vigu. Neid küsimusi lahendavad riskianalüüs, konfiguratsiooni audit ja turvatestimine.
Mida loendisse panna
Minimaalne kasulik SBOM vastab küsimustele: mis komponent, mis versioon, kes on tarnija, kuidas seda unikaalselt identifitseerida ja milline on sõltuvussuhe. Praktiline väljade loend:
- Komponendi nimi ja versioon: täpne versioon, mitte ainult „latest“.
- Tarnija: organisatsioon või projekt, kes komponenti haldab.
- Identifikaator: package URL (purl), CPE või muu unikaalne viide.
- Otsene või kaudne sõltuvus: kas komponent on otseselt kasutusel või tuleb teise teegi kaudu.
- Allikas: paketihaldur, build-fail, konteineri kihid või tarnija edastatud loend.
- Räsi või allkiri: võimalusel komponendi terviklikkuse kontrolliks.
- Litsents: kasulik õiguslikuks ja tarneahela hindamiseks, kuigi mitte alati kohustuslik.
- Haavatavuse ja VEX-i viide: kas teadaolev CVE mõjutab komponenti ja milline on exploitability staatus.
- Omanik ja märkused: kes hoiab kirjet ajakohasena ja miks mingi otsus tehti.
Meie SBOM-i CSV-mall katab need väljad ja sobib väikese toote käsitsi alustamiseks. Suurema toote puhul genereeri loend build-protsessist ja kasuta CSV-d ainult erandite või ülevaate jaoks.
Formaadid: SPDX, CycloneDX ja SWID
Kolm levinumat valikut on SPDX (ISO/IEC 5962:2021), CycloneDX (OWASP) ja SWID (ISO/IEC 19770-2). SPDX on küps ja laialt kasutatav, CycloneDX on turvakeskne ning toetab hästi sõltuvusi ja VEX-i, SWID keskendub komponentide identifitseerimisele. Valik sõltub tööriistadest, klientide ootustest ja sellest, mida suudetakse protsessis päriselt hoida.
CRA ei sea eesmärgiks ühte formaati kõigile. Olulisem on, et formaat oleks masinloetav, versioonitav ja seotud konkreetse tooteversiooniga. Kui klient või hankija nõuab kindlat formaati, järgi nõuet; kui mitte, vali üks ja dokumenteeri valik.
| Formaat | Tugevus | Nõrkus |
|---|---|---|
| SPDX | Küps, ISO standard, lai tööriistatugi | Võib olla mahukas; VEX-i toe osas sõltub tööriistast |
| CycloneDX | Turvakeskne, sõltuvused ja VEX hästi kaetud | Vähem traditsiooniline hangete jaoks |
| SWID | Komponendi identiteet ja tarkvara märgistamine | Ei kirjelda sõltuvusi sama põhjalikult |
Kuidas SBOM-i teha
- Vali üks toode ja üks väljalase: ära alusta kogu portfellist. Vaata, millised sõltuvused on tegelikult olulised.
- Genereeri loend build-protsessist: kasuta paketihalduri või konteineri tööriista, mis loeb lukufailid ja kihid. Käsitsi loend vananeb kiiresti.
- Lisa puuduvad kaudsed sõltuvused: kontrolli, et loend ei jääks ainult otseste pakettide tasemele.
- Seo versiooniga: iga SBOM peab olema seotud konkreetse buildi, commiti või väljalaske identifikaatoriga.
- Määra omanik ja protsess: kes uuendab, kes kontrollib haavatavusi ja kes teavitab klienti.
- Testi päringut: vali tuntud CVE või komponent ja vaata, kas vastus tuleb loendist mõistliku aja jooksul.
Väikeettevõttele on parem üks usaldusväärne, versiooniga seotud loend kui ambitsioonikas programm, mis katab pooled tooted ja vananeb enne järgmist kvartalit.
SBOM-i elutsükkel
SBOM ei ole ühekordne fail. Selle väärtus sõltub sellest, kas see uueneb koos tootega ja kas keegi kasutab seda otsuste tegemiseks. Praktiline tsükkel:
- Iga väljalaske juures: genereeri uus SBOM ja arhiveeri see versiooni juurde.
- Regulaarne haavatavuste kontroll: võrdle komponente CVE/OSV andmebaasidega ning hinda mõju.
- VEX ja otsused: dokumenteeri, kas konkreetne haavatavus on mõjutatud, mitte mõjutatud või parandatud.
- Turvauuendused: seo parandus väljalaske, SBOM-i ja klienditeavituse vahel.
- Arhiveerimine: säilita vanad SBOM-id vähemalt tugiperioodi jooksul, et intsidenti saaks hiljem uurida.
- Ülevaatus: kontrolli protsessi mõõdikuid, näiteks SBOM-i katvust ja aega CVE tuvastamisest paranduseni.
Tüüpilised vead
- Ainult otsesed sõltuvused: kaudsed teegid jäävad välja ja suur osa ründepinnast on nähtamatu.
- Puuduv versioon: „log4j“ ilma versioonita ei aita haavatavust hinnata.
- Aegunud loend: SBOM on olemas, kuid ei vasta enam toote tegelikule buildile.
- Käsitsi Excel: sobib alguseks, kuid ei skaleeru ega toeta automaatset päringut.
- SBOM kui turvatõend: loend ei tõesta, et komponendid on turvalised või õigesti seadistatud.
- Puuduv omanik: keegi ei vastuta uuendamise ja klientide teavitamise eest.
Eesti ja tarnijad
Eesti ettevõtte jaoks on SBOM kõige otsesemalt seotud CRA ja NIS2 tarneahela nõuetega. Kui oled tarkvara- või seadmetootja, küsi oma komponentide tarnijatelt masinloetavat loendit ja teavita neid haavatavustest, mida ise leiad. Kui oled teenuseosutaja, küsi SBOM-i oma kriitilistelt tarkvaratarnijatelt ning kontrolli, kas nende tugiperiood ja teatamisprotsess vastavad sinu riskile.
SBOM-i ei tohiks nõuda kõigilt tarnijatelt ühesuguse detailsusega. Riskipõhine lähenemine on mõistlikum: kriitilistelt komponentidelt nõua masinloetavat loendit ja VEX-i, vähem kriitilistelt vähemalt versioonide ja haavatavuste teavitamise protsessi.
Loe lisaks: CRA juhend, NIS2 juhend ja NIS2 tarneahela artikkel.
Kontrolli SBOM-i CSV-d
Laadi allalaaditav töömall või oma sama veerustruktuuriga fail. Kontrollime kohustuslikke välju, identifikaatoreid, korduvaid komponente ja näidisväärtusi. Fail ei lahku sinu brauserist.
Kontroll on orienteeruv ega asenda SBOM-i kvaliteedi auditit. Laadi CSV-mall.
Küsimused SBOM-i kohta
Kas SBOM on CRA järgi kohustuslik?
CRA nõuab, et tootja tuvastaks ja dokumenteeriks toote komponendid, sealhulgas koostaks tarkvara koostisosade loendi. See on osa haavatavuste haldamise ja tehnilise dokumentatsiooni nõudest, mitte eraldi sertifikaat. Konkreetse vormingu ja detailsuse osas tuleb lähtuda kehtivast määrusest, harmoneeritud standarditest ja turujärelevalve ootustest.
Kas SBOM tõestab, et tarkvara on turvaline?
Ei. SBOM näitab, millised komponendid ja versioonid tootes on. See aitab haavatavusi jälgida ja tarnijaid küsitleda, kuid ei tõesta, et komponendid on turvalised või et tootes ei ole muid vigu.
Millises formaadis SBOM teha?
Levinumad masinloetavad formaadid on SPDX ja CycloneDX; SWID on alternatiiv komponentide identifitseerimiseks. CRA ei sea eesmärgiks ühte konkreetset formaati kõigile, kuid valitud formaat peab olema masinloetav, versioonitav ja seotud konkreetse tooteversiooniga.
Kas SBOM peab sisaldama kaudseid sõltuvusi?
Jah, täielik SBOM peaks näitama nii otseseid kui ka kaudseid sõltuvusi. Ainult otseste pakettide loetelu jätab välja suure osa tegelikust ründepinnast ega toeta usaldusväärset haavatavuste jälgimist.
Kes peaks SBOM-i haldama?
Tootja või tarkvaraomanik vastutab SBOM-i sisu ja ajakohasuse eest. Praktikas seotakse see build- või release-protsessiga, määratakse omanik ning kontrollitakse iga väljalaske juures. Turvatestimine saab kontrollida protsessi ja tõendeid, kuid ei asenda omanikku.
Kas väikeettevõte saab SBOM-iga hakkama?
Jah. Alustada saab ühest tootest ja ühest masinloetavast formaadist, genereerides loendi build-protsessist. Olulisem kui täiuslik tööriist on see, et loend on versiooniga seotud, omanik on määratud ja haavatavuste kontroll toimub regulaarselt.
Allikad
- CRA, määrus (EL) 2024/2847.
- CISA: Software Bill of Materials.
- SPDX ja CycloneDX.
- Küberturvalisuse seadus, Riigi Teataja.
See leht on selgitav, mitte õigus- ega sertifitseerimisnõu. Kohaldumise ja tõendite ulatuse kinnitab pädev asutus, teavitatud asutus või jurist.