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
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