---
title: "Security & Trust in OSS Supply Chains"
canonical: "https://toderash.net/blog/security-trust-oss-supply-chain/"
pubDate: "2026-05-22T23:00:00.000Z"
description: "Supply chain security ensures you get what you asked for, but not whether what you asked for is safe. Establishing trust in software requires verifiable provenance with cryptographically attributable identity for the publisher.
"
---

My work on the FAIR Package Manager is largely concerned with securing the software supply chain, so I've been thinking a lot about different facets of security, and where security concerns spill over into trust.

## Establishing *Security*

### For *Supply Chains*

Supply chain security ensures that the requested package is delivered from its source as a bit-for-bit copy with no modification or tampering.

Supply chain security ensures only that you got what you requested:fn\[Even if the package is malicious — see Ken Thompson's *Reflections on Trusting Trust* and [SLSA provenance spec](https://slsa.dev/spec/v1.2/provenance) for broader context.], even if the package is malicious. In other words, even if you can trust the supply chain to deliver the package you asked for, you can't necessarily trust what's in the package.

By and large, supply chains are not designed to protect against malicious software that is compromised before it enters the supply chain, and this is the focus of increasingly effective software supply chain attacks. Some repository-level validation is done for some supply chains, but these are mainly done on a limited basis. This brings us to the question, “Can you trust the package?”

### For *Packages*

Package Security is concerned with the characteristics of the package to ensure that it operates securely and without malicious intent. This is a difficult task, especially with compiled code delivered as executable binaries. Four decades ago, Unix Co-creator Ken Thompson said in [Reflections on Trusting Trust](https://dl.acm.org/doi/pdf/10.1145/358198.358210),

> "The moral is obvious. You can't trust code that you did not totally create yourself. … No amount of source-level verification or scrutiny will protect you from using untrusted code."

[The abstract](https://dl.acm.org/doi/10.1145/358198.358210) for Thompson's 1984 lecture is simple:

> To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

Thompson's lecture makes clear that the problem is layered, illustrated by the example of a compromised compiler that injected a payload into software it was compiling. The case study was done as a practical joke in simpler times. Nobody's laughing now. Now we recognize Thompson's lesson, that every step of the build process presents an attack surface for a software package that could infect the whole supply chain. If this doesn't make someone uncomfortable, they're not paying attention.

## Establishing *Trust*

A key takeaway from Ken Thompson is that it's not enough to validate and trust the package, you've actually got to trust its publisher as well, and beyond that, the publisher-trusted authors and maintainers who write and ship the code. As for the supply chain, the technical mechanisms exist to ensure the canonical version of the code is being delivered, but they are vastly underused within some very large — and therefore very vulnerable — ecosystems.

At launch, the FAIR Package Manager established better supply chain security for the WordPress ecosystem on a number of fronts, including non-technical ones such as governance and single-vendor risk. On the technical side, the FAIR Protocol builds in support for cryptographic signing of packages in addition to validation of checksum hashes to address a weakness in the current centralized WordPress distribution model. Without buy-in from the default distribution system for WordPress Core, the solution is opt-in only. Other ecosystems already have some level of this check built in. Composer supports but does not require it, so each author determines whether or not to provide this security check. By adding FAIR support alongside Composer recently, TYPO3 moves further in this direction as well.

EmDash resolves a WordPress security issue inherent in its plugin architecture through plugin sandboxing, a method for the core CMS to limit the capabilities that plugins are allowed to have. The CMS attempts to address package security by limiting what it can do. In principle, this doesn't provide the same level of protection that a code review would, but it adds a level of protection at the *end* of the supply chain to help address whatever slips through. An older example of this is the design failure made by Microsoft when selecting Visual Basic (VBA) as the scripting language in its office suite, leading to a widespread rash of malware embedded in documents, executing code with system-wide capabilities that should never have been allowed from within a Word or Excel file.:fn\[It was portrayed as a feature, not a bug, since it gave macro scripts a lot of power. In fact, it was a miscalculation that gave them *too much* power, with end users unequipped to filter its capabilities. Later updates in the office suite only gave users the option whether to trust it or not.] EmDash's trust model (RFC 1) intends for trust to flow from the package publisher without the need to establish a separate level of trust in the individual release artifact.

While FAIR's initial implementation establishes the mechanism for verifiable trust in the release artifact, trust in the publisher has always been in scope. Since no amount of security review of the artifact itself can provide absolute certainty, we need other means of establishing trust in the people who wrote the software, and that brings us to *provenance*.

### Trust in *Provenance*

::pullquote\[Provenance is all about *verification*.]The English word provenance has two defined meanings, which are really nuances of the same concept. The first is simply the origin, or source of a thing. The second is the history of ownership, or handling of that thing. This is what the supply chain does, and might be compared to the chain of custody for evidence used in a criminal trial, or the provenance document for a valuable work of art. These establish not just where something came from, but the path it took and who handled it to place it in its current spot, whether that's in front of a jury or on an auction block.

Software is much the same, and some specific technical checks and guardrails have been created to validate that a given copy exactly matches the release asset, the original version created for distribution. This is the supply chain. Software provenance goes deeper, describing the process of how the release asset came to be created, including who its authors are, what other software libraries it contains or relies upon, and the build process that produced the release asset from its source code. The Supply-chain Levels for Software Artifacts security framework:fn\[Supply-chain Levels for Software Artifacts, or SLSA ("salsa") is "a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain." — [SLSA.dev](https://slsa.dev/)] [(SLSA) defines provenance](https://slsa.dev/spec/v1.2/provenance) this way:

> In SLSA ‘provenance’ refers to verifiable information that can be used to track an artifact back, through all the moving parts in a complex supply chain, to where it came from. It’s the verifiable information about software artifacts describing where, when, and how something was produced.

Provenance is all about verification.

For example, [GravityKit recently announced](https://www.gravitykit.com/a-stronger-reason-to-trust-what-you-install/) the addition of cryptographic signatures to all of its releases, enabling end users to positively verify that the package they receive — no matter how they received it — is unchanged from what was issued by them as the publisher. Cryptographic signatures differ from checksum hashes, typically `sha256`, for example, in that they are verifiable using a key pair to confirm not just that you've got a bit-for-bit copy of what the publisher signed, but also who signed it. Checksum hashes can *only* verify that the file contents haven't changed, and not that the file was generated by the publisher.:fn\[An attacker who updates the expected checksum while replacing the downloadable artifact has successfully compromised the supply chain.] Cryptographic signatures add authentication to file integrity, but are still missing from a surprising number of software supply chains, including expansive ones like WordPress. On the other hand, they're a key component of more recent supply chain architectures like [FAIR](https://fair.pm) and EmDash, providing a foundational layer of security by reliably transferring trust in the package back to its source.

### Trust is *Trending*

Recognizing that supply chain attacks can happen *outside* of the actual supply chain, and that the fact that the supply chain can securely deliver a package does not transmit any assurance about its actual contents means we still have a trust problem. A number of ecosystems are starting to address this in some fashion, while sources which already have trust are adding security measures. A tight link between trust and security is the end game, and I expect it will be followed by the addition of verifiable identity as an additional trust layer.

Popular note-taking app Obsidian recently laid out [The future of Obsidian plugins](https://obsidian.md/blog/future-of-plugins/), which includes a review process through the launch of [Obsidian Community](https://community.obsidian.md/), which will do both automated and manual reviews with verified authors and plugin disclosures.

Sourceforge has done automated code scanning of every release for more than a decade. WordPress has done code scans and reviews of plugins and themes for even longer, but until recently, only initial submissions received a full scrutinizing.

## Trust & Security in the *Sandbox*

The recently-released EmDash CMS makes a specific architectural change from the way WordPress plugins operate in order to help keep it secure. With WordPress, an active plugin is able to do whatever it wants within the WordPress installation, without restriction apart from what may be imposed by the hosting environment. WordPress itself doesn't make any further restrictions, so one plugin can read or modify the data created by another. EmDash introduced a "sandbox" with a more granular layer of permissions, so a plugin requires permission grants not just to run, but to modify the file system or send email, or connect to an external URL, for example. This means that if a plugin doesn't *need* to access the filesystem, it won't have permission to. The security implication is that if the plugin is compromised, an attacker doesn't automatically gain access to the filesystem. The trust implications are that the website administrator doesn't have to trust the plugin author *completely*, but only with regard to permitted operations. It's not foolproof (what is?), but it's a very good model.

[WP-Apps](https://wp-apps.org/) has taken [a stab at this for WordPress](https://github.com/InstaWP/wp-apps) by restricting the scope of what each plugin is allowed to do, similar to FAIR contributor Namith Jawahar's proof of concept MU-plugin, [WP Hook Permissions](https://github.com/namithj/wp-hook-permissions), which allows a site admin to disallow plugins from accessing certain hooks. Properly sandboxing WordPress plugins will be a difficult task, if it's doable at all. Because plugins aren't *inherently* restricted from accessing PHP functions outside of WordPress, native PHP functions could still send email, and a plugin that's not allowed to use `wp_remote_get()` could simply access `curl` directly. These scenarios could be (partially) addressed by code scans or reviews that surface to site admins when a package makes use of these functions. WordPress code scanning will flag the use of functions like `eval()` and can find functions writing SQL to access the database directly, bypassing the WordPress functions for doing so.

Simply surfacing notices to an end user or site admin isn't a reliable safety valve, since even fairly technical people can be overly quick to click the “OK” button without thinking through security implications that can be quite complex. What this does is extend trust to the publisher, effectively saying, “I know you could abuse this permission, but I don't think you will.” This is trust, not security.

### Sandbox *Anarchy?*

I resonated with remarks made recently by Patchstack CEO Oliver Sild on X and [on LinkedIn](https://www.linkedin.com/posts/oliversild_hacking-wordpress-sites-is-great-again-activity-7463310812963725312-nv-F), which were then picked up by Roger Monti at *Search Engine Journal*: [WordPress 7.0 Could Trigger Rush To Steal AI API Keys](https://www.searchenginejournal.com/wordpress-7-0-faces-security-concerns-over-ai-api-keys/575679/). Whenever WordPress security issues are raised, someone will be quick to point out that these vulnerabilities exist mainly in plugins and themes rather than in WordPress Core, and this time it was Matt Mullenweg responding directly on X. I think this is relevant to what I'm saying here about the sandbox, because at some point, you have to acknowledge that even if the core application is secure, its architecture invites insecure extensions. Just like Microsoft failed to put in guardrails around a poorly-selected macro scripting language for its office suite, WordPress is architecturally unable to limit what its plugins — or even its themes — can do, functionally and with full CRUD (Create, Read, Update, Delete) permissions for the database and filesystem. WordPress' template engine is native PHP, and one *might* argue that using the same unrestricted programming language for a template engine as to build the whole application is a worse design flaw than using VBA as a scripting language for an application written in C++. Some template engines are designed only to read and display data with no ability to modify it or add any significant functionality. Essentially, those systems create a sandbox for the presentation layer that restricts it to presentation functions only. Within WordPress, the only difference between capabilities extended to themes and plugins is almost incidental, based on the order its hooks fire.

::pullquote\[WordPress Core may well be secure, but it provides an unrestricted architecture for insecure extensions.]It's time to grapple with the fact that although WordPress Core is relatively secure, it's always-on permissions for extending it make it insecure without expert work to ensure it remains secure. Of some 60,000 plugins, a good number shouldn't be touched, with a smaller number representing trustworthy, secure extensions to the platform. Custom site-specific plugins need to bear security in mind for this same reason, and since the barrier to entry for WordPress developers is so low, it creates an ecosystem where security risks are higher than they should be.

Add to this the fact that the majority of WordPress sites are not built by experts, or even by developers *per se*, but by *integrators*, who take a no-code approach to building sites by combining and configuring existing plugins. Although not adding custom code should increase security, the lack of understanding site architecture can combine with indiscriminate selection of plugins and themes to produce questionable results from a security (and performance) standpoint. Although not the *author* of many of these vulnerabilities, WordPress Core is going to have to start taking responsibility for the fact that they've provided an open and unrestricted architecture for enabling them. Owning the sandbox means setting the rules; not doing so gives permission for some level of anarchy.

## From Challenges to *Solutions*

### AI Gets *Cracking*

The biggest challenge in recent months (it's developing very fast) is the use of AI by hackers:fn\[Being old-school, I tend to use the word “hacker” in a positive sense, but getting the world to adopt “cracker” has proved insurmountable. We *do* understand the phrase “script kiddies”, but those kiddies now have AI to help them, which makes me want to coin the term “hAIking”. I admit, it's not very catchy.] in their attempts to find vulnerabilities they can exploit. What AI has proven to be quite adept at is finding vulnerabilities that can be exploited in more complex ways through a layered attack. Anyone who's received an insurance company's cybersecurity questionnaire to fill out on a client's behalf will know that security is being taken very seriously in the industry, even if they're not always asking the right questions of the right people. This is all about to get a lot more complicated, and will put an increasing focus on the source of the software — its publisher and even its individual authors, especially in open source projects.

### Ken Thompson had it *Right.*

From a technical standpoint, secure software delivery is a solved problem, even if it's not consistently implemented. The critical frontier at the moment is establishing trust. This happens partially through code analysis and operational observation, and partially through the old-fashioned extension trust in "the people who wrote the software." In 1984, it was a lot easier to know who wrote the software. In 2026, it's nearly impossible outside of small, tight communities. Establishing and building trust as a software publisher is about to become critical to the survival of software projects. For years, the initial grant of speculative trust in what a package would do at runtime bypassed security, but allowed actual trust to be built over time. The gap between trusting the software and verifying it was an interim state, but it's now over.

The EU's Cyber Resilience Act (CRA) at the vanguard of a whole batch of regulatory legislation will change the shape of the software industry for the better. In some circles, it's seen as overreaching, or irrelevant outside the EU, but if half the industry complies, the compliant half will thrive while the other half withers. From a certain standpoint, the CRA simply codifies much of what already exists as best-practice measures, particularly ones that enterprise environments are already looking at in order to reduce risk and ensure long-term viability of their platforms.

### Supply Chains of the *Future*

Verifiable identity establishes accountability, which is another strong signal for building trust. With the availability of universally unique identifiers (DIDs) and privacy-preserving online identity verification, we should expect the future of trust-building to include verifiable attestations concerning the identity of software authors and contributors. This enables developer *karma* to follow contributors across different open source projects or software ecosystems. Some will bristle at the idea as an erosion of anonymity, but for all practical purposes, most reputable developers are already *known*, and welcome attribution as a means of building reputation. In open source, reputation is currency that's worth nothing if it's not attributable.