123% fler rapporterade CVE:er per dag 2026 än förra året.

Jämförelse

CRACI vs ONEKEY

ONEKEY tittar på firmwaren du levererar. CRACI tittar på bygget som skapade den. För de flesta enhetstillverkare besvarar de två olika frågor, och båda frågorna dyker upp under Cyber Resilience Act.

Uppdaterad

Det korta svaret

ONEKEY är en plattform för produktcybersäkerhet och efterlevnad för uppkopplade enheter. Du laddar upp en firmwareavbild, och plattformen analyserar binären för att hitta komponenter, kända sårbarheter, troliga zero-days och efterlevnadsluckor, utan att källkod behövs. CRACI är en GitHub Actions-runner som registrerar vad varje bygge drar in medan det körs och tar fram SBOM:en från den registreringen. ONEKEY analyserar resultatet; CRACI sparar bevis från bygget. De passar bra ihop, och inget av dem ersätter det andra.

I korthet

Funktion CRACI ONEKEY
Registrerar vad firmwarebygget hämtade Observeras av runnern under varje jobb Analyserar avbilden efter att den har byggts
Kör dina CI-byggen Jobben körs på CRACI-runners Din CI laddar upp firmware till ONEKEY
Analyserar den färdiga binära avbilden Automatiserad analys av binär firmware
Fungerar på firmware du inte har byggt Kräver att bygget körs på CRACI Kräver varken källkod eller nätverksåtkomst
Zero-day-analys av binärer Hittar problem som hårdkodade inloggningsuppgifter
SBOM i CycloneDX och SPDX Från bygget, med fullständighetsstatus Från binären, plus SBOM-import
Egress-policy medan bygget körs Kontrolleras före jobbet, blockerar vid fel Utanför dess område
Bevakning efter release Omvärderar bevakade SBOM:er löpande Analyserar firmware på nytt dagligen
Guidade kontroller mot standarder SBOM-export och API, ingen rapportexport eller guide för standarder Compliance Wizard för CRA, IEC 62443 med flera
CI-system GitHub Actions i dag; GitLab CI och Jenkins på roadmapen Dokumenterade exempel för GitHub, GitLab och Jenkins
  • Ingår
  • Delvis
  • Ingår inte

Vad ONEKEY gör bra

Webbplatsen för ONEKEY
onekey.com

Binäranalys utan källkod. ONEKEY analyserar kompilerad firmware direkt. Dess webbplats säger det rakt ut: "No source code or network access needed." Det spelar roll när mycket av det som levereras på en enhet kommer från kretsleverantörer, modulleverantörer och underleverantörer, och du aldrig ser deras bygge.

Fynd utöver kända CVE:er. Utöver att matcha komponenter mot sårbarhetsdata kör ONEKEY en automatiserad zero-day-analys som letar efter problem som kommandoinjektion, osäker kommunikation och hårdkodade inloggningsuppgifter i binären.

SBOM:er från avbilden. ONEKEY genererar en SBOM från binären, låter dig importera SBOM:er från källkodsskannrar eller leverantörer och exporterar CycloneDX och SPDX.

Vägledning för efterlevnad. ONEKEY Compliance Wizard guidar team genom kraven i Cyber Resilience Act, IEC 62443-4-2, ETSI EN 303 645 och Radio Equipment Directive, och exporterar resultat för certifiering av tredje part.

Bevakning och CI. Dess firmwarebevakning analyserar uppladdad firmware på nytt varje dag när nya sårbarheter dyker upp. ONEKEY:s dokumentation visar hur du laddar upp varje nytt bygge från GitHub, GitLab eller Jenkins och låter pipelinen misslyckas när nya fynd dyker upp. ONEKEY underhåller också unblob, en svit med öppen källkod för extrahering av binära blobbar.

Där CRACI skiljer sig

En binärskanning arbetar bakåt från den färdiga avbilden. CRACI arbetar framåt från bygget, eftersom det är maskinen som bygget körs på.

Bygget är sanningskällan

Ditt firmwarearbetsflöde körs på CRACI:s runners med en ändring på en rad i runs-on. Medan ett jobb körs registrerar en paketmedveten proxy vad det laddar ner från paketkällor, och paket som återställs från CI-cachar följer med. Varje SBOM anger hur komplett den är, per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. För Yocto kör CRACI BitBake på runners med upp till 32 vCPU och 96 GB RAM. I ett bygge av core-image-sato sida vid sida hade CRACI:s SBOM varje komponent i Yoctos egen SPDX-utdata, 88 till, som värdsystemets paket och GitHub Actions, och en paket-URL för var och en av de 653 versioner av Rust-crates som Yocto listar utan någon. Källor som BitBake hämtar från Yoctos källspegel registreras i CRACI:s jobb-SBOM.

Kontroll över vad bygget kan nå

En egress-policy på runnern avgör vilka värdar ett jobb får ansluta till. Den valideras innan jobbet startar, blockerar vid fel och skickar en varning vid en överträdelse. För Yocto lägger den till ett andra lager ovanpå BitBakes egen BB_ALLOWED_NETWORKS.

Proveniens och vad som levererades

API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI signerar inte proveniens. Det sammanställer sårbarheter över byggen och repon och fortsätter att omvärdera bevakade SBOM:er när nya säkerhetsmeddelanden dyker upp.

Vad CRACI inte gör är lika viktigt här. Det analyserar inte binärer, så det kan inte säga vad som finns inuti en leverantörsblob som ditt bygge laddar ner, bara att bygget hämtade den och varifrån.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp ser du vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

När du ska använda vilket, och när du ska använda båda

  • Du integrerar firmware du inte bygger. ONEKEY. Binäranalys är sättet att se inuti den.
  • Du bygger din egen Linux-avbild i GitHub Actions. CRACI kör bygget och registrerar det som går in i det. Med ONEKEY får du dessutom en andra, oberoende bild av den färdiga avbilden.
  • En revisor frågar hur du vet att SBOM:en stämmer med produkten. CRACI:s registrering från runnern svarar på "vad gick in i det här bygget"; ONEKEY:s analys svarar på "vad finns i den här avbilden". Tillsammans kontrollerar de varandra.
  • Du behöver guidade kontroller mot IEC 62443 eller ETSI EN 303 645. ONEKEY har det inbyggt. CRACI exporterar SBOM:er som CycloneDX eller SPDX, och dess API returnerar nätverksspårningar och proveniens, för ditt bredare arbete.

För CRA

Cyber Resilience Act kräver att tillverkare identifierar och dokumenterar komponenterna i sina produkter, bland annat med en SBOM, och hanterar sårbarheter så länge produkten får support. Rapportering av aktivt utnyttjade sårbarheter gäller från september 2026. ONEKEY hjälper till genom att analysera firmwaren du släpper ut på marknaden och guida dig genom kraven. CRACI hjälper genom att ta fram bevis per bygge om vad som ingick i den firmwaren, med proveniens och löpande bevakning. CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som tillverkare behöver för sitt bredare arbete med CRA-efterlevnad; det gör inte en produkt regelefterlevande på egen hand. Läs vad CRA kräver.

Lägg till CRACI bredvid ONEKEY

Behåll ditt uppladdningssteg till ONEKEY. Flytta firmwarejobbet till en CRACI-runner genom att sätta runs-on: craci, så fortsätter samma arbetsflöde att köras i GitHub Actions medan CRACI registrerar bygget. Uppladdningen till ONEKEY sker då från ett bygge du har bevis för. Yocto-exemplet i CRACI:s dokumentation visar ett komplett BitBake-arbetsflöde. CRACI har i dag stöd för enbart GitHub Actions, så pipelines i GitLab eller Jenkins skulle behöva flyttas för att använda CRACI-runners. GitLab CI och Jenkins finns på roadmapen. Se hur CRACI fungerar för industriell IoT och hemelektronik.

Väger du fler än två verktyg? Alternativ till ONEKEY jämför nio alternativ sida vid sida.

Ta med ett firmwarebygge till demon

Boka en demo så kör vi ett av dina firmwarebyggen i GitHub Actions på CRACI och går igenom vad det hämtade.

Boka en demo