Dominik Merli’s Engineering Secure Devices uses embedded security to teach
broader lessons about system integrity, device identity, and engineering
trade-offs. Its constrained systems make trust boundaries especially clear,
but its mental models also apply to containerized applications and cloud
runtimes.
The book’s treatment of secure boot, firmware updates, cryptographic
implementation, and hardware-anchored identity makes it a valuable addition
for practitioners interested in how integrity is engineered from the ground
up.
I wasn’t sufficiently aware of how PLC’s evolution from isolated microprocessor controllers, to networked devices, and now soft PLCs progressively imports conventional
computing attack surfaces into systems that still have hard real-time and physical-process constraints.
In PLC world, control logic executes in millisecond-scale scan cycles over sensor inputs and actuator outputs, mediated by
firmware, RTOS/runtime, I/O and network modules. Fieldbus protocols such as Modbus and PROFIBUS coexist with Ethernet, MQTT and OPC UA. Attacks consequently span
control-logic injection, CPU mode manipulation, firmware modification, runtime/OS compromise, network manipulation, and even I/O-based covert channels.
The SoK systematizes 17 years of PLC security research and finds that 82% of studied attacks require no knowledge of the physical environment. More interestingly, recovery
remains comparatively underdeveloped, while research is fragmented across vendors and increasingly between hard and soft PLCs.
Source review and reproducible builds alone cannot establish that a compiler binary faithfully implements its source. A trusting-trust attack can survive compiler upgrades
without appearing anywhere in the source tree.
Diverse Double-Compiling (DDC) addresses this by rebuilding the compiler source through an independently trusted compiler, then using that result to rebuild the compiler
again and comparing the resulting executable with the compiler under test. Assuming deterministic builds and sufficient toolchain diversity, equality provides evidence
that the executable corresponds to the reviewed source; divergence exposes either build nondeterminism, a defect, or possible subversion.
The thesis demonstrates this concretely with TCC: a compromised compiler reinfects its successor while also modifying cryptocurrency transaction code, and DDC detects the
subversion. More interestingly, attempts to extend the technique to GCC expose the practical problem: real build graphs quickly expand the trusted surface to assemblers,
linkers, loaders, OSes, firmware, and hardware.
ML provenance is not just software provenance with models added. The interesting problem is that datasets, code, configurations, weights, and execution environments are
coupled through transformations, while models can subsequently be fine-tuned or otherwise adapted. Atlas treats lineage as an authenticated chain of transformations rather
than simply an inventory of artifacts.
The individual mechanisms presented in the paper include Intel TDX, remote attestation, cryptographic measurements, C2PA manifests, and Merkle-tree transparency logs. What
I found interesting is their composition. An attestation client monitors PyTorch/Kubeflow execution, measures inputs and outputs, records runtime/configuration metadata,
and signs a transformation attestation containing hashes of precursor attestations. The transparency service makes these records tamper-evident; verification reconstructs
and validates the lineage.
More broadly, Atlas suggests that ML supply-chain integrity may require authenticating the transformation history, not merely signing the resulting model.
This isn’t just about reproducibility: it touches auditor trust, SBOM
completeness, and the future of supply chain assurance. Worth a skim if you
care about provable software integrity.
Automatic Bill of Materials (2023)
embeds source file hashes into binaries with compressed Bloom filters, making
it easy to check whether known-vulnerable code is present.
Remote Attestation with Constrained Disclosure
(2023) proposes a selective log disclosure mechanism for TPM-based
attestation. It uses non-interactive zero-knowledge (NIZK) proofs over IMA logs
to let systems prove integrity without revealing full software inventories.
The selective disclosure primitives introduced here are interesting beyond
privacy—for example, for fine-grained trust delegation across supply chains.
Here’s a modern classic:
Reflections on Trusting Distributed Trust
(2022) proposes an auditable deployment model using trusted execution
environments and append-only logs to solve distributed trust bootstrapping
without expensive cross-organization coordination.
I found it an approachable, practical read that is relevant to supply chain
integrity and multiparty, privacy-preserving computation.
Worth a read if you touch distributed systems and transparency in your work.