In December 2020, the SolarWinds attack rewired how the industry thinks about software security.
Russian intelligence operatives didn’t breach SolarWinds’ network through a phishing email or an unpatched server. They compromised the build system itself. Malicious code was inserted into legitimate software updates, signed with SolarWinds’ own certificates, and distributed to 18,000 organizations — including the US Treasury, the Department of Homeland Security, and Fortune 500 companies.
The breach wasn’t in the code. It was in the supply chain.
This was the moment the industry realized that trusting software meant trusting every step of its journey: the source repository, the build environment, the signing keys, the distribution channel. A single compromised link breaks the entire chain.
The response was immediate and structural. The White House issued Executive Order 14028, mandating software supply chain security for federal contractors. NIST published secure software development guidelines. And the open source community rallied around a new framework: SLSA — Supply-chain Levels for Software Artifacts.
The SLSA Revolution
SLSA gave us something we didn’t have before: a common vocabulary for supply chain integrity.
Instead of vague assurances like “we follow best practices,” organizations could now make specific, verifiable claims. “This artifact is SLSA Level 3” means something precise: the build ran on a hosted service, the provenance is authenticated, and the process is auditable.
The levels are cumulative:
- Level 1: Provenance exists (you know where it came from)
- Level 2: Hosted build, authenticated provenance (a trusted system built it)
- Level 3: Hardened build, non-falsifiable provenance (the build environment is isolated and tamper-resistant)
- Level 4: Hermetic, reproducible builds (anyone can verify by rebuilding)
This framework transformed software security. Artifact registries started requiring SLSA attestations. CI/CD platforms added native provenance generation. Sigstore emerged to provide free, transparent signing infrastructure.
And yet, the attacks keep coming — and AI is making them worse.
The Shai-Hulud worm that swept through npm in late 2025 compromised hundreds of popular packages, stealing developer credentials and propagating through the dependency graph. Its successor, SANDWORM_MODE, went further: it weaponized AI coding assistants themselves, installing rogue MCP servers that hijacked tools like Claude Code and Cursor to exfiltrate SSH keys and cloud credentials. The attackers used AI to generate convincing typosquat packages at scale — malicious clones of legitimate tools that looked authentic enough to fool both humans and automated systems.
This is the new reality. AI doesn’t just accelerate content generation — it accelerates attack generation. The same tools that help developers write code faster help attackers write malware faster. The same models that generate helpful documentation generate convincing phishing lures. Supply chain security is now an adversarial AI problem.
The software supply chain is getting the security infrastructure it needs. But the race isn’t over.
The Other Supply Chain
But software isn’t the only thing with a supply chain.
Every piece of digital content has a provenance story. A photograph moves from camera to editing software to content management system to social platform. A video passes through capture, transcoding, editing, effects, color grading, and distribution. A news article aggregates quotes, images, data visualizations, and embedded media from dozens of sources.
This is the digital content supply chain. And it’s under attack.
The threat isn’t Russian intelligence agencies (though they’re involved too). It’s the fundamental collapse of content authenticity. AI-generated images flood social media. Synthetic audio impersonates executives and politicians. Manipulated video spreads faster than corrections. The economics are brutal: fake content is cheap to produce, expensive to debunk, and algorithmically amplified.
We’re facing a SolarWinds-scale crisis for digital content — except instead of 18,000 organizations, it’s billions of people consuming compromised information every day.
C2PA: A Good Start
The media industry hasn’t been idle. The Coalition for Content Provenance and Authenticity (C2PA) — backed by Adobe, Microsoft, the BBC, and camera manufacturers — developed a standard for embedding cryptographic provenance in media files.
C2PA lets a camera sign an image at capture. It lets editing software record a chain of modifications. It lets platforms verify that content hasn’t been tampered with since signing.
This is real progress. But C2PA adoption faces a vocabulary problem.
When a security team says “we require SLSA Level 3,” everyone knows what that means. When a newsroom says “we require C2PA Content Credentials,” what level of trust does that convey? Is a self-signed credential from an unknown source equivalent to a hardware-attested signature from a trusted camera? The standard doesn’t distinguish.
SLMA: A Proposal
SLMA — Supply-chain Levels for Media Artifacts — is an attempt to apply the SLSA framework to digital content.
The insight is simple: media has a supply chain too. And that supply chain needs the same graduated trust model that transformed software security.
| Level | Name | Trust Guarantee |
|---|---|---|
| SLMA 0 | None | No provenance |
| SLMA 1 | Documented | Metadata exists, unverified |
| SLMA 2 | Signed | Cryptographically authenticated origin |
| SLMA 3 | Notarized | Tamper-evident public record |
| SLMA 4 | Hardware-Attested | Secure capture device attestation |
These levels give us a common vocabulary — the same kind of vocabulary that made SLSA successful.
SLMA 0: None
No provenance. Unknown origin. This is the default state for most content online: stripped metadata, screenshots of screenshots, files that have passed through so many hands that any chain of custody is lost.
Trust guarantee: None.
SLMA 1: Documented
Metadata exists. EXIF data shows camera settings. XMP fields record editing history. The information is present — but it’s not cryptographically verified.
The problem: Metadata can be forged. Anyone can write EXIF data. This level tells you what the content claims about itself, not what’s actually true.
Trust guarantee: Information exists, but isn’t verified.
SLMA 2: Signed
The provenance is cryptographically signed. A C2PA manifest is embedded, containing assertions about origin and edit history. The signature chain traces to an identity — a certificate, a DID, or another cryptographic anchor.
Tampering breaks the signature. You can verify the signer’s identity.
This is where C2PA lives today. It’s a significant improvement over SLMA 1, but it still requires trusting the signer. A sophisticated adversary could obtain signing credentials and produce authentic-looking fakes.
Trust guarantee: Authenticated origin. Tamper-evident assertions.
SLMA 3: Notarized
Signed provenance plus a public transparency log entry.
The artifact’s hash is recorded in an append-only log — like Sigstore’s Rekor — providing:
- Third-party timestamp: Proof the artifact existed at a specific time
- Immutability: The log entry can’t be deleted or altered
- Independent verification: Anyone can verify without trusting the creator
This is the media equivalent of SLSA’s “authenticated provenance from a hosted build service.” The transparency log acts as a neutral witness.
Trust guarantee: Public, tamper-evident, timestamped record.
SLMA 4: Hardware-Attested
The highest level. The capture device itself provides cryptographic attestation.
A secure enclave in the camera signs the image at the moment photons hit the sensor — before the file ever leaves the device. The signature proves not just who signed, but that the signing happened on specific hardware at capture time.
Today, SLMA 4 is rare: Leica M11-P, select Sony cameras, Truepic-enabled devices. But as the content authenticity crisis deepens, expect this to become standard in professional equipment.
Trust guarantee: End-to-end integrity from sensor to storage.
Policy Portability
The power of SLMA is the same power that made SLSA transformative: policy portability.
A newsroom can mandate: “Published images must be SLMA 2 or higher.”
A legal workflow can require: “Evidence submissions must be SLMA 4.”
An insurance company can specify: “Claims documentation must be SLMA 3.”
A social platform can label: “This content is SLMA 0 — origin unknown.”
The same vocabulary works across industries. The same verification tooling works. The same mental model applies whether you’re a security engineer reviewing a container image or a photo editor reviewing submitted footage.
From Software to Media to Everything
The lines between software and media are blurring anyway.
An AI agent generates code, then generates an image, then signs both, then deploys them together. A journalism workflow includes source footage, transcripts, AI-assisted edits, and a final published package. A marketing campaign combines human-written copy, AI-generated visuals, licensed stock footage, and user-submitted content.
These aren’t separate domains anymore. They’re one continuous supply chain of digital artifacts. SLMA extends the SLSA model to cover all of it.
A Starting Point, Not a Standard
This is a proposal, not a proclamation. We’re not trying to declare a new standard — we’re trying to start a conversation.
The levels we’ve outlined here are a first draft. Maybe four levels is wrong. Maybe the boundaries are in the wrong places. Maybe there are requirements we’ve missed or distinctions that don’t matter in practice. We don’t know yet.
What we do know is that the content authenticity space needs a common vocabulary — the same kind of vocabulary that made SLSA useful for software. Without it, “this image has Content Credentials” remains a binary statement that doesn’t distinguish between a self-signed credential and a hardware-attested capture from a trusted device.
We’ve implemented a rough version of SLMA verification at noosphere.tech/verify. Upload an artifact and see what level it might qualify for. It’s imperfect, but it’s concrete — something to react to rather than argue about in the abstract.
If you’re working on content authenticity, media verification, or trust infrastructure, we’d love to hear from you. What’s wrong with this framework? What’s missing? What would make it useful for your use case?
The goal isn’t to be right. The goal is to do for content authenticity what SLSA did for software security. That’s going to take a lot of people thinking hard about the problem — not just us.
SLMA builds on SLSA from the Open Source Security Foundation and C2PA from the Coalition for Content Provenance and Authenticity. We’re grateful to both communities for laying the groundwork.
Have thoughts? Reach out at hello@noosphere.tech or find us on GitHub.