Tarkvara koostisosade loend
Tarkvara materjalide loend ehk SBOM on struktureeritud nimekiri komponentidest, millest tarkvara koosneb: paketid, nende versioonid, tarnijad, litsentsid ja see, kuidas need omavahel seotud on. See on nagu koostisosade loend karbi küljel.
Idee ei ole uus, kuid see on muutunud pakiliseks. Kui laialt kasutatavas teegis teatatakse tõsisest haavatavusest, küsib iga organisatsioon esmalt, kas see puudutab neid. Ilma SBOM-ita tähendab vastamine repositooriumide läbiotsimist, meeskondadelt küsimist ja lootmist. SBOM-iga on see üks päring. Kliendid ja regulaatorid ootavad üha enam, et tarnijad suudaksid sellele küsimusele kiiresti vastata, ja SBOM on see, kuidas seda teha.
Kaks vormingut, mõlemad avatud
Domineerivad kaks avatud vormingut. Linux Foundationi all hallatav SPDX keskendus algselt litsentsiteabele ja on avaldatud rahvusvahelise standardina ISO/IEC 5962. See on eriti tugev litsentside, autoriõiguse ning failide, pakettide ja dokumentide vaheliste seoste kirjeldamisel, mistõttu sobib see loomulikult vastavustööks.
OWASP-i projekt CycloneDX keskendus algselt turvalisusele. See on kompaktne, turbetööriistade poolt laialt toetatud ja laieneb loomulikult seotud teabele, nagu teadaolevad haavatavused, teenused ja leiu ärakasutatavus konkreetses kontekstis. See on sageli eelistatud vorming tarkvara tarneahela turbe konveierites.
Praktikas kattuvad need kaks suurel määral ja nende vahel on olemas teisendajad. Olulisem otsus ei ole see, millise vormingu valid, vaid see, kas lood SBOM-e järjepidevalt, automaatselt ja täpselt. Paljud organisatsioonid loovad mõlemat, kasutades kumbagi seal, kus selle tööriistad on kõige tugevamad.
SBOM-ide hea loomine
Käsitsi kirjutatud SBOM on aegunud hetkel, mil see salvestatakse. Ainus jätkusuutlik lähenemine on luua see ehituse osana samadest sisenditest, millest valmib tarkvara ise. Mõned harjumused teevad vahe kasuliku ja dekoratiivse SBOM-i vahel:
- Loo see ehituse ajal lukufailidest ja valminud artefaktist, mitte arendaja sülearvutist.
- Kaasa transitiivsed sõltuvused, mitte ainult otse nimetatud paketid.
- Salvesta täpsed versioonid ja paketiidentifikaatorid, et haavatavuste andmebaasid saaksid neid sobitada.
- Hoia iga SBOM-i koos väljalaskega, mida see kirjeldab, sama versiooninumbriga.
- Allkirjasta SBOM või lisa sellele kontrollsumma, et saajad saaksid usaldada, et seda ei ole muudetud.
SBOM-ide kasutamine, mitte ainult loomine
Kaustas seisev SBOM ei kaitse kedagi. Selle väärtus tuleb sellest, mida sa sellega teed. Turvalisuse poolel saab SBOM-e pidevalt haavatavuste skannerisse suunata, nii et äsja avalikustatud probleemi võrreldakse kõigega, mida oled tarninud, mitte ainult sellega, mida täna ehitad. Vastavuse poolel saab litsentsiandmeid enne väljalaset sinu poliitikaga võrrelda, püüdes probleemi kinni siis, kui selle parandamine on odav.
SBOM-id aitavad ka vestlustes väljaspool arendust. Hanked saavad neid tarnijatelt nõuda. Käitus saab neid kasutada uuenduste planeerimiseks. Ja kui klient küsib, kas teatud komponent on sinu tootes, saad vastata tõenditega, mitte rahustavate sõnadega.
Ausad piirangud
SBOM on täpselt nii täpne kui tööriist, mis selle lõi, ja tööriistad erinevad selle poolest, kui hästi nad tuvastavad komponente, mis on projekti kaasatud, sisse kopeeritud või lähtekoodist ehitatud. See kirjeldab, mis on olemas, mitte seda, kas see on ärakasutatav; see hinnang vajab endiselt inimesi ja konteksti. Ja kõike sisaldav SBOM võib olla üle jõu käiv, nii et investeeri filtreerimisse ja prioriseerimisse, mitte lihtsalt rohkemate andmete loomisesse.
Miski sellest ei ole põhjus oodata. Alusta oma kõige olulisemast rakendusest, loo SBOM mõlemas vormingus, vaata, mida see sulle ütleb, ja paranda üllatused. Peaaegu kindlasti leiad mõne. Selles ongi mõte.