CRACI vs Finite State

Det korte svar

Finite State er en produktsikkerhedsplatform til forbundne enheder. Den analyserer firmware, binærfiler, kildekode og leverandørers SBOM'er, prioriterer sårbarheder efter reachability og omsætter resultaterne til dokumentation til reguleringer som CRA. CRACI er en GitHub Actions-runner, der registrerer, hvad hvert build trækker ind, mens det kører, producerer SBOM'en ud fra den registrering og styrer, hvad buildet kan forbinde sig til. Finite State analyserer det, du leverer, uanset hvor det kom fra; CRACI registrerer, hvad dit eget build gjorde. De supplerer for det meste hinanden.

Overblik

Hvad Finite State gør godt

Dækning af binærfiler og firmware. Finite State producerer SBOM'er og et softwareinventar på tværs af firmware, binærfiler og kildekode, "with support for 50+ binary instruction set architectures." For en enhed, der kører kode fra mange leverandører på usædvanlige chips, er den bredde pointen.

Én registrering på tværs af leverandører. Det samler firmware, binærfiler, kildekode, leverandørers SBOM'er og fund fra tredjeparter på én platform, hvilket hjælper, når du skal afstemme, hvad en leverandør siger, med hvad der faktisk er i produktet.

Mindre støj. Finite State rangerer fund efter reachability, exploit intelligence og produktkontekst. Det rapporterer, at 40,5 % af de fund, det har analyseret for reachability siden 2024, er bekræftet som ikke-nåbare. Det registrerer VEX-beslutninger med produktpåvirkning og status for udnyttelighed.

Compliance-dokumentation. Dets compliance-workflow dækker kontrolkortlægning til EU's CRA og vedligeholdelse af dokumentation og genererer auditklare rapporter med SBOM- og VEX-artefakter. Det dækker også rammeværker som FDA-vejledning, UN R155 og IEC 62443.

CI-integrationer. Finite State indlejrer kontroller i GitHub Actions, GitLab CI og Jenkins. Dets Binary Scan-action uploader en binærfil bygget under CI til Finite State-platformen til en hurtig eller fuld scanning.

Hvor CRACI er anderledes

Finite State starter fra artefakter: den færdige binærfil, kildetræet, den SBOM, en leverandør har sendt. CRACI starter fra selve buildet, fordi buildet kører på CRACI.

Observeret, ikke udledt

Du ændrer runs-on til craci, og jobbet kører i en isoleret virtuel maskine på en CRACI-runner. En pakkebevidst proxy registrerer, hvad jobbet downloader fra pakkekilder, og pakker gendannet fra CI-caches føres videre. Hver SBOM angiver, hvor komplet den er, pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Firmwareteams kan køre Yocto på runnere med op til 32 vCPU og 96 GB RAM. Kilder, BitBake henter fra Yocto-kildespejlet, registreres i CRACI's job-SBOM.

Kontrol under buildet

En scanning af outputtet kan ikke ændre, hvad buildet kunne nå. Det kan CRACI's egress-politik: Den er default deny eller allow, valideres før jobbet starter, blokerer ved fejl (fail closed) og sender en advarsel ved en overtrædelse.

Provenance og overvågning

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI samler sårbarheder på tværs af builds og repositories og genvurderer løbende overvågede SBOM'er, efterhånden som advisories dukker op.

CRACI analyserer ikke binærfiler og laver ikke reachability-analyse. Dets build-registrering dækker builds, der kører på det, og du kan tilføje SBOM'er, som dine leverandører leverer. For leverandørfirmware, du modtager som en binærfil uden en SBOM, dækker Finite State områder, som CRACI ikke gør.

Et inventar over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Hvornår du skal bruge hvilken, og hvornår du skal bruge begge

• Det meste af din firmware kommer fra leverandører. Finite State. Binæranalyse og indlæsning af leverandørers SBOM'er er bygget til det.
• Du bygger dine egne images og apps i GitHub Actions. CRACI registrerer hvert build. Upload det samme artefakt til Finite State, så har du build-registreringen og binæranalysen side om side.
• Du har brug for et system of record for mange produkter og leverandører. Finite State. CRACI's SBOM'er eksporteres som CycloneDX eller SPDX, formater, Finite State accepterer gennem sin upload-action.
• Du vil begrænse, hvad builds kan downloade. CRACI. Den kontrol findes kun dér, hvor buildet kører.

Til CRA

Cyber Resilience Act kræver, at producenter identificerer og dokumenterer komponenterne i deres produkter, herunder med en SBOM, håndterer sårbarheder gennem supportperioden og fra september 2026 rapporterer aktivt udnyttede sårbarheder. Finite State hjælper med at samle den dokumentation på tværs af et produkt og dets leverandører, med CRA-kontrolkortlægning og rapporter. CRACI hjælper ved at producere dokumentation pr. build for, hvad der gik ind i den software, du bygger, med provenance, løbende overvågning og SBOM-eksport som CycloneDX eller SPDX. CRACI automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som producenter har brug for i deres bredere CRA-compliance-proces; det gør ikke et produkt compliant alene. Læs hvad CRA kræver.

Tilføj CRACI ved siden af Finite State

Intet behøver at flyttes væk fra Finite State. Peg dit build-job mod runs-on: craci, behold upload-trinnet til Finite State, så kører det samme workflow på en CRACI-runner, mens CRACI registrerer det. Til Yocto viser eksemplet i CRACI's dokumentation et komplet BitBake-workflow. CRACI understøtter kun GitHub Actions i dag, så GitLab CI- eller Jenkins-pipelines skal flyttes for at bruge CRACI-runnere. GitLab CI og Jenkins er på roadmappen. Se, hvordan CRACI fungerer til industriel IoT og forbrugerelektronik.

Overvejer du mere end to værktøjer? Alternativer til Finite State sammenligner ni muligheder side om side.