Yocto Security & CRA Compliance Checklist

The EU Cyber Resilience Act treats an unpatched embedded Linux image as a defect in the product, not a detail of the build. This checklist is what to verify in a Yocto build before it ships.

It assumes you already have a build that boots. Nothing here is about getting Yocto working — it is about the gap between "the image boots" and "the image is defensible."

Work through it once per release candidate, not once per project. The answers change every time a layer moves.

1. Bill of materials

• create-spdx (or create-spdx-2.2) is in INHERIT, and the SPDX output lands in tmp/deploy/spdx/ on every image build
• The SBOM is archived as a release artefact alongside the image, not left in tmp/
• Every recipe in the image resolves to a real LICENSE field — no CLOSED placeholders on third-party code
• INCOMPATIBLE_LICENSE is set for the licences your legal position forbids, so a GPL-3.0 recipe fails the build rather than shipping
• The SBOM lists the kernel and bootloader, not only userspace packages

2. Known vulnerabilities

• cve-check is in INHERIT and the build emits a CVE report per image
• The CVE database is refreshed in CI rather than reused from a stale download cache (DL_DIR/CVE_CHECK)
• Every unpatched CVE above your severity threshold has a written disposition: patched, not applicable, or accepted with a reason
• CVE_STATUS entries carry a justification string, so an ignored CVE explains itself to an auditor
• A CVE report regression fails the pipeline instead of being reviewed by hand

3. Attack surface

• The image is built from a minimal base, not core-image-full-cmdline or a vendor demo image
• IMAGE_FEATURES contains no debug-tweaks, tools-debug, dbg-pkgs, or empty-root-password in production
• The serial console is disabled, or gated behind authentication, in production images
• No development SSH keys, .netrc, build-host paths, or CI tokens survive into the rootfs
• The package list has been read end to end at least once — every package is there because something needs it

4. Kernel and boot

• The kernel defconfig is under version control in your own layer, not inherited unseen from the BSP
• Secure boot is enabled and the chain terminates in a key you control, not a vendor test key
• The kernel and bootloader track a maintained upstream branch with a known patch cadence, and the recipe pins SRCREV to a specific commit on it
• PREEMPT_RT is applied only where a control loop needs it, and the resulting latency has been measured rather than assumed
• Boot time is measured on the production image, so a regression shows up before a customer finds it

5. Root filesystem integrity

• The root filesystem is read-only, with writable state confined to a named overlay or data partition
• dm-verity or an equivalent protects the root filesystem from offline modification
• Persistent secrets live in encrypted storage (LUKS, or the SoC's secure element), never in the image
• Log and cache directories are on a volume that can fill up without bricking the device

6. Updates in the field

• An A/B or dual-bank update mechanism is in place — RAUC, Mender, or swupdate — with a proven rollback
• Update artefacts are signed, and the device verifies the signature before applying
• Rollback has been exercised on real hardware, including a power cut mid-write
• There is a documented path from "CVE published" to "fleet updated," with an owner and a target window
• The device reports its running image version somewhere you can query across the fleet

7. Reproducibility

• Every layer is pinned to a commit SHA in the manifest, not to a branch name
• A clean build from a fresh sstate cache produces the same image the release did
• The build runs in a container with a pinned base, so the host toolchain is not part of the result
• The exact build inputs — manifest, local.conf, layer SHAs — are archived with the release artefact

Where this usually goes wrong

Three items on this list account for most of the failures we see.

cve-check enabled but never read. The report generates, nobody owns it, and the count climbs release over release. A report without a disposition step is decoration.

Layers pinned to branches. The build is reproducible until the day it is not, and the day it is not is usually the day you need to rebuild a shipped release to patch it.

Rollback never tested. Signed updates and A/B partitions are straightforward to configure and easy to get subtly wrong. The first real test should not be a field failure.

When this needs outside help

Most teams can work through this list themselves. It is worth bringing in help when the answers are expensive rather than unknown:

• The BSP is a vendor drop with no upstream, so pinning and patching mean taking on maintenance of a kernel fork
• You need a CRA conformity argument, not just a clean CVE report, and someone has to write the technical documentation an assessor will read
• Boot time or latency targets are not being met and the fix requires kernel and device-tree work rather than configuration

If any of those describe where you are, we do this work: contact@mnpsystems.ca.