CRACI vs Timesys Vigiles

The short answer

Vigiles is the SBOM and vulnerability management product of Timesys, which Lynx Software Technologies acquired in December 2023; Lynx now sells it as Lynx Vigiles. It is built for embedded Linux: a Yocto layer, meta-timesys, collects metadata about the packages in your image, uploads it, and Vigiles matches it against a curated CVE database, then tracks triage decisions and exports SBOM, VEX and vulnerability reports.

CRACI is a GitHub Actions runner. Your BitBake build runs on it, and while it runs CRACI records every package and source the build fetched, limits where the build can connect and keeps monitoring the SBOM for vulnerabilities. Both products give you an SBOM and CVE monitoring for a Yocto image; they differ in where the SBOM comes from. Vigiles reads what BitBake's metadata says goes into the image. CRACI records what the build actually pulled in.

At a glance

What Vigiles does well

Made for embedded Linux. Vigiles integrates with Yocto through meta-timesys, and with Buildroot, OpenWrt, Timesys Factory and FreeRTOS, and imports SBOMs in SPDX 2.2 to 3.0.1, CycloneDX 1.1 to 1.7 and CSV for everything else. Lynx says Vigiles, launched in 2019, has processed more than 90,000 SBOMs.

Less CVE noise. Vigiles matches components against a curated CVE database rather than raw public data, which Lynx says removes most of the false positives public data produces. Its scanner can upload your full Linux kernel and U-Boot .config files, so CVEs in features you do not build are filtered out. That matters on embedded Linux: in the example report in the meta-timesys README, 60 of the 62 unfixed CVEs are in the kernel.

Decisions that last across releases. Teams record whether each CVE is affected, fixed, deferred or not exploitable, and Vigiles keeps those decisions per release, highlights CISA Known Exploited Vulnerabilities, and exports SBOMs in CycloneDX, SPDX and SPDX Lite along with VEX and vulnerability reports. Its reports also show CVEs already fixed by patches in your build, and patches available in the meta-timesys-security layer. Lynx names the EU CRA and EO 14028 among the standards it helps with, and Vigiles connects to Jira and Okta.

Where CRACI is different

Vigiles's SBOM is only as complete as BitBake's view of the image. The meta-timesys README describes it as collecting metadata about the packages to be installed, and packages built outside BitBake, or built by it but missing from the root filesystem manifest, have to be listed by hand. CRACI does not read metadata. It is the machine the build runs on.

What Yocto's own SBOM leaves out

We have not compared a Vigiles SBOM with CRACI's. We have compared CRACI's with Yocto's built-in SPDX SBOM, which is also generated from BitBake's metadata. In a side-by-side build of core-image-sato on a 32 vCPU ARM64 runner, CRACI's SBOM had every component Yocto's SBOM had, plus 88 it missed: host packages on the build machine such as Ubuntu's cpio, GitHub sources and the GitHub Action actions/upload-artifact, and other sources and tools fetched during the build. None of them is installed in the image, and all of them are in the critical path of the build.

Both SBOMs listed the same 653 Rust crate versions, but Yocto's lists them only by file name and download URL, with no package URL. Vulnerability matching works on package URLs, so those crates cannot be monitored from Yocto's SBOM. CRACI records every one of them with a pkg:cargo package URL.

Control over what the build can reach

An egress policy at the runner decides which hosts a job may connect to. It is validated before the job starts, fails closed, and sends an alert on a violation. For Yocto it adds a second layer to BitBake's own BB_ALLOWED_NETWORKS, and a default-deny policy blocks a compromised build tool from sending secrets to a host the build does not need.

Provenance and monitoring from the same record

The API returns SBOMs, network traces and provenance. CRACI does not sign provenance. CRACI aggregates vulnerabilities across builds and repositories, keeps re-evaluating monitored SBOMs as advisories appear, lets security teams triage findings and route them to the team that owns the fix, and shows which past builds contained a vulnerable dependency, so you know the period you were affected. CRACI supports VEX, and it can submit CRA vulnerability notifications on your behalf.

The build itself, on bigger runners

Vigiles does not run your build; CRACI does. Yocto builds run on runners of up to 32 vCPUs and 96 GB of RAM, metered per second at $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner). In the same core-image-sato comparison, the build without Yocto's SBOM generation took 43% less time than the build with it.

Replacing Vigiles with CRACI

For Yocto images built in GitHub Actions, CRACI covers what Vigiles is bought for: an SBOM for every build, CVE monitoring after release, triage decisions and VEX. It adds what a metadata-based SBOM cannot give you: the host packages, GitHub sources and Actions the build used, and an egress policy while it runs.

Be clear about what you give up. Vigiles's curated CVE data and kernel and U-Boot config filters cut CVE noise in a way CRACI does not. Vigiles reports which CVEs the patches in your build already fix, which CRACI does not record; Yocto's own SPDX carries that recipe metadata too, so keep create-spdx on if you rely on it. Vigiles also covers Buildroot, OpenWrt and FreeRTOS, runs inside any CI, and imports SBOMs in many formats. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap, so Jenkins or GitLab pipelines would need to move to GitHub Actions first.

For the CRA

The Cyber Resilience Act asks manufacturers to document the components in their products, including an SBOM, and to handle vulnerabilities for as long as a product is supported, with reporting obligations from September 2026. Vigiles helps by keeping SBOMs, CVE decisions and reports per release. CRACI produces the per-build evidence of what went into the firmware, with provenance, ongoing monitoring and SBOM export as CycloneDX or SPDX. It automates a significant part of the software supply chain visibility and evidence a manufacturer needs for its wider CRA process; neither tool makes a product compliant on its own. Read what the CRA requires.

Moving a Yocto build to CRACI

Set runs-on: craci on the BitBake job and choose a runner size; the workflow keeps running in GitHub Actions. The Yocto example in the CRACI docs builds core-image-sato on the largest size. See how CRACI works for industrial IoT and consumer electronics.