José Miguel Parrella (JMP) - Posts

[Notes] Attested Builds and Layered Attestations

Unknown — Fri, 09 Oct 2026 00:00:00 +0000

Attestable Builds: Compiling Verifiable Binaries on Untrusted Systems using Trusted Execution Environments by Hugenroth et al. and Full Trust Alchemist: Reforging Attestation for Cloud-based Confidential Workloads by Galanou et al. explore complementary approaches to hardware-rooted software build provenance. They explain how attesting the initial execution environment does not establish which inputs were consumed, what code executed, or how the resulting artifacts were produced. Both approaches can support verifiable provenance without reproducible builds.

Hugenroth et al. isolate a trusted observer inside a TEE (AWS Nitro Enclaves) from sandboxed, untrusted build execution, binding declared inputs and output digests to attestation evidence. Galanou et al. extend runtime attestation using eBPF/LSM enforcement, IMA measurements, and protected evidence recording inside an AMD SEV-SNP confidential VM. Their policy-driven architecture captures build inputs, execution events, and configuration changes, linking artifacts and SBOMs to hardware-backed evidence without requiring changes to existing build toolchains. They exemplify two approaches to extend the HW RoT to runtime: Hugenroth minimizes the trusted observer while isolating build execution; Galanou protects the mechanisms that enforce policies and record runtime state.

This connects the build provenance problem in Kettle with the architectural concern in Designing Trustworthy Layered Attestations: the mechanisms that observe execution and produce evidence must themselves be protected. For attested builds, the layers need to connect the measured environment to a trustworthy observer, the build’s inputs and execution, and ultimately its output artifacts.

[Notes] Designing Trustworthy Layered Attestations

Unknown — Sun, 27 Sep 2026 00:00:00 +0000

Designing Trustworthy Layered Attestations discusses how the attestation mechanism itself as part of the threat model in attested systems.

Protecting an attestation signing key against extraction is insufficient if a compromised component can still invoke it to endorse fabricated evidence. The authors propose TPM policy and locality-based authorization, and recommend Linux/SELinux changes to bind TPM commands to particular security contexts. Similarly, moving LKIM outside the kernel being measured can remove problematic cyclic trust relationships between measurer and measured system.

This generalizes nicely beyond runtime attestation. For example, for attested builds (see Kettle), a constrained builder with bounded inputs, short-lived workers, limited interactions, and policy-enforced execution is fundamentally easier to make meaningful claims about than a generic CI runner supporting arbitrary execution and persistent state.

Readers interested in this topic may also find the Framework for Continuous Remote Attestation draft a useful read.

[Notes] SessionLatch: Attested TLS for Confidential Virtual Machines

Unknown — Thu, 24 Sep 2026 00:00:00 +0000

Paper

While TLS authenticates a service identity and attestation tells you an environment is approved, clients can’t be certain that the TLS session actually in use terminates in the expected environment. SessionLatch proposes using a trusted observer inside CVMs to prove session-endpoint correspondence.

This observer produces TEE-bound evidence which clients can fetch via a separate control channel as the handshake proceeds, holding (latching) client encrypted records until the evidence verifies and frees up the data path.

The Linux implementation relies on a userspace observer using SOCK_DIAG, nftables/NFQUEUE and other OS facilities. A measured/enforced eBPF or similar kernel mechanism could potentially provide a stronger reference monitor and bind the session to richer workload identity.

More broadly, the paper illustrates why endpoint attestation becomes harder as the TEE boundary expands from process enclaves to entire confidential VMs.

[Notes] Agent Security Is a Systems Problem

Unknown — Sun, 20 Sep 2026 00:00:00 +0000

I recently went over two articles from March-May 2026 that highlight how we must always assume that aligned models can make unexpected decisions. Perplexity’s Security Considerations for Artificial Intelligence Agents develops a layered defense strategy; Christodorescu et al.’s Agent Security Is a Systems Problem treats the model as untrusted and enforce security invariants outside it.

A boundary that holds only when the model correctly interprets an instruction or recognizes an attack is a behavioral expectation, not an enforceable restriction. Moving enforcement outside the model is necessary, but letting the same untrusted model freely define its own policy would recreate the original dependency. The articles recognize open research problems including verifiable translation of user’s intent from natural language into enforceable constraints.

Taking the untrusted model assumption seriously changes how we design agents. A model-generated tool call is a request for authority, not proof of authorization. These requirements become harder when the workflow itself emerges at runtime, rather than following a program whose resource needs are known in advance. There are excellent analogies in here for people working on code integrity, particularly dynamic/JITted code security.

Related designs explore how to enforce these boundaries: aflock places authorization and evidence generation in an external MCP server, while Grimlock uses eBPF-mediated sandbox boundaries and attested channels to enforce identity and constrain delegation outside agent code. Many of the projects I’m tracking in the bureado/awesome-agent-runtime-security collection are attempting to tackle this angle.

[Notes] AIBoMGen: Generating an AI Bill of Materials for Secure, Transparent, and Compliant Model Training

Unknown — Sat, 12 Sep 2026 00:00:00 +0000

In AIBoMGen: Generating an AI Bill of Materials for Secure, Transparent, and Compliant Model Training, a controlled training platform observes datasets, configuration, environment, and artifacts as the job executes, then hashes the artifacts and produces signed AIBOM and in-toto evidence.

AIBoMGen makes that possible by restricting the training environment. Users provide inputs and parameters rather than arbitrary code or shell access, allowing the platform to remain an independent observer of a constrained workflow. This limits generality and leaves trust in the platform, workers, signing keys, containers, and cloud control plane, but demonstrates a broader principle: trustworthy provenance may require constraining execution enough that evidence generation cannot simply be bypassed.

For a related approach to authenticating ML transformation history with hardware-backed attestation and transparency logs, see my notes on Atlas.

[Notes] Practical Post-Quantum Cryptography for Bandwidth Constrained or Non-Terrestrial Networks, and Power Constrained Devices

Unknown — Sun, 06 Sep 2026 00:00:00 +0000

The core takeaway is that many systems already have a shared secret anchored in trusted hardware, such as a SIM or TPM, and infrastructure that already knows how to derive and manage keys from it.

The authors propose reusing that existing trust: derive an application-specific secret, make it available through a KDC and trusted transfer agent, use it for TLS or DTLS PSK authentication—otherwise the dominant source of resource consumption and handshake unreliability—and keep ML-KEM for ephemeral post-quantum key establishment and forward secrecy.

This avoids dragging large post-quantum certificates and signatures across constrained devices and lossy links. The authors observed about 70% less handshake bandwidth and roughly one-third the energy consumption. The broader takeaway is that, in some scenarios, post-quantum readiness may not require rebuilding the authentication stack if the system already has a scalable symmetric root of trust.

Read the paper on arXiv. And for a related look at reducing PKI overhead on constrained devices, see my notes on lightweight certificate revocation for low-power IoT.

[Notes] Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation

Unknown — Sun, 30 Aug 2026 00:00:00 +0000

The paper shows how Thompson-class attacks aren’t restricted to compilers by tampering with strip in the NixOS bootstrap seed. The malicious strip repurposes PT_NOTE as PT_LOAD, and the payload propagates into later generations of strip rebuilt from clean source. All but one binary in stdenv ends up infected, without breaking the build or functional tests.

I walked away thinking about diverse artifact structure verification: population-level artifact checks run from independent trust roots, with independently built parsers and tooling. Could we come up with a stable ELF morphology of a distribution and use that to detect a coordinated structural shift across thousands of unrelated binaries?

For a related approach to detecting compiler subversion, see my notes on Rosencrantz’s Diverse Double-Compiling (DDC), including the challenges of extending verification across a real build graph.

Really good read by Julien Malka, Stefano Zacchiroli, Martin Monperrus, and their coauthors: read the July 2026 paper on arXiv.

[Book review] Hack to the Future

Unknown — Mon, 24 Aug 2026 00:00:00 +0000

Emily Crose’s Hack to the Future: How World Governments Relentlessly Pursue and Domesticate Hackers traces hacker culture from exploratory experimentation to a foundational role in modern cybersecurity. It examines how governments, corporations, and society shifted from treating hackers primarily as criminals to recognizing their value in security, innovation, and national strategy.

The book provides useful context for understanding the origins of penetration testing, vulnerability research, responsible disclosure, and the complicated relationship between independent researchers and institutions.

Read my full review on the Cybersecurity Canon.

[Notes] The End of Code Review: Coding Agents Supersede Human Inspection

Unknown — Thu, 06 Aug 2026 00:00:00 +0000

The core argument is that coding agents have crossed the threshold where mandatory human code review is no longer economically justified. Human review consumes an estimated 10–15% of developer time, and scaling code generation while keeping humans as the approval gate simply moves the bottleneck downstream.

Readers might find the implication for SCM architecture most interesting. GitHub/GitLab-like platforms may need first-class agent identities, cryptographically attributable actions, specialized permissions, structured findings and confidence, and machine-readable review artifacts—not agents impersonating humans through comment threads. Agent review also seems better described as auditable and replayable than deterministic.

This suggests code review may evolve from a human synchronization gate into continuous agentic assurance, with human inspection becoming a risk-based escalation path in some scenarios.

Link to paper.

[Notes] Fine-Grained Traceability for Transparent ML Pipelines

Unknown — Tue, 14 Jul 2026 00:00:00 +0000

Fine-Grained Traceability for Transparent ML Pipelines (Chen, Liu, Fayek)

The key idea in FG-Trac is the distinction between explainability and operational traceability. Influence methods such as TracInCP can retrospectively estimate how training samples affect predictions, but they do not establish when, where, and under which model state those samples actually participated. FG-Trac instruments the ML pipeline itself, recording sample lifecycle events and binding checkpoint-based influence scores to those events.

These records are committed through Merkle trees, with detailed encrypted logs kept off-chain and only constant-sized roots anchored on-chain. This lets a user trace a pseudonymous sample through training, inspect its positive or negative influence, and cryptographically verify that the resulting history has not been modified.

The important limitation is that the commitment proves integrity of the recorded history, not completeness or truthfulness of its creation; a malicious operator could bypass instrumentation before commitment. Hardware-backed attestation or TEEs could strengthen that boundary.

For a related approach combining hardware-backed attestation and transparency logs to authenticate ML transformation history, see my notes on Atlas.

[Notes] Beyond Zero: Enterprise Security for the AI Era

Unknown — Mon, 06 Jul 2026 00:00:00 +0000

Beyond Zero: Enterprise Security for the AI Era establishes that the application is no longer a sufficient trust boundary. Beyond Zero pushes authorization down to individual actions on individual resources, with contextual risk decisions running at machine speed. What’s new since BeyondCorp is fusing static authorization guarantees with dynamic AI reasoning without turning security into a fully probabilistic system.

The mechanism is essentially a continuous feedback loop: an enterprise security world model precomputes context about users, agents, roles, resources, and expected work; event intake adds endpoint, server, and agent signals, including prompts, plans, and tool invocations; a hierarchical reasoning engine then feeds allow, deny, challenge, or containment decisions directly back into authorization. Expensive inference is front-loaded so thousands of decisions per second can remain low-latency.

This also collapses the traditional separation between access management and security operations: investigations can happen continuously and immediately change the actor’s “access bubble.” Challenges add granular friction under ambiguity; containments contract authority when risk increases. More broadly, this suggests that machine-speed agentic systems may require security to become a closed-loop authorization system rather than a monitoring layer around applications.

[Notes] Grimlock: Guarding High-Agency Systems with eBPF and Attested Channels

Unknown — Mon, 06 Jul 2026 00:00:00 +0000

The core idea in Grimlock is separation of concerns for high-agency systems: agent code handles orchestration, while the sandbox substrate enforces identity, authentication, authorization, provenance, and least-privilege delegation. Much of this is established security architecture; what I found interesting is how the pieces are composed while leaving agent code unchanged.

eBPF provides no-bypass, application-transparent mediation at the sandbox boundary and associates ordinary socket flows with stable sandbox identities. Guard-to-guard communication uses TLS 1.3 with kTLS for the data plane, allowing authentication context and longer-lived channels to amortize setup costs.

Post-handshake attestation is of special note. TLS exporters bind fresh TEE evidence to an already-established channel, including nonce, audience, and requested delegation scope. Successful appraisal produces short-lived, channel-bound Scope Tokens that the destination guard revalidates before releasing plaintext to the destination sandbox.

[Book review] Infected

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Bernardo Quintero’s Infected tells how a simple idea grew into VirusTotal, then into a company, and eventually into a globally recognized security capability acquired by Google. More than a corporate timeline, it explores how curiosity, community building, and entrepreneurial persistence shaped both Quintero’s career and a cornerstone of modern malware analysis.

Its strongest themes include community building, disciplined entrepreneurship, resource constraints, local talent, and innovation driven by curiosity and conviction rather than capital and scale.

Read my full review on the Cybersecurity Canon.

[Notes] TIRA: Task-Based Intermittent Remote Attestation

Unknown — Thu, 11 Jun 2026 00:00:00 +0000

The most useful idea in TIRA: Task-Based Intermittent Remote Attestation is not that intermittent systems can be made task-based, or that remote attestation can hash code and report a digest. What is interesting is the way the paper treats the task abstraction itself as the unit of attestable progress.

The mechanism is a compiler/runtime co-design. Programmer-defined idempotent tasks are instrumented with software fault isolation; unsafe memory writes and control-flow transfers are mediated through a Trusted Compute Module; a protected bootloader establishes static attestation at boot; and successful task transitions, interrupt evidence, and mutable memory effects are folded into a cryptographically chained execution log.

The reported overheads are practical enough to make the design worth studying: about 18% runtime overhead and 4% code-size overhead on average. More broadly, the paper suggests that in some constrained systems, the right attestation boundary may be the application’s execution abstraction, not just the boot image or hardware root.

[Notes] Kettle: Attested Builds for Verifiable Software Provenance

Unknown — Mon, 01 Jun 2026 00:00:00 +0000

Kettle turns build provenance from an assertion into hardware-rooted evidence. It runs builds inside a measured confidential VM, records source, resolved dependencies, toolchain, environment, and output digests as SLSA/in-toto provenance, then commits the provenance hash into the TEE attestation report. Verification becomes an attestation check plus digest comparisons rather than trusting CI infrastructure or reproducing the build.

The interesting part is the composition: Kettle reproducibly builds its own CVM image, providing a way to derive the expected launch measurement; uses a Merkle commitment over build inputs; and can optionally attest the CVM before confidentially delivering source. Reproducibility answers whether another build produces the same bytes; attestation proves that one measured environment actually observed specific inputs and produced specific bytes.

The broader lesson is that attestation can move build infrastructure outside the trust boundary—but verifier policy still determines which measured builders deserve trust.

For a related approach to ML provenance, see my notes on Atlas, which combines attestation and transparency logs to authenticate a model’s transformation history.

[Notes] Verifiable Provenance of Software Artifacts with Zero-Knowledge Compilation

Unknown — Tue, 14 Apr 2026 00:00:00 +0000

Paper

The interesting idea here is shifting software provenance from reproducing or trusting a build to cryptographically verifying the computation itself. Reproducible builds effectively say “repeat my computation”; TEE-based systems attest that trusted hardware performed it. COSMICTURTLE instead runs compilation inside the RISC Zero zkVM and produces the binary plus a succinct proof binding the claimed source, compiler, and output.

The prototype runs unmodified ChibiCC and successfully zk-compiles 252 C programs, including OpenSSL and libsodium source files. Adversarial tests reject compiler substitution, source or binary tampering, and replay. This is still far from proving an industrial GCC/LLVM build graph, but it suggests that software provenance can be dealt with as a verifiable-computation problem rather than primarily a reproducibility or hardware-attestation problem.

[Notes] aflock: Cryptographically Signed Policies for Constrained AI Agent Execution

Unknown — Sun, 29 Mar 2026 00:00:00 +0000

aflock applies familiar ideas from SPIFFE/SPIRE, in-toto, capability systems, and policy engines to agent execution. Rather than trusting an agent to report its own behavior, aflock moves authorization and evidence generation into an external MCP server. Agent identity is derived from introspectable properties; short-lived JWTs convey authority; and the server signs attestations with keys the agent never sees.

Policies can constrain individual actions and cumulative properties of an execution trajectory. Session attestations are committed through a Merkle tree to provide ordering and completeness evidence, while Rego evaluates cross-attestation constraints. Hierarchical sub-agent delegation uses in-toto-style sublayouts with mandatory attenuation, so delegated authority cannot exceed the parent’s constraints.

The broader systems principle is compelling: securing autonomous agents may require treating execution trajectories much like software supply chains—externally constrained, cryptographically recorded, and recursively verifiable—rather than relying on the agent itself to enforce or describe its boundaries.

[Notes] Fortress: Securing IoT Peripherals with Trusted Execution Environments

Unknown — Sat, 28 Mar 2026 00:00:00 +0000

Fortress: Securing IoT Peripherals with Trusted Execution Environments (Peterson Yuhala, Jämes Ménétrey, Pascal Felber, Marcelo Pasin, Valerio Schiavoni)

The motivation in Fortress is to extend the trust boundary from TrustZone to peripherals. MMIO/DMA regions are assigned to the secure world, and the driver is partitioned so that code touching sensitive data executes in OP-TEE’s secure kernel. Data then flows through a PTA to a user-space TA for filtering or encryption before being released to the untrusted OS or cloud. This can help protect sensor data from a compromised OS or hypervisor. Direct MMIO has little overhead; the expensive part is crossing protection boundaries with buffers—up to orders of magnitude slower in their evaluation. The broader lesson is that confidential execution alone may be insufficient when plaintext inputs traverse privileged, untrusted software before reaching the TEE.

[Book review] Engineering Secure Devices

Unknown — Mon, 02 Mar 2026 00:00:00 +0000

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.

Read my full review on the Cybersecurity Canon.

Agent runtime integrity and workload identity

Unknown — Wed, 31 Dec 2025 00:00:00 +0000

I maintain Awesome Agent Runtime Security, a Linux-focused curation of long-form writing, specifications, and technologies at varying levels of maturity. It collects approaches to kernel- and hypervisor-enforced agent isolation, secrets injection, and deriving credentials from an agent’s measured state.

Related writing and resources:

Notes on Agent Runtime Security: Integrity, Execution, and Trust (2025)
Accompanying resources (2025)
Exploring Linux sandboxing with Island and Landlock (2025)
Can Lessons from Software Supply Chain Security Be Applied to MCP? (2025)
Reading list: confidential computing (2024)

Software supply chain security

Unknown — Wed, 31 Dec 2025 00:00:00 +0000

I maintain Awesome Software Supply Chain Security, a popular and comprehensive reference of tools, trends, and challenges in the software supply chain security.

I’ve built Linux distributions of various sizes, from a consumer-focused one that has millions of end users to custom-built Linux desktop distributions for the enterprise. From there, I transitioned to researching how distribution package management, release cadence, and security are relevant to the open source software supply chain problem.

Earlier works

Unknown — Tue, 30 Dec 2025 00:00:00 +0000

Most of my writing lives in GitHub Gists or LinkedIn Articles. I have presented at several conferences from Argentina to Tunisia, with slides often available on Speaker Deck. Here are some selected earlier works:

The Role of Customer-partner-vendor Collaboration in Enterprise Open Source Strategy (2020)
Global audience poll on open source sustainability with findings (2019)
Deploying Linux to the cloud at OSCON 2018
Package Management and Distribution in a Cloud World at Open Source Summit Japan 2017 in Tokyo
Interview: Red Hat + Microsoft partnership at Red Hat Summit 2016
End to end Node.js app development in the cloud at Node Live 2016 in Beijing
Enterprises cannot survive without open source. Here’s why. (2016)
From open ecosystem to open ambient (2016)

[Notes] Atlas: A Framework for ML Lifecycle Provenance & Transparency

Unknown — Sun, 23 Nov 2025 00:00:00 +0000

Atlas: A Framework for ML Lifecycle Provenance & Transparency

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.

[Notes] Rosencrantz on Diverse Double-Compiling

Unknown — Sun, 23 Nov 2025 00:00:00 +0000

Diverse Double-Compiling to Harden Cryptocurrency Software

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.

[Notes] SoK: Security of Programmable Logic Controllers

Unknown — Sun, 23 Nov 2025 00:00:00 +0000

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.

SoK: Security of Programmable Logic Controllers

[Notes] Automatic Bill of Materials and runtime SBOM enforcement

Unknown — Mon, 06 Oct 2025 00:00:00 +0000

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.

It’s a great read alongside SBOM.EXE: Countering Dynamic Code Injection based on Software Bill of Materials in Java (2024), which proposes an index built with bytecode canonicalization and a JVM watchdog agent to make the SBOM an enforceable runtime contract.

This is also a great opportunity to mention Building a Runtime JAR Inspector in 10 Hours from Bruno Borges and team.

The themes connect to runtime integrity checks, dependency-aware enforcement, and SBOM and evidence portability. It’s also worth giving a fresh read to OmniBOR: A System for Automatic, Verifiable Artifact Resolution across Software Supply Chains (2024).

[Notes] Producing Verifiable Builds for Large-Scale Commercial Systems

Unknown — Mon, 06 Oct 2025 00:00:00 +0000

While reviewing practical lessons on verifiable builds, I read An Experience Report on Producing Verifiable Builds for Large-Scale Commercial Systems (2021), which focuses on catching nondeterminism with intercept-and-ignore lists, explaining what can’t be fixed, and systematizing it into a repeatable process.

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.

[Notes] Trust in Software Supply Chains: Blockchain-Enabled SBOM and the AIBOM Future

Unknown — Sat, 06 Sep 2025 00:00:00 +0000

Trust in Software Supply Chains: Blockchain-Enabled SBOM and the AIBOM Future (2024) proposes a decentralized, selective SBOM disclosure system using verifiable credentials and zero-knowledge proofs to address the tension between software supply chain transparency and proprietary confidentiality.

Worth a read if you touch SBOMs or decentralized trust models in your work.

[Notes] Lightweight certificate revocation for low-power IoT with end-to-end security

Unknown — Sat, 06 Sep 2025 00:00:00 +0000

A few months ago I ran across Lightweight certificate revocation for low-power IoT with end-to-end security (2023), a proposal to make PKI-style revocation viable in constrained devices using slimmed-down, CBOR-based TinyOCSP and compressed Bloom filters.

Revocation isn’t just an IoT issue. It connects to many topics, from membership proofs—à la Automatic Bill of Materials—to transparency log auditing. I liked that this paper goes all the way down to practical implementation details but still takes time to introduce basic concepts for the reader.

[Notes] Reflections on Trusting Distributed Trust

Unknown — Sat, 06 Sep 2025 00:00:00 +0000

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.

[Notes] Remote Attestation with Constrained Disclosure

Unknown — Sat, 06 Sep 2025 00:00:00 +0000

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.