Learning embedded security in the agentic AI era

A computer built into a product to do one job: a router, a camera, a factory controller, a robot. It has a processor, memory, storage, interfaces, and software burned in at the factory, and it typically runs unattended for years.

SoC

System on a chip: a processor with memory controllers, radios and crypto engines on one die. Powerful enough to run Linux. Example families: NXP i.MX, MediaTek Genio, Qualcomm, Raspberry Pi's Broadcom chips.

MCU

Microcontroller: a small processor with flash and RAM on the chip, kilobytes to a few megabytes. Runs bare-metal code or a real-time operating system (RTOS) such as Zephyr or FreeRTOS. No Linux.

Flash

Non-volatile storage. An external SPI flash chip on simpler boards, eMMC or NAND on richer ones. It holds the firmware, so whoever reads it reads the product.

Silicon vendor · board vendor · OEM

The chip maker (NXP, MediaTek) · the board or module maker (SECO, Kontron, Toradex) · the company whose name is on the finished product. Each adds software; the OEM is legally the manufacturer (Module 6).

Why security is different here

Devices live 5 to 15 years, cannot be rebooted at will, have little CPU and memory for security agents, are physically reachable by attackers, and when they fail the consequence can be physical.

Where Exein's two products sit on this picture. Analyzer examines the software stored in the flash chip (the firmware, defined in the next lesson) before the device ships. Runtime is a small program that runs on the processor while the device is in use and watches what it does. Both send what they find to a web service that sees every device of that model (the fleet, lesson 0.5). Click either name to jump to its lesson.

A stack of software images flashed as one: bootloader, Linux kernel, root filesystem with its libraries and services, your application. A build system such as Yocto or Buildroot assembles it from hundreds of open-source packages plus vendor code.

Kernel

The core of the operating system: talks to hardware through drivers (some built in, some as loadable kernel modules), runs programs, enforces permissions. A system call (syscall) is how a program asks the kernel for something: open a file, send a packet.

Userspace / userland

Everything that is not the kernel: libraries, services (daemons), your app. On most devices the shell and the basic Unix commands come from BusyBox, one small binary that plays all of them. Most vulnerabilities you will triage live here or in the kernel.

Build system

Yocto: layers of recipes, one recipe per package, produces a custom distribution; the standard for products that need long maintenance. Buildroot: simpler, builds a whole image from a menu, no package manager on the device. Both download sources, apply patches, cross-compile, and emit the images.

BSP

Board support package: the kernel, bootloader and drivers a silicon or board vendor provides for its hardware, often a Yocto layer. Often "years behind upstream", which matters for Module 3.

LTS · upstream · backport

Long-term support branches of the kernel, Yocto or Buildroot receive fixes for years. Upstream is the original project; a backport is a fix copied from the newest version to an older supported one.

Cross-compile

Build on a PC for a different processor (Arm, MIPS, RISC-V). Why analysing binaries from devices needs tools that understand many instruction sets.

Boot ROM · bootloader · device tree

The boot ROM is code fixed inside the chip by the silicon vendor; it runs first and loads the bootloader (usually U-Boot), which loads the kernel. The device tree is a data file that tells the kernel which hardware is on this board. None of them hold the libraries you will triage.

A bug is a mistake in code. A weakness is a type of mistake (CWE). A vulnerability is a specific bug an attacker could use (CVE). An exploit is code or a method that uses it. A patch removes it; a mitigation makes it harder or less damaging without removing it.

CWE

Common Weakness Enumeration: the catalogue of mistake types. CWE-787 out-of-bounds write, CWE-78 command injection, CWE-798 hard-coded credentials.

CVE

Common Vulnerabilities and Exposures: one identifier per publicly known vulnerability, like CVE-2021-44228. Module 2 explains who issues them.

Proof of concept (PoC)

Code that demonstrates a vulnerability can be triggered. Not the same as attackers using it (Module 2, KEV).

Zero-day

A vulnerability exploited before a fix exists.

Memory safety

The class behind most device CVEs: C code reading or writing outside the memory it owns (buffer overflow, use-after-free). The attacker turns that into running their code.

Remote code execution (RCE)

The attacker runs their own code on the device over the network. The worst common outcome. "Unauthenticated RCE" means no password was needed.

Denial of service (DoS)

The device stops working: a crash, a reboot, a flood of traffic (DDoS when many machines send it).

Privilege

What a program may do. Root may do anything. Least privilege gives each program the minimum.

Vulnerability management

The loop: know what you ship, learn which known vulnerabilities touch it, decide which matter, fix or mitigate, ship the update, prove it. The whole course, in one sentence.

Four ideas: a hash fingerprints data; a signature proves who produced it and that it was not changed; encryption hides it; a key is the secret that makes the last two work, and where the key lives decides everything.

Hash

A fixed-size fingerprint (SHA-256) of any data. Change one bit, the hash changes completely. Cannot be reversed. Used to verify integrity and to identify files in SBOMs.

Digital signature

A hash encrypted with a private key (RSA, ECDSA, EdDSA). Anyone with the matching public key can verify it; only the private key holder could have made it. Authenticity plus integrity.

Public / private key

A pair. Private signs or decrypts and must stay secret; public verifies or encrypts and can be published. A certificate (X.509) binds a public key to an identity; a PKI is the system that issues and revokes certificates.

Symmetric encryption

One key encrypts and decrypts (AES). Fast; used for storage (dm-crypt) and traffic (TLS after the handshake). Keeps data confidential; does not prove who wrote it.

TLS

The protocol behind https: certificates to authenticate, then symmetric encryption. Devices must verify the server certificate, or the update channel is open to interception.

Where keys live

In software (weak), in a TPM or the SoC's secure enclave, in a secure element or HSM that uses the key without revealing it, in a TEE (trusted execution environment, Arm TrustZone with OP-TEE) isolated from Linux.

One-time-programmable (OTP) fuses

Bits in the chip that can be set once. The public key hash goes here so nobody can swap the key.

Thousands of identical devices in the field, updated over the air, increasingly running applications in containers, reporting to a cloud dashboard through an agent. Security products attach to each of those points.

OTA

Over-the-air update: new firmware delivered over the network and installed without a technician. Module 5 shows how it is done safely.

Fleet

All deployed units of a product, across versions and customers. Fleet management: knowing which device runs which firmware, pushing updates in rings, collecting health and security events.

Container

A packaged application with its own libraries, isolated from the rest of the system by kernel features (namespaces, cgroups, seccomp). Docker and Podman on devices, often orchestrated by lightweight Kubernetes (k3s) or vendor platforms (balena). A container image carries its own packages and therefore its own CVEs.

Agent

A small program on the device that reports to a platform and enforces policy. On servers it is called EDR; on devices it must be tiny, and today it is built on eBPF (Module 5).

Runtime

While the device is operating, as opposed to build time. "Runtime protection" means detecting and stopping attacks on the live device.

CI/CD

Continuous integration and delivery: the automated pipeline that builds, tests, scans and releases every change. Security tools that live here run on every build.

SBOM

Software bill of materials: the list of every package and version inside an image, produced by the build. Scanners compare it with CVE databases; Module 4 is about it.

Incident

A security event that did or could cause harm: a device executing unknown code, exfiltrating data, being bricked. Triage decides what happened, how bad, what to do; the CRA puts a clock on severe ones.

The OWASP IoT Top 10 (2018): one list of "the top ten things to avoid when building, deploying, or managing IoT systems", chosen for the issues that "caused the most actual impact and damage". OWASP

I1 Weak or hardcoded passwords

Easily brute-forced, public or unchangeable credentials, including firmware backdoors.

I2 Insecure network services

Unneeded or insecure services on the device, especially internet-exposed.

I3 Insecure ecosystem interfaces

Web, API, cloud or mobile interfaces outside the device with weak authentication, encryption or filtering.

I4 No secure update

No firmware validation, unencrypted delivery, no anti-rollback, no notification.

I5 Insecure or outdated components

Deprecated libraries, insecure OS customisation, compromised supply chain.

I6 Insufficient privacy protection

Personal data used insecurely or without permission.

I7 Insecure data transfer and storage

No encryption or access control at rest, in transit or in processing.

I8 No device management

No asset or update management, monitoring, decommissioning or response.

I9 Insecure default settings

Shipped insecure, or impossible to harden.

I10 No physical hardening

Physical access yields information "that can help in a future remote attack" or local control.

A shell, a memory dump or a full firmware copy, with under about twenty dollars of equipment, through interfaces that exist for developers: the UART serial console, the JTAG debug port and the SPI flash chip itself. Explore the board: click a part.

UART

Universal asynchronous receiver-transmitter: the serial port of the board, exposed as three pins or pads (TX, RX, ground). Connect a five-dollar USB-serial adapter and a terminal shows the boot log, a chance to interrupt the bootloader, and on an unhardened device a root shell with no password. The first thing an attacker looks for; OWASP I10.

JTAG / SWD

Joint Test Action Group and Serial Wire Debug: hardware debug ports that let a probe halt the processor, read and write memory and flash, and step through code. Meant for bring-up; left enabled they hand over live memory including decrypted keys. A probe costs ten to a few hundred dollars.

SPI flash dump

Clip a programmer such as the CH341A (about five dollars) onto the flash chip, or desolder it, and copy the whole firmware in minutes. The image then goes to the analysis of lesson 1.3.

Side channels

Power or electromagnetic measurement while a chip computes recovers keys. Colin O'Flynn's ChipWhisperer made it teachable with open hardware. channel

Fault injection

A nanosecond voltage or clock glitch skips a check. Joe Grand recovered about two million dollars from a Trezor One this way; Thomas Roth jailbroke an AirTag with a four-dollar Pico. Joe Grand stacksmashing

Controls, in order: disable or authenticate debug (fuses, readout protection); encrypt and sign the image, no secrets inside; harden binaries (stack protection, ASLR); design the boot chain assuming glitches (redundant checks, certified silicon). Hardware Hacking Handbook, ch. 14

With the OWASP Firmware Security Testing Methodology: nine stages from reconnaissance to exploitation. Each stage names the control that would stop it. OWASP FSTM

A product such as Exein Analyzer automates stages 3 to 5 on an uploaded image; a researcher runs all nine. Learn the stage names and each defender's answer; the tool names are for recognition only.

binwalk · file · strings · QEMU

The analyst's first tools. file and strings show what an image is and the text inside it; binwalk finds and extracts the filesystems packed inside a firmware image; QEMU emulates the device processor so the firmware can run on a PC.

IoTGoat

OWASP's "deliberately insecure firmware based on OpenWrt", one flaw per Top 10 item. Run as a VM or on a Raspberry Pi. lab

DVRF

Damn Vulnerable Router Firmware: a Linksys E1550 image with MIPS exploitation exercises, usually run under QEMU. lab

Microcorruption

Browser CTF: real MSP430 assembly in a fictional smart lock, one memory bug per level, no setup. lab

Telnet on ports 23 and 2323, 62 default username:password pairs, a memory-resident bot. No exploit. Antonakakis et al., USENIX 2017

Source release

30 September 2016, by "Anna-senpai". Variants followed: more passwords, closed ports after infection, a short-lived domain generation algorithm.

Deutsche Telekom

26 November 2016: a variant hit TCP 7547 (TR-069 management) with a code-execution bug; about 900,000 customers offline. Fixed fast because an automatic update channel already existed.

Paper's recommendations

Random per-device passwords; ports closed by default; no WAN management; automatic updates with rollback and a physical fallback; owner notification; device identification; fewer, maintained operating systems; an end-of-life plan.

The consequence becomes physical. ATT&CK for ICS adds three tactics about the process itself; physical AI adds sensors as an input channel and a model as a hijackable reasoner.

Perception is the injection surface

"The attack arrives as light through the lens, and your network threat model never sees it." Black Hat USA 2026 showed a locomotion override by prompt injection. Exein TechTarget

Still an embedded device

"They have firmware, a kernel, a network stack, a supply chain, and, in the EU, a Cyber Resilience Act obligation." Weights, runtime and agent framework "are firmware now" and belong in the SBOM.

Enforce below the model

"Assume the model is compromised, and bound what that buys": kernel-level default-deny, the agent with its own identity and minimum mandate.

Robots are OT

Classify under NIST SP 800-82 and IEC 62443; treat the agent layer as "a new privilege boundary"; log every skill invocation as privileged; signed updates with staged rollout. "Robots shouldn't be secured like laptops." eSecurity Planet

An identifier plus a description and references, assigned by a CVE Numbering Authority (CNA). It carries no judgement. Severity, likelihood and exploitation are added later by other organisations: NIST's NVD scores severity, FIRST (the forum of incident response teams) publishes EPSS, a probability of exploitation (lesson 2.3), and CISA (the US cybersecurity agency) lists CVEs known to be exploited in its KEV catalog (lesson 2.4).

CNA

Authorised to assign IDs within a scope. The programme opened widely in 2016; GitHub became a CNA in 2020; the Linux kernel in February 2024 (Module 3). cve.org

NVD

NIST's database. It enriches records with CVSS, CWE and a CPE applicability statement; it "does not actively perform vulnerability testing". NVD

Backlog

Enrichment stalled in February 2024; about 27,000 unenriched CVEs by end 2025. Since April 2026 NVD enriches KEV entries within a business day and leaves low-priority CVEs unscored. A missing score is not a missing risk.

CWE · CPE

Weakness class (e.g. CWE-787 out-of-bounds write) · product-and-version name used for matching.

Severity in the abstract, not risk to you. The v4.0 user guide's own heading: "CVSS Base (CVSS-B) Measures Severity, not Risk". FIRST user guide

Nomenclature

The suffix says which metric groups were applied: CVSS-B base only; CVSS-BT base plus threat (is it exploited?); CVSS-BE base plus environmental (what does it mean on your system?); CVSS-BTE all three.

Bands

None 0 · Low 0.1–3.9 · Medium 4.0–6.9 · High 7.0–8.9 · Critical 9.0–10.0. The label applies to CVSS-B or CVSS-BTE alike.

New in v4

Attack Requirements split from Attack Complexity; Scope replaced by vulnerable-system vs subsequent-system impact; User Interaction None/Passive/Active; Temporal renamed Threat, Remediation Level and Report Confidence retired.

Safety

Environmental SI/SA can take the value Safety (IEC 61508 injury categories). Its absence "does NOT mean that there may not be any Safety-related impacts". For cyber-physical products you fill it in.

What vendors publish

CVSS-B only. A "9.8 Critical" on your dashboard is severity in a vacuum, scored by someone who never saw your device.

# a typical remote code execution in a device web UI: 9.3 Critical CVSS-B
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

A calibrated probability that exploitation activity against the CVE is observed in the next 30 days, recomputed nightly for every CVE. 0.05 means about a 5% empirical rate. FIRST, how it works

Coverage · efficiency · effort

Share of exploited CVEs you fixed · share of what you fixed that was exploited · share of all CVEs you touched. CVSS ≥ 7: effort 50.7%, coverage 74.6%, efficiency ≈ 6%. EPSS at the same coverage: effort ≈ 6%, efficiency ≈ 47%.

Percentile

Rank among all CVEs. 87th percentile at 3% probability is still 3%.

Limits

Population-level, not your network; weak for new CVEs; "a low score is not a declaration that a vulnerability is safe".

The embedded caveat

Gamblin: the model is built against "an average corporate network... we're not an IoT network, we're not an OT network... this might not be the model for you." The sensors watch laptops and servers, not fieldbus stacks.

Order of use

"EPSS should only be used as a primary source of information after you remove all exploited known vulnerabilities from your network." KEV first.

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2020-25159" | jq '.data[0]'
# epss 0.0303 · percentile 0.874 · 23 Oct 2026

That attackers have used the flaw. CISA's Known Exploited Vulnerabilities catalog (1,756 entries on 23 October 2026) is the only one of the four signals that reports a fact rather than an estimate. CISA KEV

Three criteria

An assigned CVE ID · "reliable evidence that the vulnerability has been actively exploited in the wild" · "a clear remediation action". CVSS plays no part: a 6.7 Medium can be listed.

Active exploitation

"Execution of malicious code was performed by an actor on a system without permission". Attempts count (honeypots). Scanning, research and proof-of-concept code do not; a PoC "does not automatically indicate the vulnerability has been or will be exploited".

BOD 22-01 → 26-04

US agencies must remediate listed CVEs by a due date (two weeks for post-2020 CVEs). Its FAQ: CVSS "does not account for" exploitation, yet "should still be a part" of the programme. CISA recommends everyone feed KEV into a framework such as SSVC.

Late and incomplete

Entry follows confirmed exploitation. Of 1,226 KEV CVEs studied, 22.4% had no EPSS score before exploitation and only ~20% had EPSS ≥ 0.5. The catalog skews to widely deployed IT products; a flaw exploited in one PLC family may never appear.

Four questions, no number, one of four outcomes. Stakeholder-Specific Vulnerability Categorization (SEI 2019, CISA's tree 2020) is "a customized decision tree model that assists in prioritizing vulnerability response". CISA SSVC guide

Exploitation

None · Public PoC (Metasploit, ExploitDB, well-known method) · Active ("shared, observable, and reliable evidence"). Describes now, does not predict.

Automatable

Can reconnaissance through exploitation be automated? Unauthenticated RCE is "likely yes". "One effective barrier is enough to get in a No answer." Chaining counts: an info-leak that removes an authentication barrier makes the pair automatable.

Technical impact

Partial (limited control or disclosure; denial of service is partial) · Total.

Mission & well-being

Mission prevalence (minimal / support / essential) × public well-being (minimal / material: injury, safety-margin failure / irreversible: fatalities, destroyed system). Essential or irreversible → High.

Outcomes

Track: standard timelines · Track*: closer monitoring · Attend: supervisors, sooner than standard · Act: leadership, as soon as possible. Only four of 36 rows reach Act, all with active exploitation.

Mitigation status is recorded but "does not change the priority of the SSVC decision". Since June 2026 NVD publishes CISA's SSVC values next to CVSS.

Order them, never average them: known exploited and present → fix now; EPSS above your threshold → schedule fast; then severity and context. Agreement between the systems on 600 Microsoft CVEs was near zero; they "assess vulnerabilities from fundamentally different perspectives". Koscinski et al., CCS 2025

Two "chainings"

Exploit chaining (SSVC's Automatable: several bugs, one path) vs scoring-system chaining (the sequential filter above).

Mistakes

"Patch all Criticals" (half of all CVEs) · PoC treated as exploitation · low EPSS treated as safe on OT · no NVD score treated as no risk · vendor CVSS-B treated as your risk.

Two structural limits, in ONEKEY's words: correctness (backported fixes do not change the CVE's version range) and expressivity (a product name and version cannot say which module, function, configuration or architecture a bug needs). ONEKEY Research, 2026

Reading the 5.15 row

A new branch has had almost nothing backported, so ranges are still right. The older the branch, the more the raw list lies.

After binary evidence

OpenWrt 21.02.7 on a Raspberry Pi 4: 4,479 raw candidates, 802 removed by ranges, then 2,830 scored negative by impact assessment. Average reduction 78.6% across five releases, before any CVSS, EPSS or KEV. Vendor figures.

Vocabulary

Backport: a fix applied to an older supported branch. Stable/LTS: fix-only kernel branches, LTS ≥ 2 years. Vendored: a library copied in, not linked as a package.

Since February 2024 the kernel is its own CNA and assigns a CVE to any stable fix that plausibly meets the vulnerability definition, after the fix lands, with no severity, because it cannot know your configuration. kernel CVE process

Only after the fix

"No CVEs will be assigned for unfixed security issues in the Linux kernel." Usually a one to two week delay.

What counts

Overflows, use-after-free, double free, crashes, lock-ups, denial of service, leaks. Not data loss, not performance, not hardware flaws such as Spectre.

panic_on_warn

A WARN_ON is a log line, unless the kernel runs with panic_on_warn, as Android, many clouds and "all Samsung phones" do. Then it is a reboot, so it gets a CVE. Without that option "like three-quarters of our CVEs would go away".

No severity

"I can't tell you the severity. I do not know the severity. So severity determination is for you." Microsoft and Apple "only report their severe ones... we report them all."

Keep pulling

Ranges get corrected after publication. Reading the first version of a record and never again is "a mistake".

Volume

4,325 CVEs in 2024 (third-largest CNA), first in 2025; roughly quadrupled per release in 2026 with bugs found by large language models (LLMs), about 33 a day.

The kernel's answer

"The best way to stay secure is to take all the patches." "If you're not using a stable kernel, your system isn't secure." A company that hand-triaged every kernel CVE "lasted six months". Cherry-picking CVE-tagged fixes "would lead to a false sense of security".

Proof that the affected code is not in your image, or cannot be reached. Kroah-Hartman's example: of 94 commits in one stable release, "19 commits... actually affected Android because you don't build the whole kernel. Only four of them had a CVE assigned."

Limits

Compiled is not reachable (a driver built but never probed). Reachable is not exploitable. All of it depends on metadata quality: Fixes: tags, affected-file lists, debug info.

ONEKEY's caveat

The score "is an evidence balance, not a CVSS replacement and not an exploitability oracle".

The cve-check class matches each recipe's product and version against a local NVD copy at build time; your triage goes into CVE_STATUS with a reason that maps to a VEX justification. The class says of itself: "Running this tool doesn't guarantee your packages are free of CVEs." Yocto docs

Three words from the snippet: local.conf is the build's settings file; a .bbappend adds lines to one package's recipe without editing it; INHERIT switches a feature on for every recipe in the build.

# conf/local.conf
INHERIT += "cve-check"
# every recipe gets do_cve_check; outputs:
tmp/deploy/cve/<recipe>_cve.json · tmp/deploy/images/…/<image>.json · tmp/log/cve/cve-summary.json

# recipes-kernel/linux/linux-yocto_%.bbappend
CVE_STATUS[CVE-2024-26666] = "not-applicable-config: CONFIG_INET_ESP not set"
CVE_STATUS[CVE-2021-47089] = "backported-patch: cherry-picked from 6.1.52 in vendor tree"
CVE_STATUS[CVE-2004-1599] = "cpe-incorrect: NVD entry matches a different project"

Automatic Patched

A patch named CVE-2022-3341.patch or carrying a CVE: header line is detected. Patch conventions are vulnerability metadata.

Precedence

Skipped recipe → Patched; CVE_STATUS reason; detected patch; then version in range → Unpatched.

Database

Since Yocto 5.2 the default feed is the FKIE mirror, because NVD "stopped annotating CVEs with the affected CPEs" in 2024. CVE_CHECK_IGNORE is deprecated.

Not by rebuilding it. The build emits an SBOM (the package list, in SPDX or CycloneDX format, lesson 4.2) and a VEX manifest (the list of CVEs that do not apply and why, lesson 4.3); an external tool checks them later, against any database. FOSDEM 2025: "cve-check 5 years after the original build, anyone?" Rybczynska & Jalabert

$ pip install "sbom-cve-check[extra]"
$ sbom-cve-check --sbom image.rootfs.spdx.json --vex image.vex.json --export-type yocto-cve-check-manifest
# Scarthgap ≥ 5.0.14, Walnascar, Whinlatter; not Kirkstone · SPDX 3 default since Walnascar

Why it moved

NVD stopped mid-February 2024, restarted around 20 May, processed under 10% of entries in January 2025. One database is a single point of failure. The vex class and cve-check are mutually exclusive; on OpenEmbedded master the external tool has become the build-time check.

VEX gap

Four statuses, but "no VEX expression for 'the entry is wrong, waiting for their update' or 'disputed' or 'abandoned project'". Yocto's tooling carries those as custom notes.

Scale

Real products: about 25 layers, about a thousand dependencies, 13+ kernel CVEs a day, decisions scattered as CVE_STATUS text. Sustainable only with automated applicability evidence, shared triage metadata, exploitation-based prioritisation, and an update pipeline that can ship the fix.

"A formal, machine-readable inventory of software components and dependencies, information about those components, and their relationships" (CISA). The recipe of the opaque blob. CycloneDX guide

NTIA minimum elements

Supplier · component name · version · other unique identifiers (CPE, purl, SWID) · dependency relationship · SBOM author · timestamp. Licence and hashes are beyond the minimum, and useful.

CRA minimum

Annex I Part II: an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies". No format imposed; a shallow legal floor.

Good practice

"All direct and transitive components and the dependency relationships between them", with identifiers tools can match. Regenerated every build.

Why embedded is harder

An image is a kernel with a configuration, a bootloader, a root filesystem from a build system, vendored libraries and vendor blobs. Generate from the build, do not reconstruct from the binary afterwards.

Support both. SPDX is the Linux Foundation's ISO standard; CycloneDX is OWASP's Ecma standard. Generate at build time, where the configured packages and versions are exact.

# Yocto
INHERIT += "create-spdx"      # SPDX 2.3 or 3.0; 3.0 default since 5.2 Walnascar; records CONTAINS relationships and provenance
INHERIT += "vex"              # CVE_STATUS metadata beside the SBOM
# Buildroot
$ make show-info | utils/generate-cyclonedx
$ make pkg-stats              # versions, CVEs via support/scripts/cve-check, upstream status
# Zephyr: SPDX from the CMake build since 2021, listing the sources actually compiled and linked

purl

Package URL, cross-ecosystem identifier: pkg:generic/openssl@3.0.13.

Not SBOM formats

CSAF 2.0 (OASIS's advisory format) and OpenVEX (a minimal JSON format) carry VEX statements, not inventories. Lesson 4.3.

Provenance

Yocto's SPDX links image → package → source, download location and patches. A tool that flattens that into a list loses what the CRA's risk assessment needs.

"The status of a software product or component with respect to a vulnerability": one of four statuses, and for "not affected" one of five justifications. "VEX does not specify, assume, or imply any default status." CISA minimum requirements

Who writes it

"The supplier of the software or by a third party": vendor, coordinator (a CERT or CSIRT, a computer security incident response team), discoverer, user. Not only CISA.

Minimum content

Document id, version, author, first-issued and last-updated times; per statement one status, one vulnerability, one or more product ids (which "SHOULD reference existing SBOM identifiers") and a description.

Carriers

CSAF 2.0 VEX profile, CycloneDX vulnerabilities, OpenVEX, SPDX 3.0 security profile. VEX is a set of requirements, not a file format.

Common pattern

Subcomponent affected, product not affected, with justification. Statuses move over time; documents are reissued.

The SBOM produces candidates; developer context, recorded as VEX, removes the ones that do not apply with an auditable reason. Exploitability "cannot be completely solved without internal developer context on how a third party package is being used." Black Hat Asia 2025

What to measure

Not how many CVEs a tool finds: how many it can justify removing, and whether the justification would survive an auditor.

Drivers

US Executive Order 14028 (May 2021) and CRA Annex I. Splunk's team automated SBOM and VEX generation to "minimize the false positives and enhance customer trust".

Two failure modes

An SBOM without VEX hands the customer the flood. A VEX without justifications asks the customer to trust you.

With a threat model, then one control per layer. "Security is all about risk mitigation"; "an attacker needs only one flaw to compromise the device" (Prado). "Any Threat Model is better than no Threat Model" (Bootlin).

Remediation, five answers

Patch or backport the component (3.4, 5.6); prove the CVE does not apply with VEX (4.3); harden the build: secure boot, least privilege, Zephyr hardenconfig (5.2 to 5.4, 5.8); mitigate at runtime with eBPF policy (5.7, 5.10); for Physical AI, enforce below the model (1.5, 5.10). Every lesson in this module is one of the five.

STRIDE

Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege: per component and data flow.

Attack trees

Goal at the root, ways to reach it as children; "attribute a cost to leaves, the cost of the parent is the min".

CIA + 2

Confidentiality, integrity, availability, plus authenticity and non-repudiation for devices.

A chain: "the manufacturer's ROM code verifies the first stage bootloader; the last stage bootloader verifies the OS kernel; the kernel, optionally, verifies the userland." It stops offline reflashing and persistence. "It is not designed to protect against runtime compromise of the system via a vulnerability." Bootlin

Root

Mask ROM plus a hash of the public key in one-time-programmable fuses. i.MX93: SHA-256 of a four-key table in fuses, EdgeLock enclave verifies; Raspberry Pi 4: four RSA-2048 ROM keys. "The SoC vendor is very much part of the trusted perimeter."

FIT image

U-Boot's signed container for kernel, device tree, initramfs. CONFIG_FIT_SIGNATURE refuses unsigned legacy images; mkimage -k keys -f kernel.its kernel.itb -r signs, -r marks the key required.

Names

"Secure Boot, High Assurance Boot, Trusted Boot or Verified Boot" (Toradex). Same chain.

Environment

Under secure boot the U-Boot environment is attack surface: allowlist the writable variables.

Glitching

Module 1's fault injection targets the ROM stage. Redundant checks, glitch detection, certified silicon.

Measured boot

The other model. Instead of refusing unsigned code, each stage hashes the next one into a register of a TPM (trusted platform module, a small security chip) and the kernel's IMA/EVM log every file it opens. It records what ran and blocks nothing; a remote verifier reads the record (attestation). Filesystem integrity at runtime is lesson 5.3's dm-verity.

dm-verity for integrity, dm-crypt or fscrypt for confidentiality, keys in hardware. "The protection of the encrypted code/data is as secure as the protection of the key" (Prado).

Root hash

Signed and checked against the kernel keyring (CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG), or carried inside something already signed. Then "the kernel command line is now security sensitive, and must be signed".

Encryption

Secure boot does not prevent code extraction from a dumped flash. dm-crypt (block), fscrypt (file); AES with a mode (CBC, CTR, GCM). The problem is the key, not the cipher.

Keys, weakest to strongest

Derived from device identifiers (obfuscation) · kernel trusted keys sealed by TPM, CAAM or EdgeLock · a secure element or HSM via PKCS#11, OP-TEE's PKCS#11 trusted application as "software HSM". HSMs "split usage of cryptographic material from knowledge of the cryptographic material".

Shipped layout

Signed FIT kernel; read-only SquashFS root under dm-verity with signed root hash; a separate dm-crypt data partition with the key in the secure element; A/B slots (5.5).

Least privilege, layered: a dedicated user, only the capabilities needed, a mandatory access control policy, namespaces and cgroups, a seccomp filter, and systemd options that apply all of it per service.

Capabilities

Root split into pieces since 2.6.24: CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SYS_ADMIN…; five per-thread sets; setcap on a binary instead of setuid root (ping with cap_net_raw).

SELinux

Type enforcement, "by default, everything is forbidden"; mainline since 2003; "used on all Android devices"; Yocto and Buildroot ship the reference policy.

AppArmor

Path-based profiles, about twenty access modes; "less advanced features but... easier to use".

Namespaces · cgroups

Mount, UTS, IPC, PID, net, user, cgroup, time; resource limits with cgroups v2. "One fundamental principle behind software containers."

seccomp

Strict mode allows only read, write, exit, sigreturn; anything else kills the process. Filter mode (since 3.5) uses BPF programs, libseccomp.

Attack surface

Every service not shipped cannot be exploited. No compiler or headers on target (Buildroot), static monolithic binary (Zephyr), closed ports, no debug console. ETSI 5.6-1: "All unused network and logical interfaces shall be disabled."

# /etc/systemd/system/gateway-agent.service
[Service]
User=gateway
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
SystemCallFilter=@system-service
SystemCallFilter=~@mount @reboot @module @raw-io
ReadWritePaths=/var/lib/gateway
# Bootlin: "A good practice is to enable as much as possible of these options."

Two identical slots. Write the inactive one, point the bootloader at it with a bounded number of attempts, commit after a health check, fall back otherwise. "An OTA should never touch boot locations from the current slot." Anavi, FOSDEM 2025

Trade-off

A/B: double storage, full image, rollback and fallback. Delta: small, no inherent fallback.

Choosing

RAUC is "an update mechanism you integrate"; Mender is client and server designed together. Keep a qualified RAUC setup; start from nothing wanting turnkey fleet rollout, Mender. "Developing an in-house solution is rarely worth the effort."

Secure boot

Boot-state variables must be the only writable ones, or the update state becomes the attack vector. The pipeline must also ship signed bootloaders (Toradex).

In the build system, as a rebuilt image on a supported branch, with regenerated SBOM and VEX, shipped through the A/B pipeline.

Buildroot

"Simplifies and automates the process of building a complete Linux system... using cross-compilation." Quarterly releases, LTS three years. No compiler on target, no package manager: binary packages are "not necessary, and potentially harmful"; a security fix is a rebuilt, reflashed image. Need a package manager? "You need a real distribution." manual

Yocto

Layers of recipes; cve-check, vex, create-spdx, provenance of every download and patch; LTS four years, which "is not enough for most embedded products" against the CRA's five. tutorial series, 83 videos

Process, both

Track an LTS branch and take its updates (kernel LTS ≥ 2 years; CIP beyond 5). Carry backports as patches with CVE: and Upstream-Status: tags. Archive SBOM and VEX per shipped image. Upstream your patches: BSPs "years (literally) behind upstream" end in "no security updates".

Watch and block behaviour during the attack, at kernel level, without a kernel module and without the risk that the agent crashes the device. The verifier is the point. ebpf.io

Tetragon

"Real-time, eBPF-based Security Observability and Runtime Enforcement": process, syscall, file and network events, filtered in kernel. A TracingPolicy hooks kprobes, tracepoints or uprobes with selectors and actions. docs

Override · Signal

Override: "the function will never be executed and, instead, a value (typically an error) will be returned." SIGKILL terminates synchronously, but a kill during write() does not stop the write, so "the Signal action should be combined with the Override action".

Example

Policy blocks reads of /etc/shadow: cat /etc/shadow exits 137 with a SIGKILL event; a second policy kills external curl while in-cluster traffic continues.

On devices

Secure boot cannot stop a runtime exploit; MAC confines statically; eBPF adds dynamic detection and blocking at an overhead constrained devices can afford. Exein's Pulsar requires Linux ≥ 5.5 with BPF and BTF: the practical floor.

A documented process, a build-time hardening gate, a build-time SBOM, a disclosure policy with a defined embargo, mandatory CVEs, backports to supported branches. Measure any RTOS or vendor against that list. Zephyr security

Process

Independent reviewer plus separate security review; static analysis with documented waivers; fuzzing in CI; threat model = assets, data-flow diagrams, STRIDE with CVSS, countermeasures.

Design

Open design, least privilege, defence in depth, fail-safe defaults, "features off by default"; user mode with MPU partitions; stack guards; PSA Crypto via Mbed TLS; "a monolithic static binary with no dynamic loader".

Vulnerabilities

Reports acknowledged "within 1 week"; PSIRT from platinum members; embargo "of at most 90 days" (30 to fix + 60 downstream); "each issue... shall be assigned a CVE number"; backports to current LTS and two most recent releases. The list is mostly out-of-bounds writes in DNS, Bluetooth, USB and TLS code: disable unused subsystems.

Why it matters here

Exein Runtime claims RTOS-based devices as well as Linux; Zephyr is the RTOS whose security process is public enough to be measured against.

$ west build -t hardenconfig
# Kconfig vs scripts/kconfig/hardening.yaml (Security WG); flags EXPERIMENTAL / DEPRECATED / NOT_SECURE options
# profiles base and strict (strips logging, shell, asserts); e.g. CONFIG_BOOT_BANNER=n, STACK_POINTER_RANDOM ≥ 100
# HARDENCONFIG_STRICT fails CI; JSON output; out-of-tree rules

Two inventories on one device, isolation that is only as good as its defaults, and a runtime that the CRA treats as an important class II product (the CRA sorts products into default, important class I or II, and critical; the class decides who checks conformity, lesson 6.2). The container image carries its own packages and therefore its own CVEs; an SBOM scoped to the base system under-reports.

Why devices use them

Update one application without reflashing the firmware; isolate third-party apps; reuse cloud tooling. Yocto's meta-virtualization layer ships docker, podman, containerd, runc, crun, k3s, kubernetes, cri-o, lxc and more; balena and similar platforms orchestrate fleets of containers. meta-virtualization

Isolation defaults

Docker's default seccomp profile "disables around 44 system calls out of 300+" and is "an allowlist that denies access to system calls by default"; its AppArmor profile docker-default is "moderately protective while providing wide application compatibility"; rootless mode runs daemon and containers as a non-root user "to mitigate potential vulnerabilities in the daemon and the container runtime". Devices often ship with these weakened or disabled; check. Docker docs

Shared kernel

Containers do not virtualise the kernel. A kernel CVE reachable from inside a container is a host CVE. Module 3's kernel triage applies unchanged; a hypervisor (KVM, Xen) is the stronger wall when it is needed.

Two SBOMs

The firmware SBOM (Module 4) plus one per container image, with their own base distributions. A scan that covers only the rootfs misses the application layer, which is where the most frequently updated code lives. Exein Analyzer lists Docker among the inputs it covers.

CRA

Annex III class II: "hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments". Class II means Module B+C, Module H or a certificate at level "substantial": a notified body, not self-assessment. Operating systems are class I.

Runtime policy

Because one kernel sees everything, an eBPF agent on the host can apply per-container policy: which binaries may run, which files and destinations each container may touch. Lesson 5.10's allowlist, per container.

A policy written once, pushed to every device, enforced in the kernel by an eBPF agent, with events flowing back to one console where a human decides: expected, misconfiguration, or incident. On a fleet, the hard parts are identity, bandwidth, offline devices and false positives.

Allowlist beats blocklist

A device does one job, so its normal behaviour is small and knowable: these binaries, these files, these destinations. Anything else is an event. Servers cannot do this; devices can, which is the device-security advantage.

Detect vs enforce

Start in observe mode to learn the baseline, then enforce (Override, SIGKILL) for the clearest rules. Enforcing a wrong rule on 10,000 devices is an outage you caused.

Fleet constraints

Each device needs an identity (per-device certificate) so events cannot be spoofed; events must be rate-limited and summarised, bandwidth is scarce; devices are offline for days, so policy and events must queue; a policy must be versioned like firmware and rolled out in rings.

Triage steps

1 What happened: the event chain, not one event. 2 Is it expected: new firmware version, technician session, known cron job? 3 Scope: one device or a pattern across a version or customer? 4 Impact: did it reach data, control or other devices? 5 Act: kill, isolate, rotate credentials, push an update; 6 Record: tune the policy, and if exploitation is confirmed start the CRA 24-hour clock (Module 6).

False positives

The product's enemy. A rule that fires on every firmware update trains people to ignore alerts. Measure precision per rule and retire noisy ones; correlate with the SBOM so an alert on a vulnerable component outranks one on a patched component.

From alert to vulnerability

An exploited device often reveals which CVE was used. That links the runtime track back to the analysis track: mark the CVE affected, VEX it, prioritise the fix, verify with the fleet that the exploit stops.

Physical AI

A robot or a device running a model is the same fleet with one more input, the sensor. Lesson 1.5's loop (perception → reasoning → action) means an alert can start as a camera frame, so the policy sits below the model and triage asks what the model was told.

Any "product with digital elements": "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately", with "a direct or indirect logical or physical data connection" (Articles 2, 3). Free products count. EUR-Lex

Out

Medical devices (2017/745, 2017/746), vehicles, civil aviation, marine equipment, spare parts, national-security products.

Manufacturer

Develops or has developed, and markets under its name "whether for payment, monetisation or free of charge". Carries almost all obligations.

Importer · distributor

Verify CE mark, documentation, contact details; must not place non-compliant products.

ENISA

The EU Agency for Cybersecurity. It runs the single reporting platform (lesson 6.4) and receives notifications; it carries none of the manufacturer's obligations.

Open-source software steward

"A legal person, other than a manufacturer" supporting open-source software intended for commercial use. Light regime (6.6).

Rule of thumb

"It is the person who puts it in the product who carries obligations" (Kroah-Hartman). Yocto "is not a product with a manufacturer... users of the YP are (usually) manufacturers... Full CRA compliance required from them" (Rybczynska). You own every byte in the image, vendor patches included; Article 13(6) also makes you report component flaws upstream with the fix.

Geography

"The CRA applies even if the software wasn't developed in the EU" (Wheeler, Linux Foundation). Placement on the EU market is the trigger.

Default products self-assess. Important class I may self-assess only if harmonised standards are fully applied; class II and critical need a notified body or a certificate (Articles 7, 8, 32).

Paperwork

Technical documentation before placing on the market, kept current for the support period (Art. 31); EU declaration of conformity, "the manufacturer shall assume responsibility" (Art. 28); CE mark "visibly, legibly and indelibly", for software on the declaration or a website (Art. 30).

Presumption

Harmonised standards in the Official Journal, or recognised certification schemes, give a presumption of conformity (Art. 27). The CRA-specific standards are still being drafted, which is why class I self-assessment is conditional.

Open source in Annex III

May still self-assess if the technical documentation is public (Art. 32(5)).

Annex I Part I: properties of the product. Part II: processes you run for the support period, at least five years. Article 13 requires a documented risk assessment deciding which Part I properties apply.

Paraphrased from Annex I; quote the Official Journal in contracts or declarations.

Support period

"Shall be at least five years" unless the product is used for less (Art. 13(8)); published updates stay available ten years or the support period, whichever is longer (13(9)); end date shown at purchase (13(19)).

Collision

Yocto LTS four years, Buildroot three, kernel LTS two: at least one base migration per product life, or extended maintenance, or CIP kernels. "December 2027 is 'tomorrow'" (Rybczynska).

Mapping

Part I items 3, 5 = Mirai; 11 = the UART header; 4 = Deutsche Telekom. Part II items 1, 2 = Modules 3 and 4; items 5, 6 = Zephyr's PSIRT.

An early warning on ENISA's Single Reporting Platform, then a notification within 72 hours, then a final report. Live since 11 September 2026, for products already on the market. European Commission

Awareness

After an initial assessment, "a reasonable degree of certainty" (Commission guidance, July 2026). No duty for exploitation known before 11 September 2026.

Where

One submission on the SRP reaches the CSIRT of your main establishment (where cybersecurity decisions are taken) and ENISA. Web form only at launch, English, EU Login with MFA, one primary and up to twenty secondary representatives; the wrong CSIRT can invalidate the report. ENISA can assign a CVE and add it to the EUVD. ENISA FAQ

Then

Inform impacted users with mitigations (Art. 14(8)); notify affected component maintainers; if you fail, the CSIRT may inform users itself.

Readiness

Product inventory, named team with backups, SRP accounts, tabletop drills on the 24-hour window, board reporting (Skadden, Jones Day).

Three tiers up to EUR 15 million or 2.5% of worldwide turnover, whichever is higher (Article 64). Reporting since 11 September 2026; everything else from 11 December 2027 (Article 71).

No fines for micro and small enterprises missing the 24-hour early warning, and none at all for open-source stewards (Art. 64(10)). Authorities can also order correction, withdrawal or recall.

Non-monetised open source outside a commercial activity is out of scope; foundations become stewards with light duties and no fines; manufacturers who use the code carry the obligations and must report fixes upstream. The 2023 draft said otherwise, and the community changed it.

2023 fears

"Programming is not my profession though, it's my hobby"; "a solo developer selling 100€/month of support is treated the same way than a billion dollar company" (Hacker News, Debian statement thread). HN

Final text

Recital 18: open source "not monetised by their manufacturers" is not commercial activity. Art. 3(14), 24: the steward, "a legal person", with a documented cybersecurity policy and reporting "to the extent that they are involved". Art. 25: voluntary attestation. Art. 32(5): self-assessment for open source in Annex III with public documentation. Art. 13(6): manufacturers report and share fixes upstream.

Reception

VideoLAN's president: "The new version of the CRA is quite an improvement." OSI: "The European regulators listened to the Open Source communities." Open questions remain on "making available on the market" and paid add-ons. HN HN

Kernel's reading

Three roles: manufacturer, steward, out of scope. The Linux Foundation is the kernel's steward. When a steward stops maintaining, its duties end; the manufacturers' do not. Advice: security.txt, become a CNA, OpenSSF best practices, REUSE. Headline: no need to panic.

Yocto

Tooling, so at most a steward; it supplies build-time SPDX, provenance, cve-check, security layers, four-year LTS, and plans a CRA-aligned security policy in 6.0. The Eclipse-hosted Open Regulatory Compliance Working Group (with the Apache Foundation and others) writes process specifications and liaises with CEN and CENELEC. ORC WG

ETSI EN 303 645 (2020), the consumer-IoT baseline: 13 provision groups, about 33 "shall" and 35 "should", assessed with TS 103 701. Not yet a CRA harmonised standard, but it maps onto Annex I item by item. ETSI

Consumer scope: toys, cameras, locks, hubs, appliances. Industrial and healthcare devices look to IEC 62443-4-2 instead; the provisions translate, the assessment regime does not.

The ten things a device team does

1. Own the manufacturer role for every byte; map main establishment and coordinator CSIRT.
2. Risk assessment and threat model, documented, maintained (5.1).
3. SBOM from the build, archived per shipped image (4.2).
4. A CVE scan on every build with recorded decisions (Yocto cve-check and CVE_STATUS, or the equivalent), VEX export, exploitation-first triage (2.6, 3.4).
5. Secure boot and a signed OTA pipeline with rollback; none ships by default (5.2, 5.5).
6. Secure defaults: no universal passwords, debug off, unused services off; upstream "unsecure configuration by default" is "quite common".
7. A published support period longer than your LTS plan allows, with the migration it implies.
8. CVD policy, security.txt, contact address, public advisories, upstream reporting.
9. The 24-hour drill: SRP accounts, named people, tabletop (6.4).
10. Technical documentation, Annex III classification, declaration of conformity before 11 December 2027.

RED 3.3 is the cybersecurity rule already in force for connected radio equipment, applicable since 1 August 2025 and repealed on 11 December 2027 when the CRA takes over. IEC 62443 is the industrial security standard series: part 4-1 for how you develop, part 4-2 for what a component must do, with four security levels.

RED 3.3 scope

(d) network protection: "any radio equipment that can communicate itself over the internet"; (e) privacy: internet-connected equipment processing personal, traffic or location data, plus childcare equipment, toys and wearables; (f) fraud: internet-connected equipment that lets the user "transfer money, monetary value or virtual currency". Medical devices excluded. NIST checklist quoting Art. 1

Standards

EN 18031-1, -2, -3 (2024), cited in the Official Journal on 30 January 2025 by Implementing Decision 2025/138, with restrictions: no presumption of conformity if the user "is allowed not to set and use any password", if parental access control is not ensured for childcare, toys and wearables, or for the secure-update clause under (f). Where a restriction applies, a notified body is required.

Routes

RED Article 17: harmonised standards applied → Module A, B+C or H; not applied or restricted → B+C or H only. Same logic the CRA reuses.

Hand-over to the CRA

Delegated Regulation (EU) 2026/339 (adopted 16 February 2026, OJ 29 April 2026): 2022/30 "is repealed with effect from 11 December 2027", "to prevent radio equipment ... from being simultaneously subject to requirements" of the CRA. The CRA asked standards bodies to reuse the EN 18031 work. Practically: a connected product shipping before December 2027 needs RED 3.3 now and the CRA after.

IEC 62443, the series

Requirements and processes for securing industrial automation and control systems, shared among asset owners, integrators and product suppliers. For a device maker the parts are 4-1 (secure development lifecycle) and 4-2 (component requirements for embedded devices, host devices, network devices, software applications); 3-3 is for systems, 3-2 for risk assessment with zones and conduits. ISA

4-1's eight practices

Security management; specification of security requirements; secure by design; secure implementation; security verification and validation testing; management of security-related issues; security update management; security guidelines. Compare Zephyr's process (5.8) and CRA Annex I Part II.

Seven foundational requirements

FR1 identification and authentication control · FR2 use control · FR3 system integrity · FR4 data confidentiality · FR5 restricted data flow · FR6 timely response to events · FR7 resource availability. 4-2 states each per component.

Security levels

SL1 casual or coincidental violation · SL2 intentional, simple means · SL3 intentional, sophisticated means · SL4 sophisticated means with extended resources. A product is certified to a capability level (ISASecure CSA covers 1 to 4; certification bodies accredited to ISO/IEC 17065; the IECEE CB scheme also covers 3-3, 4-1, 4-2).

Why a device PM cares

Industrial customers ask for 62443-4-2 at a stated SL and a 4-1 process; the CRA names no standard but its Annex I maps onto 4-1 and 4-2, and Exein lists 62443, RED 3.3, ETSI EN 303 645 and the CRA as the frameworks its compliance mapping covers. Consumer products → ETSI EN 303 645; industrial → IEC 62443; both → CRA.

In one of three positions: pre-market binary analysis of a firmware image, build-time integration in Yocto, Buildroot or CI, or runtime protection on the shipped device. Most occupy one. CRACI taxonomy

Five questions for any vendor page

Where does it sit and what does it need (binary, build, kernel)? What evidence removes a CVE (ranges, config, compiled sources, symbols, reachability)? What does it export (SPDX, CycloneDX, VEX with justifications)? Does it prioritise by exploitation or only CVSS? Which compliance evidence (CRA, IEC 62443, RED, FDA 524B)?

EMBA

Open-source firmware analyser: GPLv3, static plus emulation-based dynamic analysis, SBOM, web UI, no vendor support.

Names in the diagram

ONEKEY, Finite State, NetRise, Cybellum, Binarly: commercial pre-market services, upload an image and read a report. Timesys Vigiles and RunSafe Identify: build-time SBOM and CVE monitoring. RunSafe Protect: runtime memory protection by relocating code at load time. Manifest: an SBOM management platform, not a scanner.

Two products, Analyzer at build time and Runtime on the device, distributed through the build system and silicon and board vendors rather than through security buyers. Rome, founded 2018; "Next-generation Physical AI cybersecurity". exein.io

Analyzer

"Binary analysis, SBOM generation, and AI-driven remediation built into your build pipeline." Scan: "every dependency, vendored library, and third-party driver hiding in your firmware." Assess: "reachability scoring and LLM-powered filtering." Fix: remediation "directly inside Yocto and CI/CD". "AI-powered CRA evidence mapping."

Runtime

"A real-time security platform protecting Physical AI Systems, Linux-based environments, and RTOS-based devices", "optimized for resource-constrained environments". Built on Pulsar: open source, "modular and blazing fast runtime security tool for the IoT, powered by eBPF", Rust, Linux ≥ 5.5 with BPF and BTF. Photon: kernel-level eBPF LSM enforcement. Pulsar

Channels

"Starting from Yocto Release 5.0 (Scarthgap) all Yocto devices include Exein Security Metalayer as a default compatible layer"; native in MediaTek Genio from IoT Yocto 24.1; SECO (subscription on SECO hardware since 2022), Supermicro, Kontron, AAEON, Logic Technology; Arm and Nvidia on the partner wall.

Pitch

"Decentralize your security", "Monetize OEMs", "Cure compliance headaches" (CRA, RED 3.3, IEC 62443, ETSI EN 303 645, Cyber Trust Mark). Claims: 1B+ devices, 1M+ high-severity vulnerabilities, 100K+ attacks blocked.

"A component-level CVE match does not always mean a vulnerability affects the product" (ONEKEY). Both sell evidence-based removal of non-applicable CVEs from a binary image, re-run continuously, exported as compliance evidence.

ONEKEY

Düsseldorf, PwC-backed, maintains unblob. "Analyzes firmware at binary level, so your team never needs source code or a build system." Impact Assessment "cuts more than 60% of false positives"; "each result explains why a CVE matters and what to do next"; Digital Cyber Twin re-analyses shipped versions; Compliance Wizard for CRA, IEC 62443, ETSI EN 303 645, RED. Claims "90% less vulnerability effort", "ROI in under 3 months". ONEKEY

Finite State

Columbus, founded 2017, $30M Series B 2021 with Schneider Electric; acquired MergeBase 2024. Binary decomposition across 50+ instruction set architectures; SBOM in CycloneDX and SPDX, VEX, control-mapped evidence; GitHub Actions, CLI, SDK, Jenkins, Azure DevOps; imports from 161 scanners; 40.5% of 10.9M findings marked unreachable. No free tier or trial; "produces assessor-ready artifacts but does not itself confer compliance". review

The question to ask

"Show me a CVE your tool marked not affected, and the evidence." Place it on Module 3's ladder. A false-positive percentage is marketing until you know which rung it stands on and whether it exports as a VEX justification you could sign.

Two sets of competitors, one per track: on CVE management, Aikido (code and dependencies), ONEKEY and Finite State (firmware images); on runtime, SentinelOne and CrowdStrike (servers and laptops). All made the same three moves first: rule out by reachability, rank by exploitation likelihood, automate the fix with a confidence signal. Exein's claim: the same moves at build time plus on the device, with evidence a regulator accepts.

Aikido AutoTriage

"First tries to rule out exploitability, then (only when needed) ranks remaining findings": is the function called, is the dependency only tooling, is there sanitisation between source and sink. Auto-ignore when "there's no path from untrusted input to a dangerous sink". Then a 0–100 severity adjusted by code context. docs

Aikido AutoFix

"Every fix ships as a pull request you trust", with a confidence score; "most SAST fixes in under 5 seconds"; "all scans are read-only". The shape "AI-driven remediation inside Yocto" must take to be trusted. page

SentinelOne lifecycle

Discover assets ("the cycle begins with identifying all the hardware devices") → assess and scan → prioritise by "CVSS scores and exploit prevalence" → remediate or mitigate → verify and monitor. Metrics: time to patch, recurrence, dwell time. On devices the asset is a firmware version in the field. article

EDR vs XDR

EDR "focuses on endpoint devices"; XDR "collects and correlates data from several security layers" with analytics and hunting, at higher cost. An eBPF agent on a gateway is EDR-shaped for a device that cannot run an EDR; a fleet view across devices, network and cloud is XDR-shaped. article

CrowdStrike exposure management

"What is actually exploitable in my environment? Where am I exposed right now? How do I reduce risk before adversaries attack?" ExPRT.AI predicts likely exploitation from adversary intelligence and telemetry: "Unlike static CVSS scoring, it prioritizes exposures based on exploitability, attacker behavior, and environmental context." Attack-path analysis, asset discovery incl. IoT/OT, "no rip and replace". data sheet

Where Exein differs

Footprint and floor: an eBPF agent on Linux ≥ 5.5 and an RTOS story, where an endpoint agent built for servers does not run. Place: inside the build (Yocto layer, CI) and on the device, where AppSec tools stop at the source repository, with CRA evidence export at the end.

They sell time: the engineering hours a device maker does not spend on CVEs that do not apply, and the 24 hours it has when one does.

Customer

Device makers and the silicon and board vendors who supply them. The user (the embedded engineering lead) is often not the buyer (product security officer owning the CRA declaration), who is often not the deployer (OEM partner).

Demand

Dates: Article 14 since September 2026, full CRA December 2027, RED 3.3, IEC 62443, FDA 524B, Cyber Trust Mark. Evidence export (SBOM, VEX, control mappings) is the feature that follows.

Product must

Integrate where customers build (Yocto layer, Buildroot hook, GitHub Actions, CLI); remove noise with evidence over shipped images; prioritise by exploitation; export SPDX, CycloneDX and VEX with justifications; for runtime, fit the footprint, state the kernel floor, prove the overhead, enforce below the model.

Pricing

Mostly quote-based: per device, per fleet, per image per year, or OEM-bundled subscriptions (SECO with Exein). CRACI per build minute is the exception; Finite State has no free tier; Aikido starts free.

Metrics

False-positive rate after triage · time to triage (the CRA's 24 hours is the ceiling) · coverage and efficiency (2.3) · time to patch and recurrence · evidence acceptance by auditors, notified bodies, customers.

Two tracks that meet in one console. Analysis, which is CVE management: upload or CI build → unpack → SBOM → CVE candidates → impact assessment → prioritised list → VEX and remediation → compliance evidence. Runtime: policy → agent → events → alerts → triage → response → back to the vulnerability list. Three users walk it: the firmware engineer, the security engineer, the compliance owner.

Firmware engineer

Wants: integrate in Yocto or CI once, see only what applies, get a patch or a recipe change, not a PDF. Fears: noise, build slowdowns, a tool that blames them.

Security engineer

Wants: evidence per removed CVE, KEV and EPSS visible, policies they can tune, alerts with chains not single events, exports to their SIEM. Fears: false positives, an agent that bricks devices.

Compliance owner

Wants: documents an auditor accepts, per version, with dates. Fears: the 24-hour clock with no process behind it.

Moments that decide retention

First upload to first "this CVE does not apply, here is why" (time to first value). First CI integration. First alert that was real. First audit passed with exported evidence.

Adoption: did they integrate it where they build? Value: did it remove noise honestly and fast? Retention: do they come back every release and every alert? Each has one number you can defend.

Coverage · efficiency · effort

From Module 2: of exploited CVEs, how many you fixed; of what you fixed, how many were exploited; how many you touched. Report your prioritisation on these, not on "CVEs found".

Leading vs lagging

Activation and CI integration lead; retention and fleet-on-latest lag by months. Review both, decide on the leading ones.

What not to report

Total CVEs detected (rewards noise), total scans (rewards manual re-uploads), alerts generated (rewards bad rules).

Anywhere a human would read, classify, summarise or draft, with the evidence attached and a reviewer at the end. Nowhere as the sole author of a statement a regulator can hold you to. Exein's language is "LLM-powered filtering" (LLM: large language model), "AI-driven remediation" and "fine-tuned LLMs tell you exactly what caused each incident"; the question is what those mean in practice.

How to evaluate it

A labelled set of CVEs triaged by humans; measure the model's agreement, false "not affected" rate (the dangerous error) and false "affected" rate (the noisy error) per evidence rung; re-run on every model or prompt change. Module 2's coverage and efficiency vocabulary applies.

Failure modes

Hallucinated function names and versions; confident wrong justifications; drift when the CVE description is thin (new kernel CVEs often are); prompt injection through CVE text or firmware strings. Treat model output as untrusted input to the product.

Exein's direction

Photon compiles TOML rules into eBPF programs enforced "in the kernel across host and container"; an "AI Compliance" mapping is in beta; a proprietary foundation model for physical-AI security, trained on two years of telemetry from more than two billion devices, is announced for Q1 2027, to "power autonomous security agents". Vendor claims; no independent benchmark exists. Exein, Sept 2026

The question for any AI feature

For each AI feature: what is the human doing today, how long does it take, what error is acceptable, what evidence must the output carry, and how will we know it got worse? If the last question has no answer, the feature is a demo.

Four possible features, one engineering team. The facts in this course rank them; the method: who is blocked, by which date, with what evidence, and what each costs in false confidence.

A defensible order

B, then A, then D as a drafting aid bound to B's evidence, then C when the fleet data shows container adoption crossing a threshold you set. B because it is the product's core promise and unblocks everything downstream; A because the date already passed and it is cheap; D only on top of evidence; C by measured demand.