<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>José Miguel Parrella (JMP) - Posts</title>
      <link>https://jmp.soy/posts/</link>
      <description>José Miguel Parrella (JMP) is an open source technologist in Seattle focused on Linux, cloud computing, and software supply chain security.</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://jmp.soy/posts/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Sun, 06 Sep 2026 00:00:00 +0000</lastBuildDate>
      <item>
          <title>Notes: Practical Post-Quantum Cryptography for Bandwidth Constrained or Non-Terrestrial Networks, and Power Constrained Devices</title>
          <pubDate>Sun, 06 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/practical-post-quantum-cryptography-for-constrained-systems/</link>
          <guid>https://jmp.soy/posts/practical-post-quantum-cryptography-for-constrained-systems/</guid>
          <description xml:base="https://jmp.soy/posts/practical-post-quantum-cryptography-for-constrained-systems/">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2607.23007&quot;&gt;Read the paper on arXiv&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation</title>
          <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/trusting-trust-attack-against-an-entire-linux-distribution/</link>
          <guid>https://jmp.soy/posts/trusting-trust-attack-against-an-entire-linux-distribution/</guid>
          <description xml:base="https://jmp.soy/posts/trusting-trust-attack-against-an-entire-linux-distribution/">&lt;p&gt;The paper shows how Thompson-class attacks aren’t restricted to compilers by
tampering with &lt;code&gt;strip&lt;/code&gt; in the NixOS bootstrap seed. The malicious &lt;code&gt;strip&lt;/code&gt;
repurposes &lt;code&gt;PT_NOTE&lt;/code&gt; as &lt;code&gt;PT_LOAD&lt;/code&gt;, and the payload propagates into later
generations of &lt;code&gt;strip&lt;/code&gt; rebuilt from clean source. All but one binary in
&lt;code&gt;stdenv&lt;/code&gt; ends up infected, without breaking the build or functional tests.&lt;/p&gt;
&lt;p&gt;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?&lt;/p&gt;
&lt;p&gt;Really good read by Julien Malka, Stefano Zacchiroli, Martin Monperrus, and
their coauthors:
&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2607.24888&quot;&gt;read the July 2026 paper on arXiv&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Book review: Hack to the Future</title>
          <pubDate>Mon, 24 Aug 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/hack-to-the-future-book-review/</link>
          <guid>https://jmp.soy/posts/hack-to-the-future-book-review/</guid>
          <description xml:base="https://jmp.soy/posts/hack-to-the-future-book-review/">&lt;p&gt;Emily Crose’s &lt;em&gt;Hack to the Future: How World Governments Relentlessly Pursue
and Domesticate Hackers&lt;/em&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://cybercanon.org/hack-to-the-future-how-world-governments-relentlessly-pursue-and-domesticate-hackers/&quot;&gt;Read my full review on the Cybersecurity Canon&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: The End of Code Review: Coding Agents Supersede Human Inspection</title>
          <pubDate>Thu, 06 Aug 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/end-of-code-review-paper/</link>
          <guid>https://jmp.soy/posts/end-of-code-review-paper/</guid>
          <description xml:base="https://jmp.soy/posts/end-of-code-review-paper/">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2606.13175&quot;&gt;Link to paper&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Beyond Zero: Enterprise Security for the AI Era</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/beyond-zero-paper/</link>
          <guid>https://jmp.soy/posts/beyond-zero-paper/</guid>
          <description xml:base="https://jmp.soy/posts/beyond-zero-paper/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2605.22985&quot;&gt;Beyond Zero: Enterprise Security for the AI Era&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Grimlock: Guarding High-Agency Systems with eBPF and Attested Channels</title>
          <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/grimlock-paper/</link>
          <guid>https://jmp.soy/posts/grimlock-paper/</guid>
          <description xml:base="https://jmp.soy/posts/grimlock-paper/">&lt;p&gt;The core idea in &lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2605.27488&quot;&gt;Grimlock&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Book review: Infected</title>
          <pubDate>Mon, 22 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/infected-book-review/</link>
          <guid>https://jmp.soy/posts/infected-book-review/</guid>
          <description xml:base="https://jmp.soy/posts/infected-book-review/">&lt;p&gt;Bernardo Quintero’s &lt;em&gt;Infected&lt;/em&gt; 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.&lt;/p&gt;
&lt;p&gt;Its strongest themes include community building, disciplined entrepreneurship,
resource constraints, local talent, and innovation driven by curiosity and
conviction rather than capital and scale.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://cybercanon.org/infected/&quot;&gt;Read my full review on the Cybersecurity Canon&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: TIRA: Task-Based Intermittent Remote Attestation</title>
          <pubDate>Thu, 11 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/tira-paper/</link>
          <guid>https://jmp.soy/posts/tira-paper/</guid>
          <description xml:base="https://jmp.soy/posts/tira-paper/">&lt;p&gt;The most useful idea in &lt;a rel=&quot;external&quot; href=&quot;https://scholar.google.com/scholar_lookup?doi=10.1145/3774906.3802751&quot;&gt;TIRA: Task-Based Intermittent Remote Attestation&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Kettle: Attested Builds for Verifiable Software Provenance</title>
          <pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/kettle-paper/</link>
          <guid>https://jmp.soy/posts/kettle-paper/</guid>
          <description xml:base="https://jmp.soy/posts/kettle-paper/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2605.08363&quot;&gt;Kettle&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The broader lesson is that attestation can move build infrastructure outside the trust boundary—but verifier policy still determines which measured builders deserve trust.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Book review: Engineering Secure Devices</title>
          <pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/engineering-secure-devices-book-review/</link>
          <guid>https://jmp.soy/posts/engineering-secure-devices-book-review/</guid>
          <description xml:base="https://jmp.soy/posts/engineering-secure-devices-book-review/">&lt;p&gt;Dominik Merli’s &lt;em&gt;Engineering Secure Devices&lt;/em&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://cybercanon.org/engineering-secure-devices/&quot;&gt;Read my full review on the Cybersecurity Canon&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Agent runtime integrity and workload identity</title>
          <pubDate>Wed, 31 Dec 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/agent-runtime-integrity-and-workload-identity/</link>
          <guid>https://jmp.soy/posts/agent-runtime-integrity-and-workload-identity/</guid>
          <description xml:base="https://jmp.soy/posts/agent-runtime-integrity-and-workload-identity/">&lt;p&gt;I maintain
&lt;a rel=&quot;external&quot; href=&quot;https://github.com/bureado/awesome-agent-runtime-security&quot;&gt;Awesome Agent Runtime Security&lt;/a&gt;,
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.&lt;/p&gt;
&lt;p&gt;Related writing and resources:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.linkedin.com/pulse/notes-agent-runtime-security-integrity-execution-trust-parrella-t7rgc/&quot;&gt;Notes on Agent Runtime Security: Integrity, Execution, and Trust&lt;/a&gt; (2025)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://gist.github.com/bureado/71dfb7380e8a1cd7294c2f8b8136d085&quot;&gt;Accompanying resources&lt;/a&gt; (2025)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=BFAv_b46J6o&quot;&gt;Exploring Linux sandboxing with Island and Landlock&lt;/a&gt; (2025)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.linkedin.com/pulse/can-lessons-from-software-supply-chain-security-applied-parrella-p1ioc/&quot;&gt;Can Lessons from Software Supply Chain Security Be Applied to MCP?&lt;/a&gt; (2025)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://gist.github.com/bureado/08f02136bba64ad528bacbf819c1c648&quot;&gt;Reading list: confidential computing&lt;/a&gt; (2024)&lt;/li&gt;
&lt;/ul&gt;
</description>
      </item>
      <item>
          <title>Software supply chain security</title>
          <pubDate>Wed, 31 Dec 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/software-supply-chain-security/</link>
          <guid>https://jmp.soy/posts/software-supply-chain-security/</guid>
          <description xml:base="https://jmp.soy/posts/software-supply-chain-security/">&lt;p&gt;I maintain &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bureado/awesome-software-supply-chain-security/&quot;&gt;Awesome Software Supply Chain Security&lt;/a&gt;, a popular and
comprehensive reference of tools, trends, and challenges in the software supply chain security.&lt;/p&gt;
&lt;p&gt;I’ve built Linux distributions of various sizes, from a consumer-focused one
that has &lt;a rel=&quot;external&quot; href=&quot;https://wiki.debian.org/Derivatives/Census/Canaima&quot;&gt;millions of end users&lt;/a&gt;
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.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.linkedin.com/pulse/year-innovations-insights-software-supply-chain-jose-miguel-parrella-ndjyc/&quot;&gt;A Year of Innovations and Insights in Software Supply Chain Security&lt;/a&gt; (2024)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=tH8DGVzxbPc&quot;&gt;Popular dependency acquisition patterns in containers&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=Rv4ZlbMb1pE&quot;&gt;Traversing deb packages upstream provenance and downstream integrity&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://gist.github.com/bureado/792037b71229db3c37975e70e8a9c54a&quot;&gt;Post-modern Linux packaging: additional reading&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
      </item>
      <item>
          <title>Earlier works</title>
          <pubDate>Tue, 30 Dec 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/earlier-works/</link>
          <guid>https://jmp.soy/posts/earlier-works/</guid>
          <description xml:base="https://jmp.soy/posts/earlier-works/">&lt;p&gt;Most of my writing lives in &lt;a rel=&quot;external&quot; href=&quot;https://gist.github.com/bureado&quot;&gt;GitHub Gists&lt;/a&gt; or
LinkedIn Articles. I have presented at several conferences from Argentina to
Tunisia, with slides often available on
&lt;a rel=&quot;external&quot; href=&quot;https://speakerdeck.com/bureado&quot;&gt;Speaker Deck&lt;/a&gt;. Here are some selected earlier
works:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=LfyaMABZWpw&quot;&gt;The Role of Customer-partner-vendor Collaboration in Enterprise Open Source Strategy&lt;/a&gt; (2020)&lt;/li&gt;
&lt;li&gt;Global audience poll on &lt;a rel=&quot;external&quot; href=&quot;https://dev.to/bureado/open-source-sustainability-is-a-debate-37p1&quot;&gt;open source sustainability&lt;/a&gt; with &lt;a rel=&quot;external&quot; href=&quot;https://gist.github.com/bureado/5e2152ac6e6a8d920baeb5f2678b97d3&quot;&gt;findings&lt;/a&gt; (2019)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321391.html&quot;&gt;Deploying Linux to the cloud&lt;/a&gt; at OSCON 2018&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Package-Management-and-Distribution-in-a-Cloud-World-OSS-Jose-Miguel-Parrella.pdf&quot;&gt;Package Management and Distribution in a Cloud World&lt;/a&gt; at Open Source Summit Japan 2017 in Tokyo&lt;/li&gt;
&lt;li&gt;Interview: &lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=He-4JIPDYvo&quot;&gt;Red Hat + Microsoft partnership&lt;/a&gt; at Red Hat Summit 2016&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=UMIayCY4_Xo&quot;&gt;End to end Node.js app development in the cloud&lt;/a&gt; at Node Live 2016 in Beijing&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://www.alphagamma.eu/entrepreneurship/enterprises-cannot-survive-without-open-source/&quot;&gt;Enterprises cannot survive without open source. Here’s why.&lt;/a&gt; (2016)&lt;/li&gt;
&lt;li&gt;&lt;a rel=&quot;external&quot; href=&quot;https://medium.com/@bureado/from-open-ecosystem-to-open-ambient-ab4a16d56687&quot;&gt;From open ecosystem to open ambient&lt;/a&gt; (2016)&lt;/li&gt;
&lt;/ul&gt;
</description>
      </item>
      <item>
          <title>Notes: Atlas: A Framework for ML Lifecycle Provenance &amp; Transparency</title>
          <pubDate>Sun, 23 Nov 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/atlas-paper/</link>
          <guid>https://jmp.soy/posts/atlas-paper/</guid>
          <description xml:base="https://jmp.soy/posts/atlas-paper/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2502.19567&quot;&gt;Atlas: A Framework for ML Lifecycle Provenance &amp;amp; Transparency&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;More broadly, Atlas suggests that ML supply-chain integrity may require authenticating the &lt;em&gt;transformation history&lt;/em&gt;, not merely signing the resulting model.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Rosencrantz on Diverse Double-Compiling</title>
          <pubDate>Sun, 23 Nov 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/ddc4cc-paper/</link>
          <guid>https://jmp.soy/posts/ddc4cc-paper/</guid>
          <description xml:base="https://jmp.soy/posts/ddc4cc-paper/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;http://kth.diva-portal.org/smash/record.jsf?pid=diva2:1737190&quot;&gt;Diverse Double-Compiling to Harden Cryptocurrency Software&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: SoK: Security of Programmable Logic Controllers</title>
          <pubDate>Sun, 23 Nov 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/sok-plc-paper/</link>
          <guid>https://jmp.soy/posts/sok-plc-paper/</guid>
          <description xml:base="https://jmp.soy/posts/sok-plc-paper/">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2403.00280&quot;&gt;SoK: Security of Programmable Logic Controllers&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Automatic Bill of Materials and runtime SBOM enforcement</title>
          <pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/automatic-bill-of-materials-and-runtime-sbom-enforcement/</link>
          <guid>https://jmp.soy/posts/automatic-bill-of-materials-and-runtime-sbom-enforcement/</guid>
          <description xml:base="https://jmp.soy/posts/automatic-bill-of-materials-and-runtime-sbom-enforcement/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2310.09742&quot;&gt;&lt;em&gt;Automatic Bill of Materials&lt;/em&gt;&lt;/a&gt; (2023)
embeds source file hashes into binaries with compressed Bloom filters, making
it easy to check whether known-vulnerable code is present.&lt;/p&gt;
&lt;p&gt;It’s a great read alongside
&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2407.00246&quot;&gt;&lt;em&gt;SBOM.EXE: Countering Dynamic Code Injection based on Software Bill of Materials in Java&lt;/em&gt;&lt;/a&gt;
(2024), which proposes an index built with bytecode canonicalization and a JVM
watchdog agent to make the SBOM an enforceable runtime contract.&lt;/p&gt;
&lt;p&gt;This is also a great opportunity to mention
&lt;a rel=&quot;external&quot; href=&quot;https://devblogs.microsoft.com/java/building-a-runtime-jar-inspector-in-10-hours/&quot;&gt;Building a Runtime JAR Inspector in 10 Hours&lt;/a&gt;
from Bruno Borges and team.&lt;/p&gt;
&lt;p&gt;The themes connect to runtime integrity checks, dependency-aware enforcement,
and SBOM and evidence portability. It’s also worth giving a fresh read to
&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2402.08980&quot;&gt;&lt;em&gt;OmniBOR: A System for Automatic, Verifiable Artifact Resolution across Software Supply Chains&lt;/em&gt;&lt;/a&gt;
(2024).&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Producing Verifiable Builds for Large-Scale Commercial Systems</title>
          <pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/producing-verifiable-builds-for-large-scale-commercial-systems/</link>
          <guid>https://jmp.soy/posts/producing-verifiable-builds-for-large-scale-commercial-systems/</guid>
          <description xml:base="https://jmp.soy/posts/producing-verifiable-builds-for-large-scale-commercial-systems/">&lt;p&gt;While reviewing practical lessons on verifiable builds, I read
&lt;a rel=&quot;external&quot; href=&quot;https://www.researchgate.net/publication/352806306_An_Experience_Report_on_Producing_Verifiable_Builds_for_Large-Scale_Commercial_Systems&quot;&gt;&lt;em&gt;An Experience Report on Producing Verifiable Builds for Large-Scale Commercial Systems&lt;/em&gt;&lt;/a&gt;
(2021), which focuses on catching nondeterminism with intercept-and-ignore
lists, explaining what can’t be fixed, and systematizing it into a repeatable
process.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Trust in Software Supply Chains: Blockchain-Enabled SBOM and the AIBOM Future</title>
          <pubDate>Sat, 06 Sep 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/blockchain-enabled-sbom-and-the-aibom-future/</link>
          <guid>https://jmp.soy/posts/blockchain-enabled-sbom-and-the-aibom-future/</guid>
          <description xml:base="https://jmp.soy/posts/blockchain-enabled-sbom-and-the-aibom-future/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://dl.acm.org/doi/10.1145/3643662.3643957&quot;&gt;&lt;em&gt;Trust in Software Supply Chains: Blockchain-Enabled SBOM and the AIBOM Future&lt;/em&gt;&lt;/a&gt;
(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.&lt;/p&gt;
&lt;p&gt;Worth a read if you touch SBOMs or decentralized trust models in your work.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Lightweight certificate revocation for low-power IoT with end-to-end security</title>
          <pubDate>Sat, 06 Sep 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/lightweight-certificate-revocation-for-low-power-iot/</link>
          <guid>https://jmp.soy/posts/lightweight-certificate-revocation-for-low-power-iot/</guid>
          <description xml:base="https://jmp.soy/posts/lightweight-certificate-revocation-for-low-power-iot/">&lt;p&gt;A few months ago I ran across
&lt;a rel=&quot;external&quot; href=&quot;https://www.sciencedirect.com/science/article/pii/S2214212623000091&quot;&gt;&lt;em&gt;Lightweight certificate revocation for low-power IoT with end-to-end security&lt;/em&gt;&lt;/a&gt;
(2023), a proposal to make PKI-style revocation viable in constrained devices
using slimmed-down, CBOR-based TinyOCSP and compressed Bloom filters.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Reflections on Trusting Distributed Trust</title>
          <pubDate>Sat, 06 Sep 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/reflections-on-trusting-distributed-trust/</link>
          <guid>https://jmp.soy/posts/reflections-on-trusting-distributed-trust/</guid>
          <description xml:base="https://jmp.soy/posts/reflections-on-trusting-distributed-trust/">&lt;p&gt;Here’s a modern classic:
&lt;a rel=&quot;external&quot; href=&quot;https://arxiv.org/abs/2210.08127&quot;&gt;&lt;em&gt;Reflections on Trusting Distributed Trust&lt;/em&gt;&lt;/a&gt;
(2022) proposes an auditable deployment model using trusted execution
environments and append-only logs to solve distributed trust bootstrapping
without expensive cross-organization coordination.&lt;/p&gt;
&lt;p&gt;I found it an approachable, practical read that is relevant to supply chain
integrity and multiparty, privacy-preserving computation.&lt;/p&gt;
&lt;p&gt;Worth a read if you touch distributed systems and transparency in your work.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Notes: Remote Attestation with Constrained Disclosure</title>
          <pubDate>Sat, 06 Sep 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://jmp.soy/posts/remote-attestation-with-constrained-disclosure/</link>
          <guid>https://jmp.soy/posts/remote-attestation-with-constrained-disclosure/</guid>
          <description xml:base="https://jmp.soy/posts/remote-attestation-with-constrained-disclosure/">&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://dl.acm.org/doi/10.1145/3627106.3627118&quot;&gt;&lt;em&gt;Remote Attestation with Constrained Disclosure&lt;/em&gt;&lt;/a&gt;
(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.&lt;/p&gt;
&lt;p&gt;The selective disclosure primitives introduced here are interesting beyond
privacy—for example, for fine-grained trust delegation across supply chains.&lt;/p&gt;
</description>
      </item>
    </channel>
</rss>
