CRACI vs. Finite State

Det korte svaret

Finite State er en plattform for produktsikkerhet for tilkoblede enheter. Den analyserer firmware, binærfiler, kildekode og SBOM-er fra leverandører, prioriterer sårbarheter etter reachability og gjør resultatene om til dokumentasjon for regelverk som CRA. CRACI er en GitHub Actions-runner som registrerer hva hvert bygg henter inn mens det kjører, produserer SBOM-en fra den registreringen og kontrollerer hvor bygget kan koble seg til. Finite State analyserer det du leverer, uansett hvor det kom fra; CRACI registrerer hva ditt eget bygg gjorde. De utfyller stort sett hverandre.

Oversikt

Hva Finite State gjør bra

Dekning av binærfiler og firmware. Finite State produserer SBOM-er og et programvareinventar på tvers av firmware, binærfiler og kildekode, "with support for 50+ binary instruction set architectures." For en enhet som kjører kode fra mange leverandører på uvanlige brikker, er det nettopp bredden som er poenget.

Én registrering på tvers av leverandører. Det samler firmware, binærfiler, kildekode, SBOM-er fra leverandører og tredjepartsfunn på én plattform, noe som hjelper når du må avstemme det en leverandør sier, mot det som faktisk er i produktet.

Mindre støy. Finite State rangerer funn etter reachability, utnyttelsesinformasjon og produktkontekst. Det rapporterer at siden 2024 ble 40,5 % av funnene det analyserte for reachability, bekreftet som ikke nåbare. Det registrerer VEX-beslutninger med produktpåvirkning og status for utnyttbarhet.

Samsvarsdokumentasjon. Samsvarsflyten dekker kartlegging av EU CRA-kontroller og vedlikehold av dokumentasjon, og genererer revisjonsklare rapporter med SBOM- og VEX-artefakter. Den tar også for seg rammeverk som FDA-veiledning, UN R155 og IEC 62443.

CI-integrasjoner. Finite State bygger inn sjekker i GitHub Actions, GitLab CI og Jenkins. Binary Scan-actionen laster opp en binærfil bygget under CI til Finite State-plattformen for en rask eller full skanning.

Der CRACI skiller seg ut

Finite State starter fra artefakter: den ferdige binærfilen, kildetreet, SBOM-en en leverandør sendte. CRACI starter fra selve bygget, fordi bygget kjører på CRACI.

Observert, ikke utledet

Du endrer runs-on til craci, og jobben kjører i en isolert virtuell maskin på en CRACI-runner. En pakkebevisst proxy registrerer hva jobben laster ned fra pakkekilder, og pakker gjenopprettet fra CI-cacher blir ført videre. Hver SBOM angir hvor fullstendig den er, per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Firmware-team kan kjøre Yocto på runnere med opptil 32 vCPU-er og 96 GB RAM. Kilder BitBake henter fra Yocto-kildespeilet, blir registrert i CRACI-jobbens SBOM.

Kontroll under bygget

En skanning av resultatet kan ikke endre hva bygget kunne nå. Det kan CRACIs egress-policy: Den er default deny eller allow, valideres før jobben starter, blokkerer ved feil (fail closed) og sender et varsel ved brudd.

Provenance og overvåking

API-et returnerer SBOM-er, nettverksspor og provenance. CRACI samler sårbarheter på tvers av bygg og repositorier og fortsetter å vurdere overvåkede SBOM-er på nytt når advisories dukker opp.

CRACI analyserer ikke binærfiler og utfører ikke reachability-analyse. Byggeregistreringen dekker bygg som kjører på det, og du kan legge til SBOM-er leverandørene dine leverer. For leverandørfirmware du mottar som en binærfil uten SBOM, dekker Finite State et område CRACI ikke dekker.

En oversikt over hva som er rullet ut hvor

Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Når en ny sårbarhet dukker opp, kan du se hvilke produkter som kjører den berørte versjonen, i stedet for å pusle det sammen fra utgivelsesnotater og regneark.

Når du bør bruke hvilken, og når du bør bruke begge

• Mesteparten av firmwaren din kommer fra leverandører. Finite State. Binæranalyse og inntak av SBOM-er fra leverandører er bygget for det.
• Du bygger egne images og apper i GitHub Actions. CRACI registrerer hvert bygg. Last opp den samme artefakten til Finite State, så har du byggeregistreringen og binæranalysen side om side.
• Du trenger et registreringssystem for mange produkter og leverandører. Finite State. CRACIs SBOM-er eksporteres som CycloneDX eller SPDX, formater Finite State godtar gjennom opplastings-actionen sin.
• Du vil begrense hva bygg kan laste ned. CRACI. Den kontrollen finnes bare der bygget kjører.

For CRA

Cyber Resilience Act ber produsenter identifisere og dokumentere komponentene i produktene sine, inkludert en SBOM, håndtere sårbarheter gjennom støtteperioden og, fra september 2026, rapportere aktivt utnyttede sårbarheter. Finite State hjelper med å sette sammen denne dokumentasjonen på tvers av et produkt og leverandørene, med CRA-kontrollkartlegging og rapporter. CRACI hjelper ved å produsere dokumentasjon per bygg av hva som gikk inn i programvaren du bygger, med provenance, løpende overvåking og SBOM-eksport som CycloneDX eller SPDX. CRACI automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen som produsenter trenger for sin bredere CRA-samsvarsprosess; det gjør ikke et produkt samsvarende på egen hånd. Les hva CRA krever.

Slik legger du CRACI til ved siden av Finite State

Ingenting må flyttes ut av Finite State. Pek byggejobben mot runs-on: craci, behold opplastingssteget til Finite State, og den samme workflowen kjører på en CRACI-runner mens CRACI registrerer den. For Yocto viser eksempelet i CRACI-dokumentasjonen en fullstendig BitBake-workflow. CRACI støtter bare GitHub Actions i dag, så pipelines i GitLab CI eller Jenkins må flyttes for å bruke CRACI-runnere. GitLab CI og Jenkins står på veikartet. Se hvordan CRACI fungerer for industriell IoT og forbrukerelektronikk.

Vurderer du flere enn to verktøy? Finite State-alternativer sammenligner ni alternativer side om side.