CRACI vs. Kusari

Lyhyt vastaus

Kusari on ohjelmistotoimitusketjun tietoturva-alusta tiimiltä, joka oli mukana luomassa GUACia, toimitusketjun metatietojen avoimen lähdekoodin graafia. Se rakentaa jatkuvasti päivittyvän tietograafin lähdekoodistasi, SBOM:eistasi, VEX-dokumenteistasi ja olemassa olevien skannerien tuloksista, asettaa hyödynnettävät haavoittuvuudet järjestykseen, katselmoi pull requesteja ja avaa korjauksia. CRACI on GitHub Actions -runneri. Se tallentaa, mitä kukin buildi tuo mukanaan ajon aikana, hallitsee, mihin buildi pääsee, ja seuraa jatkuvasti sitä, mitä on toimitettu. Mikä tahansa graafi heijastaa sille annettuja SBOM:eja; CRACI tuottaa SBOM:t itse buildista. Molemmat kilpailevat samasta toimitusketjun tietoturvabudjetista. Itse buildaamallesi ohjelmistolle CRACI kattaa CI:n, SBOM:n ja haavoittuvuuksien seurannan yhdessä tuotteessa.

Lyhyesti

Kusari ja GUAC tarkasti

GUAC (Graph for Understanding Artifact Composition) on OpenSSF:n inkubointivaiheen projekti Supply Chain Integrity -työryhmän alla, ja sen lisenssi on Apache 2.0. Se kokoaa ohjelmistojen tietoturvametatiedot graafitietokantaan. Sen dokumentoituja syötteitä ovat CycloneDX- ja SPDX-SBOM:t, in-toto- ja SLSA-attestaatiot, OpenVEX- ja CSAF-dokumentit, OpenSSF Scorecard -tulokset sekä OSV- ja deps.dev-tiedot. GUAC kokoaa muiden työkalujen tuottamia metatietoja; se ei aja buildeja.

Kusarin perustajat loivat GUACin yhdessä Googlen kanssa, ja yksi Kusarin perustajista on GUACin päämaintainer. Kusari kertoo käyttävänsä ja kuratoivansa GUACia, SLSA:ta, OpenSSF Scorecardia, ClearlyDefinediä ja muita avoimen lähdekoodin projekteja kaupallisissa tuotteissaan. GUACilla on myös muita kehittäjiä, kuten Google, Red Hat, Purduen yliopisto ja Citi. Kusari on kaupallinen alusta; GUAC on yhteisöprojekti.

Missä Kusari on hyvä

Avoimista standardeista rakennettu graafi. Kusarin alusta ottaa vastaan lähdekoodin, build-artefaktit, CycloneDX- ja SPDX-SBOM:t, VEX:n ja olemassa olevien skannerien tulokset, myös Snykin, Black Duckin, Prisma Cloudin, Dependabotin ja GitHub Advanced Securityn tulokset. Se kartoittaa suorat ja transitiiviset riippuvuudet alkuperätietoineen ja polveutumisineen ja näyttää uuden haavoittuvuuden vaikutusalueen koko ympäristössäsi.

Vähemmän ja parempia havaintoja. Reachability- ja hyödynnettävyysanalyysi etsivät näyttöä siitä, että haavoittuvaa koodia todella kutsutaan, joten jonossa on se, millä on merkitystä. AutoFix generoi korjaavia pull requesteja ja validoi ne ennen kuin ne päätyvät repositorioosi.

Tarkistukset pull requestissa. Kusari Inspector katselmoi jokaisen GitHubin tai GitLabin pull requestin transitiivisten haavoittuvuuksien, vuotaneiden salaisuuksien, haitallisten ja typosquatting-pakettien, lisenssiriskien, elinkaarensa päähän tulleiden riippuvuuksien, turvattomien GitHub Actions -työnkulkujen ja yleisten koodin heikkouksien varalta. Kusarin mukaan Inspectorin asentaminen on ilmaista, eikä myyntipuhelua tarvita.

Standardit ja viitekehykset. Kusari tuottaa SBOM:eja ja attestaatioita SPDX-, CycloneDX- ja in-toto-muodoissa ja listaa tuen viitekehyksille, kuten EU:n CRA, FDA 524B, SSDF, IEC 62443 ja DORA. Sen latausohjelma toimii GitHub Actionsissa, GitLab CI/CD:ssä, Jenkinsissä, CircleCI:ssä, Azure DevOpsissa, Bitbucket Pipelinesissa ja TeamCityssä.

Missä CRACI on erilainen

Kusari kuvaa graafinsa rakentuvan lähdekoodista ja build-järjestelmistä ohjelmistoa luotaessa sen sijaan, että se koottaisiin jälkikäteen valmiista binääreistä. Se on oikea vaisto, ja juuri siinä tuotteet myös eroavat. Kusarin SBOM:t tulevat generaattorista: sen dokumentaatio kuvaa niiden generoinnin waybillillä, sen avoimen lähdekoodin SBOM-työkalupakilla, kun pull requestit yhdistetään, tai oman työkalun käytön. Generaattori lukee lukitustiedostoja, manifesteja, välimuisteja ja konttikuvia. CRACI ei lue buildin tiedostoja päätelläkseen, mitä se käytti. Se on kone, jolla buildi ajetaan.

Tallenne, ei jälkikäteinen kokoaminen

Yhden rivin muutoksella runs-on-kohtaan työnkulkusi ajetaan CRACI:lla. Paketit tunnistava välityspalvelin tallentaa, mitä kukin jobi lataa pakettilähteistä, ja CI-välimuisteista palautetut paketit kulkevat mukana. Jokainen SBOM ilmoittaa kattavuutensa jobeittain ja välimuisteittain: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded. Seuranta alkaa siitä, mitä buildi todella haki, ja tietää, missä aukot ovat.

Hallinta buildin aikana

Graafi auttaa löytämään jälkikäteen, mihin ongelma vaikuttaa. Runnerin egress-käytäntö päättää jobin ajon aikana, mihin palvelimiin se saa ottaa yhteyttä. CRACI:n käytännöt ovat oletuksena estäviä tai oletuksena sallivia, ja niissä on 24 sisäänrakennettua ohjelmistolähteiden esiasetusta. Ne validoidaan ennen jobin käynnistymistä ja toimivat fail closed -periaatteella.

Alkuperätiedot ja seuranta samasta tallenteesta

API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot. CRACI ei allekirjoita alkuperätietoja. Se arvioi seurattuja SBOM:eja jatkuvasti uudelleen.

CRACI ei tee sitä, mikä tekee Kusarista erottuvan: se ei ota vastaan muiden skannerien tuloksia, tee reachability-analyysiä eikä katselmoi pull requesteja haitallisten pakettien ja koodin heikkouksien varalta. Se tukee tällä hetkellä vain GitHub Actionsia, ja GitLab CI ja Jenkins ovat tiekartalla.

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

CRACI:n inventaarionäkymä näyttää tarkasti, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa maailmanlaajuisesti. Kun uusi haavoittuvuus ilmenee, näet, missä tuotteissa on haavoittuva versio, eikä sinun tarvitse koota tietoa julkaisutiedotteista ja taulukoista.

Kusarin korvaaminen CRACI:lla

Itse buildaamasi ja toimittamasi ohjelmiston osalta CRACI kattaa sen, mitä varten graafialusta yleensä hankitaan. Se ajaa buildin, tallentaa SBOM:n kattavuus ilmoitettuna, arvioi seurattuja SBOM:eja jatkuvasti uudelleen uusien haavoittuvuuksien julkaisun myötä, kokoaa havainnot buildien ja repositorioiden yli ja antaa tietoturvatiimien tehdä niille triagen (luokittelu ja priorisointi) ja ohjata kunkin korjauksesta vastaavalle tiimille. Egress-käytäntö rajaa jo etukäteen, mihin buildi pääsee, mihin mikään graafi ei pysty.

Ole selvillä siitä, mistä luovut. Kusari yhdistää yhden graafin monen skannerin ja SBOM-lähteen yli, ottaa vastaan VEX:n, tekee reachability-analyysiä ja katselmoi pull requesteja haitallisten pakettien, vuotaneiden salaisuuksien ja koodin heikkouksien varalta. CRACI ei tee mitään näistä tällä hetkellä, ja se tukee tällä hetkellä vain GitHub Actionsia, ja GitLab CI ja Jenkins ovat tiekartalla. Jos monen olemassa olevan työkalun havaintojen yhdistäminen on päätarpeesi, Kusari on edelleen parempi valinta.

Kyberkestävyyssäädöksen näkökulmasta

EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) edellyttää, että valmistajat dokumentoivat tuotteidensa komponentit, myös SBOM:n, ja käsittelevät haavoittuvuuksia niin kauan kuin tuotetta tuetaan. Aktiivisesti hyödynnettyjen haavoittuvuuksien raportointi on voimassa syyskuusta 2026 alkaen. Kusari yhdistää SBOM:t, VEX:n ja havainnot yhteen graafiin, ja se listaa CRA:n tukemiensa viitekehysten joukossa. CRACI tuottaa buildikohtaisen näytön ja seuraa sitä jatkuvasti: mistä kukin julkaisu on buildattu, alkuperätiedot, jatkuva seuranta ja SBOM-vienti CycloneDX- tai SPDX-muodossa. CRACI automatisoi merkittävän osan siitä ohjelmistotoimitusketjun näkyvyydestä ja näytöstä, jota yritykset tarvitsevat laajempaan CRA-vaatimustenmukaisuus- prosessiinsa; kumpikaan työkalu ei yksinään tee tuotteesta vaatimustenmukaista. Lue mitä CRA edellyttää.

Siirtyminen CRACI:iin

Aseta runs-on: craci niihin työnkulkuihin, jotka buildaavat toimittamasi ohjelmiston. CRACI korvaa runnerin, ei GitHub Actionsia, ja ajot näkyvät edelleen GitHubin käyttöliittymässä. Lue lisää buildin aikaisesta SBOM-generoinnista ja haavoittuvuuksien seurannasta.

Punnitsetko useampaa kuin kahta työkalua? Vaihtoehdot Kusarille vertailee yhdeksää vaihtoehtoa rinnakkain.