Supply Chain Trust

Every time you install software, you're trusting a chain of strangers: the developer who wrote the code, the maintainer who accepted the pull request, the build system that compiled it, the package manager that delivered it, and the mirror that hosted it. Break any link and you're running someone else's code. The history of software security is largely the history of this chain being too long, too opaque, and too fragile — and of increasingly sophisticated attempts to make it less so.

The Event-Stream Problem

The attack that haunts software supply chain discussions happened in 2018. A hacker offered to take over maintenance of event-stream, a widely-used npm package whose original author was tired of the burden. The new maintainer added a benign-looking dependency called flatmap-stream, which a month later was updated to include code that stole Bitcoin wallets. The package had 2 million downloads. Fortune 500 companies depended on it.¹

What makes this attack so instructive is that every existing defense would have failed to prevent it. The code was signed by the official maintainer. The changes were authorized. Transparency logs would have recorded the update faithfully. The attacker was the maintainer. This is the deep problem with supply chain trust: cryptographic verification can prove that code came from a specific key, but it can't tell you whether the person holding the key is trustworthy. Identity isn't integrity.¹

Merkle Trees All the Way Down

The most serious attempt to secure software distribution comes from layering Certificate Transparency-style mechanisms onto package management. The basic architecture: when a maintainer submits a package, it goes into an append-only Merkle tree log. Clients verify that the package they're installing appears in the log, and that the log hasn't been tampered with (by checking consistency proofs between successive tree roots). Independent monitors watch the logs for anomalies — unexpected version bumps, packages signed by unfamiliar keys, versions that appear and vanish.¹

This catches targeted attacks — where a compromised mirror serves a backdoored package to a specific victim but the clean version to everyone else. The split-view attack. But it requires multiple logs under independent administration (otherwise the log itself becomes a single point of trust), and it operates asynchronously: it detects rather than prevents. Your machine has already installed the backdoor by the time the monitors notice.¹

Two deeper problems lurk beneath the log infrastructure. First: how do you know the binary matches the source? A compromised build system could insert a backdoor during compilation and the source code would look clean. The Reproducible Builds project has been painstakingly eliminating sources of non-determinism from Debian's build process since 2013 — timestamps, parallel build ordering, hashmap iteration, filesystem directory order. Over 90% of Debian packages now build reproducibly. But 100% coverage is what security actually requires, and that last 10% represents the hardest cases.¹

Second, and more vertiginous: how do you trust the compiler? Ken Thompson's 1984 Turing Award lecture demonstrated that a compiler can be modified to insert backdoors into specific programs — including into itself, so the attack perpetuates through future compiler builds and is invisible in the source code. Thompson rigged the compiler to insert a root login backdoor into the Unix login program, and then rigged the compiler to insert that modification into future compilers. The victim disassembled the binaries and found nothing, because Thompson had also rigged the disassembler.¹

The Bootstrappable Builds project tries to solve this by starting from a 280-byte hex monitor and building up an entire toolchain — assembly language, then Forth, then a garbage-collected Lisp, then a C compiler hand-written in assembly — where every stage is simple enough to be verified by inspection. It's like building trust from first principles, literally. The current state: they have a self-hosting C compiler written in assembly. There's clearly a long way to go before you can bootstrap a full modern toolchain, but the attempt itself is philosophically clarifying. It asks: at what point does a binary become too complex to trust by inspection, and what do you do after that point?¹

LLMs Find the Bugs Humans Miss

Meanwhile, a completely different approach to software security has emerged: throw an LLM at the code and ask it to find vulnerabilities. This sounds like it shouldn't work, and for years it mostly didn't. Traditional static analysis tools (SASTs) match code against predetermined rule sets — known vulnerability patterns, dangerous function calls, tainted data flows. They're useful but rigid. They can't reason about business logic, developer intent, or the subtle interactions between components that create real-world exploits.²

The new generation of AI-native security scanners — tools like ZeroPath, Corgea, and Almanax — use LLMs to actually understand code in context. They ingest a codebase, build an AST, index it (probably into a vector store), determine what the application is for (important: reporting that a forwarding proxy is "vulnerable to SSRF" is useless because connecting to the web is its intended function), and then query the LLM about potential vulnerabilities in specific functions and flows.²

The results, according to a penetration tester who trialed them extensively, are startling. These tools find real vulnerabilities in complex code — business logic flaws, architectural mistakes, faulty assumptions about trust boundaries — in minutes. They're indeterministic, which the reviewer considers a feature: run them multiple times and they find different bugs each time, "like having a schizophrenic auditor that is able to find connections between things that may or may not be there." They have low false positive rates. They're cheap. And they can reason about whether a known CVE in a dependency actually affects the specific codebase, rather than just flagging every outdated package.²

The limitations are real: some tools silently skip test files, media files, or directories named "tests" (a hole ready for exploitation — just make your malicious code look like a test). The malicious code detection claims are harder to evaluate. And nobody really knows what's happening under the hood — "my understanding of how these products work is based on inference, not disclosure." But the comparison to afl-fuzz's revolution in fuzzing circa 2013 feels apt. A new class of tool that fundamentally changes what's findable.²

The Hardware Verification Gap

Software has something hardware doesn't: a mechanism for near-perfect trust transfer. Hash a binary, compare it to the hash of the audited source compiled reproducibly, and you know — mathematically — that what you're running matches what was reviewed. The time-of-check and time-of-use can be made arbitrarily close.³

Hardware has no equivalent. Bunnie huang, who built the open-source Novena laptop from circuit boards up, came away from the experience more anxious, not less. You can't boot any modern computer without several closed-source firmware blobs running between power-on and your first instruction. Even if you published the complete mask set for a billion-transistor CPU, that "source code" is meaningless without a method to verify equivalence between the mask set and the chip in your possession — down to a near-atomic level — without destroying the chip. It's a Heisenberg problem for hardware: you can't simultaneously verify construction without disturbing function.³

This undercuts everything else in the trust stack. Software's clever Merkle trees and reproducible builds all depend on hardware faithfully computing the hashes. Tamper with the hardware, and a malicious chip can forge hash results, making bad code appear identical to good code. Open hardware, bunnie concludes, is "precisely as trustworthy as closed hardware" — which is to say, neither is trustworthy in any rigorous sense.

The Betrusted project — bunnie's attempt at an answer — follows three principles: complexity is the enemy of verification (so radically simplify the device), verify entire systems from fingertips to silicon (not just the CPU), and empower end-users to seal their own hardware. The result is deliberately limited: a black-and-white LCD whose on-glass circuits are large enough to inspect with a USB microscope, a physical keyboard made of nothing but switches and wires, and an FPGA-based CPU where logic placement randomization makes fixed silicon backdoors impractical to exploit. It can do secure text chat and second-factor auth. It can't browse the web. The minimum viable verifiable product is, by definition, the product that does almost nothing — because everything you add is something you can't inspect.

The Intelligence Theater

There's a darker thread running through all of this, which is that the institutions nominally responsible for security often don't know what they're doing. Adam Curtis's history of MI5 is the definitive account of this dynamic. When MI5 was founded in 1909, it was created largely because of a paranoid novelist's serialised invasion fantasy in the Daily Mail — whose route was adjusted by the circulation department to pass through towns with more readers. Thousands of Daily Mail readers wrote in reporting "suspicious activity" that confirmed the novelist's fiction, and MI5 was born from this feedback loop of imagination and confirmation bias.⁴

The pattern repeated throughout MI5's history. In 1991, they discovered a "secret Iraqi terror cell" in Britain — which turned out to be 33 PhD students on a list sent by the Iraqi embassy to the Bank of England to prevent their grant money from being frozen. The deputy military attache was in charge of student grants. MI5 had them rounded up and interned as prisoners of war in a military camp surrounded by razor wire. They produced no evidence at the inquiry. "It was best to err on the side of caution."⁴

This isn't just a funny story about British intelligence. It illustrates something fundamental about how security institutions operate: the aura of secret knowledge becomes a source of power independent of whether that knowledge is real. Journalists and spies develop a symbiotic relationship where the journalists get exciting stories and the spies get an inflated reputation. The classified nature of intelligence work makes accountability almost impossible — if you can't see the evidence, you can't evaluate the conclusions. Curtis's devastating summary: "It is not the story of men and women who have a better and deeper understanding of the world than we do. In fact in many cases it is the story of weirdos who have created a completely mad version of the world that they then impose on the rest of us."⁴

The connection to software security is direct. Much of the security industry operates in the same mode: the appearance of security substituting for actual security, compliance checkboxes that don't correspond to real protection, and a culture of secrecy that prevents outsiders from evaluating whether any of it works. The supply chain trust problem is partly technical (Merkle trees, reproducible builds, AI scanners) and partly social (who maintains the package, who watches the watchers, and whether the institutions responsible for security are competent enough to deserve the trust we place in them). Thompson's compiler attack is terrifying precisely because it exploits the gap between apparent verification and actual trust — and that gap is as much human as it is technical.