CRACI vs. Dependency-Track

Missä Dependency-Track on hyvä

OWASP Dependency-Track on vahva valinta komponenttianalyysiin. Se on avointa lähdekoodia Apache 2.0 -lisenssillä, se seuraa komponenttien käyttöä portfoliosi jokaisen sovelluksen jokaisessa versiossa, ja se hakee haavoittuvuustietoja useista lähteistä, kuten National Vulnerability Databasesta ja GitHub Advisoriesista. Sen käytäntömoottori kattaa tietoturva-, lisenssi- ja toimintasäännöt, ja se lukee ja tuottaa CycloneDX VEX -dokumentteja. Sen API-lähtöinen rakenne sopii CI/CD:hen: putket lataavat SBOM:t osoitteeseen /api/v1/bom.

Säännellyillä aloilla toimivat tiimit pitävät siitä, koska se on läpinäkyvä, itse ylläpidetty ja rakennettu standardiformaatin ympärille. Sen heikkous ei ole analyysi. Se on se, mitä analyysiin syötetään.

Analyysi riippuu syötteestä

Dependency-Track lukee SBOM:eja; se ei generoi niitä. Jokainen löydös, käytäntörikkomus ja portfolionäkymä riippuu SBOM:sta, jonka putkesi lähettää. Jos SBOM:sta puuttuu riippuvuus, Dependency-Track ei voi liputtaa sitä. Jos kaksi generaattoria on eri mieltä, Dependency-Track näyttää sen, jonka latasit.

Käytännössä SBOM-generaattorit ovat usein eri mieltä, ja syyt löytyvät niiden omasta dokumentaatiosta:

• Ei yhteistä pohjaa. Jokainen generaattori päättää itse, mikä lasketaan komponentiksi ja mihin tiedostoihin luotetaan, joten kaksi generaattoria samassa repossa palauttaa osittain päällekkäiset mutta eri listat.
• Ilmeinen jää huomaamatta. Työkalulla, joka ratkaisee riippuvuudet lukitustiedostoista, ei ole mitään ratkaistavaa repossa, joka ei commitoi niitä, kuten express 5.2.1 ei commitoi. Se voi silti palauttaa listan, joka koostuu kaikesta muusta, minkä se tunnistaa, kuten GitHub Actionsista ja työnkulkutiedostoista.
• Asetukset heiluttavat tulosta. Syft valitsee catalogerinsa skannaustyypin mukaan, joten yksi lippu muuttaa sitä, mitä sama työkalu samassa versiossa raportoi samasta checkoutista.
• Ei manifestia, ei SBOM:ia. Repo, jossa ei ole lainkaan riippuvuusmanifestia, ei anna tiedostopohjaiselle skannerille mitään, mistä lähteä, ja se, mitä kukin työkalu silloin palauttaa, kertoo enemmän työkalusta kuin projektista.
• Ohuet metatiedot. Useimmilla generaattoreilla ei ole lähdettä NTIA:n supplier-kentälle, joten se jää tyhjäksi riippumatta siitä, mitä repossa on.

CRACI:a ei voi verrata tällä tavalla. Se tallentaa buildeja eikä skannaa hakemistoa, joten sitä ei voi ajaa samalla tavalla. Pointti ei ole, että mikään näistä työkaluista olisi huono. Pointti on, että repon staattinen skannaus on arvio siitä, mitä build käyttää, ja arvio vaihtelee työkalun, sen asetusten ja repossa olevien tiedostojen mukaan.

Mitä CRACI muuttaa lähteellä

SBOM tulee buildista

CRACI on GitHub Actions -yhteensopiva runneri. Vaihdat runs-on-arvoksi craci, ja jobisi ajetaan CRACI:ssa eristetyissä virtuaalikoneissa. Jokaisen jobin aikana pakettitietoinen välityspalvelin (proxy) tallentaa liikenteen pakettilähteisiin: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk ja Git-lähteet sekä latausten esiasetukset. Riippuvuusnäyttö kulkee CI-välimuistien mukana, joten välimuistista palautettu paketti on silti kirjauksessa. SBOM, CycloneDX- tai SPDX-muodossa, sisältää kaikki transitiiviset riippuvuudet, joita build oikeasti käytti.

Se kertoo, kun se on vajaa

Jokaisella CRACI:n SBOM:lla on kattavuustila jobia ja välimuistia kohden: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded. Tiedät, onko kukin SBOM täydellinen kirjaus vai onko siinä aukko. Sillä on merkitystä, kun auditoija kysyy, mistä tiedät inventaariosi olevan kattava.

Se tallentaa SBOM:n buildin sisällä

CRACI generoi SBOM:n omassa runnerissaan sen perusteella, mitä jobi haki. API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot.

Se hallitsee, mihin build pääsee

Koska CRACI ajaa jobin, se voi valvoa lähtevän liikenteen käytäntöä: oletuksena estävä tai oletuksena salliva, ja mukana on 24 valmista ohjelmistolähteiden esiasetusta sekä tyypitetyt omat lähteet. Käytännöt validoidaan ennen jobin alkua, ja ne toimivat fail closed -periaatteella. Dependency-Track voi kertoa jälkikäteen, että komponentti on riskialtis; egress-käytäntö rajaa jo etukäteen, mistä lähteistä build ylipäätään voi hakea.

Inventaario siitä, mitä on käytössä missäkin

CRACI:n inventaarionäkymä näyttää tarkalleen, mitkä ohjelmistoversiot on otettu käyttöön missäkin tuotteessa, maailmanlaajuisesti. Kun uusi haavoittuvuus julkaistaan, näet, missä tuotteissa haavoittuva versio on, sen sijaan että kokoaisit tiedon julkaisutiedotteista ja taulukoista.

Dependency-Trackin korvaaminen CRACI:lla

CRACI kattaa työn molemmat puolet, joihin ennen tarvittiin generaattori ja Dependency-Track. Se tuottaa SBOM:n buildissa, arvioi seurattuja SBOM:eja jatkuvasti uudelleen sitä mukaa kuin uusia haavoittuvuuksia julkaistaan, kokoaa löydökset buildien ja repojen yli ja antaa tietoturvatiimien tehdä niille triagen ja ohjata kunkin korjauksesta vastaavalle tiimille. Ylläpidettävää latausvaihetta tai ajettavaa palvelinta ei ole.

Ole selvillä siitä, mistä luovut. Dependency-Trackin käytäntömoottori on kypsä. CRACI:ssa on buildeja estävät käytäntöportit ja lisenssikäytäntö, kun taas kommentit ja kynnysarvohälytykset ovat tiekartalla. Dependency-Track on myös avointa lähdekoodia ja itse ylläpidetty, kun taas CRACI on nyt hallinnoitu palvelu, ja asiakkaan ylläpitämät runnerit ovat Enterprisen tiekartalla. Jos nämä painavat enemmän kuin inventaarion laatu, pidä Dependency-Track.

Miksi tämä on tärkeää säännellyillä aloilla

EU:n kyberkestävyyssäädöksen (Cyber Resilience Act, CRA) mukaan valmistajien on tiedettävä, mitä kussakin tuotejulkaisussa on, ja käsiteltävä siinä olevat haavoittuvuudet, ja aktiivisesti hyödynnettyjen haavoittuvuuksien raportointivelvollisuudet alkavat syyskuussa 2026. Haavoittuvuus, jota et näe, koska SBOM:stasi puuttui komponentti, on silti sinun haavoittuvuutesi.

CRACI automatisoi merkittävän osan siitä ohjelmistotoimitusketjun näkyvyydestä ja näytöstä, jota yritykset tarvitsevat laajempaan CRA-vaatimustenmukaisuusprosessiinsa, ja vie SBOM:t CycloneDX- tai SPDX-muodossa haavoittuvuuksineen. Inventaario ja seuranta perustuvat samaan kirjaukseen siitä, mistä kukin julkaisu on buildattu. Katso CRA-vaatimustenmukaisuus, teollinen IoT ja tietoliikenne.