Yocto Project 6.0 "Wrynose" ships EU Cyber Resilience Act compliance as a build output, not a separate audit track. The sbom-cve-check tool replaces the old cve-check bbclass, SBOM generation now produces SPDX 3.0 with concluded licenses and PURLs, and TLS 1.0/1.1 are off by default. Teams shipping connected embedded products into Europe no longer have to layer a compliance documentation workflow on top of their build workflow. The CRA artifact comes out of bitbake.
The mechanism is straightforward but the implications compound quickly. SBOM generation that runs in CI on every build means the bill of materials is always current, automatically diff-able when a recipe changes, and already in the format regulators expect. Contrast that with the current norm: a manual SBOM capture at the end of a product cycle, frequently wrong because recipes changed after the last audit, requiring a separate team and a separate tool to maintain. Wrynose does not add a compliance feature; it collapses the compliance workflow into the build.
Wrynose is an LTS release, supported until April 2030, with Linux 6.18, GCC 15.2, LLVM 22.1, and Rust 1.94. The four-year LTS window matters for commercial embedded programs where updating a base image is a full engineering and qualification cycle. Teams that adopt Wrynose now lock in the CRA-compliant toolchain for programs that will still be shipping in 2028. Vendors whose compliance tooling sits outside the build system face a harder pitch when the reference platform ships it for free.