Secure by Construction: Production Security That Ships With the OS

I have spent fifteen years building embedded Linux the hard way. Network switch firmware at HPE and Aruba. Upstream kernel and security work at Linaro, where I pushed a complete UEFI Secure Boot implementation into meta-arm and kept CVE backports current across a rack of ARM targets. Most recently I built shipcheck, a tool that audits Yocto builds for the EU Cyber Resilience Act, because I kept watching teams get CRA advice that was flatly wrong.

I joined Peridio a few weeks ago, and I turned down another offer to do it, because Avocado OS handles security the way I have spent years arguing it should be handled and almost never is. 

Security is a property, not a phase

Read most embedded security advice and it follows the same shape: build the product, run a scanner near the end, triage the CVEs, generate an SBOM, ship. Security becomes a phase you schedule before launch and a tool you buy to get through it.

That framing is wrong, and if you have shipped embedded Linux you already know it. The properties that actually matter cannot be added at the end. You cannot make a mutable rootfs immutable after the fact. You cannot reconstruct a reproducible build once it is non-deterministic. You cannot bolt a hardware root of trust onto a system that booted unverified. By the time the security review arrives, the architecture has already decided most of the answers.

Avocado OS makes the architecture decide them correctly. The properties are present from the first build, which is why I describe its security as secure by construction rather than secure after hardening. "Secure by default," the posture the CRA will require, is not a checklist here. There is no writable root to harden, no debug interface to remember to disable, no configuration drift to audit. The image contains only what you composed into it, so a minimal attack surface is the starting point, not a goal. Your robot does not ship with printer drivers it never needed.

Everything below follows from that.

Secure boot: a chain of trust from the silicon up

I have implemented secure boot the hard way, upstream, so I will be blunt about where the pain is: every silicon vendor establishes a root of trust differently, with different fuse provisioning and different signing toolchains, and stitching that into a build is weeks of work that does not transfer to the next board.

Avocado abstracts that behind one interface. Secure boot establishes an unbroken cryptographic chain from the silicon ROM through the bootloader, the kernel, the immutable root filesystem, and every signed extension. Each stage verifies the next before handing off, and if any link fails verification the device refuses to boot. The same command configures it regardless of the underlying hardware, with the CLI invoking the correct board-specific module to handle key management and signing.

Two things matter for real supply chains. Multiple signing authorities mean an OEM can control core system signing while a hardware partner signs their own driver extensions, neither party holding the other's keys, and the end-to-end chain still verifies. And fuse provisioning for OTP roots of trust is handled inside avocado provision as part of manufacturing, not as a separate manual step on the line. Because the same signing infrastructure runs in development and production, there is no late security-integration phase where everything suddenly breaks.

Filesystem integrity and hardware-backed encryption

Secure boot gets you to a trusted kernel. Two more layers keep the system trustworthy while it runs.

For integrity, Avocado uses dm-verity over a read-only SquashFS root. It does not check the filesystem once at boot; it verifies every block on every read against a Merkle hash tree built at build time, with the signed root hash anchored in the boot chain. A modification from any source, a tampering attempt or a bit flipped in storage, fails the read instead of executing corrupted code. On hardware with crypto acceleration the cost is effectively nothing, since blocks are verified on first read and cached after. Each extension carries its own hash tree and is verified independently, so a compromised application extension cannot reach the core OS or another extension. That isolation is structural, not a policy you hope holds.

For confidentiality, Avocado uses LUKS2 with AES-256-XTS on the writable BTRFS /var partition, where application data and device state live. The root stays integrity-protected rather than encrypted, because the OS is not the secret; the data is. Where the key lives is the part most implementations get wrong. When the hardware has a security module, Avocado seals the key inside it: a TPM releases it only when the boot chain is in a known-good state, an OP-TEE TrustZone TEE keeps it in the secure world, an NXP or NVIDIA enclave derives it from hardware-unique secrets that never leave the chip. Pull the storage media, mount it on another machine, and the data is inert — the key only exists inside the security module on the original device. For boards without one, an Argon2id derivation from device-specific inputs still puts extraction well beyond a guessed passphrase.

Updates you can actually deploy: atomic A/B with rollback

I maintained stable kernels with CVE backports for years, so I know the failure mode that matters most: teams stop shipping security patches when updates are risky. If pushing a fix might brick a device in the field, the fix waits, and the fleet stays vulnerable.

Avocado's update architecture is built so a bad update self-heals instead of bricking anything. It is a dual A/B partition scheme. The update is written entirely to the inactive slot while the active system keeps running. Signatures and the dm-verity hash tree are verified before anything switches. The commit is a single atomic flag flip, and on next boot the device runs a health check; if the new slot fails to boot or fails the check, the bootloader reverts to the last known-good slot automatically, with no manual intervention and no remote access required. Every step is power-loss safe, so a cellular dropout or a pulled power cable mid-update cannot leave a device unbootable.

Two more properties make this usable in the field. Updates are composable, so you can push a 50MB application extension instead of a 500MB monolithic image, and merging a system extension does not require a reboot. And OS-level updates support delta compression, sending only the binary difference over metered cellular, satellite, or LoRa links. This is the signed, verified, resilient update mechanism the CRA explicitly requires, and it is the reason you can deploy security patches the day they are ready instead of hoarding them.

CRA and SBOMs: the evidence problem, and the half Avocado OS owns

This is the part buyers ask about first, and it is the part I have spent the most time on, so let me save you the detour I see most teams take.

The CRA is a process and design regulation, not a scanner-selection problem. The framing every security vendor sells, run our scanner, triage, generate an SBOM, ship, does not satisfy it. Split your readiness into two halves and it gets clear fast. One half is build-derivable: the SBOM, the CVE reconciliation, the license manifest, the signing and update posture. The other half is vendor-committed: your coordinated vulnerability disclosure policy, your support-period end date, your single point of contact, your Declaration of Conformity. No tool can produce the second half, because those are sentences a manufacturer has to write, not files a build emits.

Avocado OS owns the build-derivable half by construction. Builds are deterministic, so an artifact is traceable to its exact source configuration and an auditor can reproduce it instead of trusting you. SBOM generation is part of the build, producing the machine-readable manifest the CRA requires. The immutable root delivers secure-by-default. The signed A/B update mechanism delivers the secure update requirement. And because packages are pre-built, when a CVE lands you patch the feed and rebuild in minutes, not in the hours a from-source Yocto rebuild would cost, which is what turns "vulnerability handling" from an aspiration into a cadence.

I will be precise about the claim, the same way I am in shipcheck: this is readiness, not certification. Avocado provides the technical controls the standards require, including the defense-in-depth that IEC 62443 expects and hardware-backed key storage for its higher security levels. It does not sign your Declaration of Conformity. That remains a human act against a completed technical file, and any vendor who tells you a tool makes you "CRA compliant" is selling you the wrong mental model.

Security and support: you do not carry the OS alone

Everything above is the security half. The support half is the rest of the sentence, and it is the part that decides whether security actually holds up over a product's life.

Production security is not a setup you finish. It is a commitment that runs for years, and on most teams it lands on people who never signed up to maintain an operating system. That is the work Peridio carries with you. We maintain the package feeds and publish patched versions when CVEs land, so vulnerability handling has a cadence instead of being whoever-notices-first. The base OS and the validated hardware integrations are backed with long-term support, so a kernel CVE at two in the morning is not solely your team's emergency. And for environments that require it, Avocado Connect deploys on-premise, behind your firewall, fully air-gapped, with the same update and provenance guarantees and no dependence on the public internet.

Having spent years as the person doing CVE backports across a fleet of targets, I can tell you exactly how much that matters. When the auditor asks for evidence, or a new class of vulnerability drops, you want a team whose whole job is the OS layer, so yours can stay on the product.

What security and support unlock for your team

Security and support is one of the three things Avocado 1.0 is built to prove, and what it unlocks depends on where you sit.

For the engineer, the security controls are available from day one, in development, not introduced in a late integration phase that breaks things right before ship. There is nothing to harden, because the system cannot be modified at runtime.

For the product lead, you can pass the security review and move toward the CRA without standing up a compliance program from scratch, which opens regulated, industrial, and defense-adjacent markets that were previously gated.

For the org, the OS layer's compliance and maintenance burden is carried with you, not dropped on a team hired to build a product. Deals stop stalling on security questionnaires, and a CVE stops being a fire drill.

Security as a property, not a phase. Built in from the first image, not bolted on before the last.

Why I am betting on this

You can start building today with a free developer account, running the same security controls in development that you will run in production.

I spent fifteen years watching teams treat security as the thing you scramble to add at the end, and I built tools to make that scramble less painful. Avocado is the first stack I have worked on that makes the scramble unnecessary, because the hard properties, verified boot, integrity, hardware-bound encryption, signed recoverable updates, a reproducible bill of materials, are present from the first build or they are not there at all. The compliance floor is rising, the CRA puts direct obligations on the OS layer in 2027, and the threat model for connected devices is not getting friendlier. None of that is answered by a hardening pass.

That is the standard the next decade of embedded products will be held to, and it is why I am here. Secure by construction is not a slogan. It is the only version of security that survives contact with production.

-Javier