Your SLSA Provenance Means Nothing If Your Identity Is Compromised

The Miasma campaign did not crack any cryptography. It got a valid signature on malicious code by using a legitimate identity — and that distinction should worry every engineering team that considers SLSA provenance a supply chain safety net.

A Red Hat employee's GitHub account was compromised this week, exposing the @redhat-cloud-services npm namespace: 32 packages, 96 versions, approximately 117,000 weekly downloads. The attacker exploited GitHub Actions OIDC tokens tied to that account to publish Trojanized packages carrying Miasma, a credential-stealing worm derived from the Mini Shai-Hulud family. The packages shipped with valid SLSA provenance because the OIDC tokens were legitimate — issued to the real account, now in the wrong hands. Wiz Research uncovered and disclosed the campaign; Red Hat issued security bulletin RHSB-2026-006 in response.

The attack surface here is not a vulnerability in SLSA itself. The protocol did exactly what it promised: cryptographically linking build artifacts to pipeline executions. The problem is that this guarantee only holds as long as the identity behind those executions is trustworthy. Once a human account is compromised, everything downstream inherits that compromise — OIDC tokens, pipeline triggers, published artifacts, and their provenance records. SLSA verifies the pipeline; it does not verify the intent of the person who triggered it.

This is a confirmed production incident, not a theoretical scenario, and it fits an escalating pattern. SolarWinds targeted build servers. XZ Utils targeted a maintainer's trust relationship over months of social engineering. Miasma targeted account credentials and pipeline permissions. The common thread is identity, not code. Attackers have learned that as SLSA and similar controls mature, the path of least resistance shifts toward the identity layer that those controls implicitly trust. SLSA is still worth implementing — but it needs to be paired with strong IAM upstream, not treated as a standalone safety net. Provenance tells you where a package came from. It does not tell you whether the person or system that triggered the build was acting legitimately. Both questions need answers.

For engineering leaders, the practical response operates at three distinct layers. First, OIDC token scope. GitHub Actions OIDC tokens can be bound to specific workflows, branches, environments, and repositories — but many teams grant broader permissions than necessary. Any token with the ability to publish to a package registry should require an explicit environment gate, not just branch protection. If your npm publish fires on any successful merge to main, that permission surface is worth auditing today. Second, machine identities for automated publishing. Human accounts get phished, credential-stuffed, and socially engineered. Dedicated machine identities — GitHub App credentials, service accounts with scoped IAM roles — offer a narrower attack surface and do not carry the risk of a human account being compromised via email or password reuse. Where automated publishing is driven by tokens derived from human accounts, a single credential leak is all that separates you from a Miasma-class incident. Third, if your dependency tree pulls from @redhat-cloud-services, audit your lockfiles against RHSB-2026-006 now. The affected versions are documented and the remediation path is clear.

The deeper architectural lesson generalizes beyond supply chains: integrity guarantees at one layer are only as strong as the authentication model protecting the layer above it. SLSA secures build provenance; identity and access management secures who can initiate builds. Running SLSA without strong IAM upstream is equivalent to locking the safe but leaving the keys on the desk — the provenance record is authentic, the intent behind it is not. The Miasma campaign is not an anomaly. It is a preview of how supply chain attacks will operate as SLSA adoption grows, and the teams that treat identity security as a prerequisite to provenance verification — rather than an afterthought — are the ones that will hold the line.