Skip to content
BR_

2 min readoutline

Hardening an embedded Linux image with Yocto: a working outline

What a security-oriented Yocto layer needs to cover (secure boot, CVE management across layers, SBOM generation, image signing), as an outline that will grow into a full case study.

This note is an outline: the structure is final, the sections will be filled in over time.
On this page

This note is a stub. It states the scope of a case study at the intersection of hands-on Yocto experience and a cybersecurity thesis, and will be filled in one section at a time.

Scope#

A hardened image is not one setting. It is a set of decisions taken at build time, so that they can be reviewed, repeated and audited:

  1. Secure boot: what is verified at each stage, and where the chain of trust starts.
  2. CVE management across layers: knowing which vulnerabilities apply to which recipe versions, including those pulled in by third-party layers.
  3. SBOM generation: a machine-readable inventory of what is in every image.
  4. Image signing: how a released image is authenticated before it reaches a device.

Build-time inventory#

Recipes and images can emit an SPDX document as part of the normal build. The exact class and its options differ between Yocto releases, so check the documentation of the release you use.

conf/local.conf
# Generate an SPDX SBOM for every recipe and image (class name and options vary by release)
INHERIT += "create-spdx"
 
# Report known CVEs for the recipes that end up in the image
INHERIT += "cve-check"

Vulnerability triage#

A CVE report is only useful when someone decides what to do with each entry. The useful habit is to record that decision next to the recipe, so it survives layer updates:

recipes-example/foo/foo_1.2.bb
SUMMARY = "Example recipe"
# CVE-YYYY-NNNN does not apply: the affected code path is not built (CONFIG_FOO is off).
CVE_STATUS[CVE-YYYY-NNNN] = "not-applicable-config: feature disabled in this build"

Still to write#

  • Where secure boot ends and the kernel's own hardening begins.
  • A workable review process for CVE status changes across layers.
  • Signing keys: generation, storage and rotation for a small team.
  • What an SBOM does and does not prove.