Every smart device ships firmware built from open source packages, chip vendor SDKs and tools fetched during the build. A supply chain attack needs only one of them. CRACI runs your firmware builds, records every component that goes in, and keeps the build from reaching anything it does not need.
Most of the code in a connected device was written by someone else: an embedded Linux distribution, the board support package from the chip vendor, a network stack, a few hundred open source libraries and the Rust crates under them. The same components ship in products from many brands, and the devices stay in homes for years, often long after anyone last looked at what they contain.
That makes one weak component worth a lot to an attacker. A flaw in a shared library or SDK opens every product that ships it, and a poisoned release reaches every build that pulls it in. These incidents show the pattern.
Nineteen vulnerabilities, up to CVSS 10.0, in a small TCP/IP library that device makers had licensed for years, often under another name. It sat inside products from many vendors, and many of them first had to work out whether they shipped it at all.
You cannot patch a component you do not know you ship.
Flaws in a chip vendor's SDK reached about 200 device models from some 65 manufacturers: routers, IP cameras, smart lighting gateways, connected toys. A Mirai botnet was scanning for them two days after the details went public.
The chip vendor's code is your code once it ships in your device.
A backdoor was planted in the upstream xz project itself, in versions 5.6.0 and 5.6.1. Embedded Linux images pull in compression libraries like xz as a matter of course, usually without anyone choosing them.
Trusted open source can turn hostile in a single release.
Attackers used ASUS's own signing certificates to sign a backdoored version of its update utility and delivered it from the official update servers. Kaspersky estimated it may have reached more than a million users.
A valid signature only proves who signed, not what went in.
Device hardening, such as secure boot, no default passwords and a closed debug port, protects the device you ship. The steps below protect what goes into it.
CRACI covers the build side of this list: the SBOM of every build, supplier SBOMs, continuous monitoring, build isolation, egress control and policy gates. Signing and device hardening stay with your own tools.
Run your Yocto and other embedded Linux builds on CRACI's GitHub Actions runners, up to 32 vCPUs, on x86-64 or native ARM64. While the build runs, CRACI records every package and file it pulls in, including host packages, Git sources, GitHub Actions and downloads that no recipe or lockfile lists. In a core-image-sato build, CRACI's SBOM had every component in Yocto's own SBOM plus 88 it missed, with a package URL for each of the 653 Rust crate versions, so all of them can be monitored for vulnerabilities.
Each job runs in its own isolated virtual machine under an egress policy that is validated before the job starts and fails closed. With a default-deny policy, the build reaches your package sources and nothing else. A compromised dependency that tries to send your signing material or tokens to an attacker's host is blocked and raises an alert, even when the attack is new and nobody has published an advisory for it yet.
Add SBOMs from your chip vendors and other suppliers, and the bought-in components are monitored alongside the software you build. When the next SDK vulnerability lands, the vendor's code is in the same record as yours.
CRACI keeps re-evaluating monitored SBOMs as new vulnerabilities are published. Build history shows which builds contained the vulnerable dependency, direct or transitive, and the inventory view shows which software versions are deployed to which products. Security teams triage each finding and route it to the team that owns the fix, and a policy gate can keep a specific CVE out of every later build.
CE marking under the Cyber Resilience Act rests on technical documentation and a conformity assessment. CRACI supplies the supply chain evidence that documentation needs: build-time SBOMs exported as CycloneDX or SPDX, vulnerability records and build history. CRACI also submits the CRA vulnerability notifications on your behalf. The conformity assessment, the EU declaration of conformity and the CE marking stay with you, the manufacturer.
CRACI does not sign firmware, SBOMs or provenance, and it does not detect new malicious packages by behavior or reputation: it flags a malicious release once an advisory with a CVE exists, and relies on the egress policy until then. It does not run your conformity assessment or draw up your declaration of conformity. It runs GitHub Actions jobs on Linux runners today; GitLab CI, Jenkins, and Windows and macOS runners are on the roadmap.
Common questions about securing connected devices and their software supply chain
It is an attack that reaches a device through something its maker relies on rather than through the device itself: a vulnerable open source library, a chip vendor's SDK, a poisoned package release, a compromised build tool or a hijacked update channel. Because the same component ships in many products, one weakness can reach millions of devices from many brands at once.
Start with what you ship: keep an SBOM for every firmware build, track supplier components, and keep checking shipped versions as new vulnerabilities appear. Lock down the build itself, keep known-bad versions out with policy gates, protect your signing keys, and have a process for triage, fixes and disclosure. Device hardening such as secure boot and disabling default passwords matters too, but it does not help if the firmware already carries a vulnerable component.
Know every component that goes into the image, including what the build fetches outside your recipes and lockfiles, and keep that record per release. Build in an isolated environment that can reach only the sources it needs, so a malicious dependency cannot send your secrets anywhere. Monitor the recorded components and your suppliers' SBOMs against new vulnerabilities for as long as the devices are supported.
Yes. Yocto and BitBake builds run on CRACI runners, and CRACI records the job's SBOM while the build runs. Yocto's own SPDX output still carries recipe metadata that CRACI does not record, such as the patches applied and the CVEs a recipe marks as fixed, so keep create-spdx on if you rely on those.
Yes, when you have an SBOM for them. You can add vendor SBOMs to CRACI, and those components are monitored alongside the software you build. Anything your build downloads from a vendor during the build is recorded in the job's SBOM as well.
Not by behavior or reputation. A known malicious release that has a published CVE, such as the xz backdoor, is flagged like any other vulnerability, and a policy gate can block builds that contain it. Against new attacks, CRACI's protection is the default-deny egress policy, which blocks the build from reaching hosts it does not need.
No. CRACI does not sign firmware, SBOMs or provenance. Keep using your own signing process and hardware-backed key storage for releases and updates.
The Cyber Resilience Act covers products with digital elements placed on the EU market, which includes most connected consumer devices. Reporting obligations apply from 11 September 2026 and the regulation applies in full from 11 December 2027. CRACI automates a significant part of the supply chain visibility and evidence the CRA process needs; meeting the regulation stays the manufacturer's process.
CRACI runs GitHub Actions jobs on Linux runners, x86-64 and ARM64, from 1 to 32 vCPUs. Other CI systems, such as GitLab CI and Jenkins, are on the roadmap, as are Windows and macOS runners.
Book a demo and we will show every component your device builds pull in, and which of them are vulnerable
Book a demo