SBOM-automaatio

Miksi käsin tehdyt SBOM:t lakkaavat toimimasta

• Ne vanhenevat seuraavassa buildissa. Riippuvuudet muuttuvat jokaisessa julkaisussa, ja taulukko muuttuu vain, kun joku muistaa päivittää sen.
• Ne pysähtyvät siihen, minkä ihmiset näkevät. Suorat riippuvuudet on helppo luetella. Niiden alla olevat transitiiviset riippuvuudet eivät ole, eikä kukaan pysty seuraamaan niitä käsin.
• Ne monistuvat. Useampi tuote, joista jokaisella on useita tuettuja versioita, tarkoittaa kymmeniä tiedostoja, joilla kullakin on oma omistajansa ja oma käsityksensä totuudesta.
• Ne eivät vastaa olennaiseen kysymykseen. Kun uusi haavoittuvuus julkaistaan, sinun on tiedettävä, mitkä julkaisut sisältävät paketin. Taulukkokansion läpikäynti on hidasta, eikä vastaukseen voi luottaa.
• Niitä ei pyydetä. Asiakkaat ja työkalut odottavat koneluettavaa muotoa, kuten CycloneDX tai SPDX. Katso, miten vastaat asiakkaan SBOM-pyyntöön.

Mitä hyvä SBOM-automaatio tekee

1. Tuottaa SBOM:n jokaisesta buildista ilman, että kenenkään tarvitsee ajaa tai muistaa mitään.
2. Kattaa koko puun, transitiiviset riippuvuudet mukaan lukien, joka tasolla.
3. Sitoo jokaisen SBOM:n yhteen buildiin, jotta tiedät, mikä tiedosto kuvaa mitäkin julkaisua.
4. Kertoo, mitä se ei nähnyt, sen sijaan että esittäisi osittaisen listan kokonaisena.
5. Vie standardimuodossa, jotta SBOM toimii seuraavan työkalun ja seuraavan asiakkaan kanssa.
6. Seuraa toimitettua jatkuvasti, koska maanantaina puhdas julkaisu voi olla tiistaina haavoittuvuuden kohteena.

Kolme tapaa ylläpitää SBOM:eja vertailussa

Kysymys	Taulukko	Skanneri CI:ssä	Tallennettu buildin aikana
Milloin se päivittyy?	Kun joku muistaa	Kun skannausvaihe ajetaan	Jokaisessa buildissa
Mistä tiedot tulevat?	Ihmisiltä	Lukitustiedostoista tai valmiista tuotoksesta	Siitä, mitä buildi todella haki
Transitiiviset riippuvuudet?	Harvoin	Ne, jotka se pystyy päättelemään	Joka tasolla
Piilotetut riippuvuudet, kuten asennusskriptien lataukset?	Ei	Jäävät huomaamatta	Tallennetaan
CI-välimuistista palautetut paketit?	Ei	Riippuu työkalusta	Tallennetaan ja merkitään välimuistista tulleiksi
Haavoittuvuuksien seuranta?	Käsin	Yleensä erillinen työkalu	Sisäänrakennettu CRACI:ssa

Automatisointi skannerilla on todellinen parannus taulukkoon verrattuna, mutta se arvaa yhä, mitä buildiin meni. Perustelut löydät sivulta miksi buildi on totuuden lähde.

Mitä taulukoillesi tapahtuu

Komponenttitiedot siirtyvät pois: versiot ja paketit tulevat buildista, joten kenenkään ei tarvitse kirjoittaa niitä. Jäljelle jää tieto, joka on vain tiimilläsi, kuten mitä tuotteita on olemassa, kuka niistä vastaa ja mitkä versiot ovat yhä tuettuja. Se on se osa, joka on ihmisen ajan arvoinen.

Miten CRACI hoitaa tämän

CRACI korvaa GitHubin ylläpitämät runnerit nopeammilla ja edullisemmilla ja tallentaa SBOM:n jokaisen buildin aikana. Asetat runs-on: craci, ja ajosi näkyvät edelleen GitHubissa. Tavalliset buildit saavat kattavan SBOM:n ilman konfigurointia. Buildit, joilla on omat pakettirekisterit tai epätavalliset konttiasetukset, voivat vaatia hieman konfigurointia.

• Tallennettu, ei skannattu. CRACI näkee jokaiseen buildiin tulevan liikenteen, myös piilotetut riippuvuudet, jotka lukitustiedostoihin perustuvilta työkaluilta jäävät huomaamatta. Jokainen SBOM:n komponentti oli buildissa.
• Kattavuustila jokaiselle jobille, jotta tiedät, milloin buildia ei voitu tallentaa kokonaan ja miksi.
• Vienti CycloneDX- ja SPDX-muotoon, transitiiviset riippuvuudet ja komponenteista löydetyt haavoittuvuudet mukaan lukien.
• Yksi näkymä kaikkiin tuotteisiin. Inventaarionäkymä näyttää, mitkä ohjelmistoversiot on otettu käyttöön missäkin tuotteessa, ja CRACI arvioi seurattavat SBOM:t jatkuvasti uudelleen.

Käyttöönotosta tiimeissä, joilla on erilaiset putket, kerrotaan sivulla SBOM-generointi kehitystiimeissä.

SBOM-automaatio: usein kysytyt kysymykset

Mitä SBOM-automaatio on?

Ohjelmistojen materiaaliluettelon tuottamista osana buildia, jotta jokaisella julkaisulla on sellainen ilman, että kukaan laatii sitä käsin. Paremmat ratkaisut myös seuraavat jokaista SBOM:ia uusien haavoittuvuuksien varalta julkaisun jälkeen.

Voimmeko pitää SBOM:t Excelissä?

Taulukko voi toimia ensimmäisenä inventaariona, mutta sitä on vaikea pitää ajan tasalla, eikä se ulotu transitiivisiin riippuvuuksiin. Se ei myöskään ole standardi SBOM-muoto. Asiakkaat ja tietoturvatyökalut odottavat yleensä CycloneDX- tai SPDX-muotoa, ja kyberkestävyyssäädös (Cyber Resilience Act) edellyttää yleisesti käytettyä, koneluettavaa muotoa.

Vaatiiko SBOM-automaatio uuden vaiheen jokaiseen putkeen?

Useimpien generaattorien kanssa vaatii: lisäät vaiheen jokaiseen työnkulkuun ja pidät sen ajan tasalla. CRACI tallentaa SBOM:n runnerissa, joten jobeihisi ei tarvitse lisätä vaihetta.

Mitä ekosysteemejä CRACI tallentaa?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debianin ja Ubuntun paketit (apt), Alpinen paketit (apk) ja Git-lähteet sekä Yocton ja OpenEmbeddedin lataukset. Maven ja Java ovat tiekartalla.

Mitä CI-järjestelmiä ja alustoja CRACI tukee?

Tällä hetkellä GitHub Actionsia; muut CI-järjestelmät ovat tiekartalla. Runnerit ovat tällä hetkellä Linux x86-64 ja ARM64; Windows ja macOS ovat tiekartalla.

Entä toimittajilta ostetut komponentit?

Voit lisätä toimittajien SBOM:t CRACI:iin, jolloin ostettuja komponentteja seurataan omien buildiesi rinnalla.

Mitä se maksaa?

CRACI veloittaa vain build-minuuteista: $0.002 vCPU-minuutilta ($0.004 oletusarvoiselle 2 vCPU:n runnerille), mitattuna sekunneittain, ilman kuukausimaksua ja ilman SBOM-kohtaista maksua.