Every time a supply chain campaign lands — and the Miasma campaign landing on 14 June 2026, with over 100 compromised npm and PyPI packages including packages from the Red Hat namespace, is a significant one — the same conversation plays out in security teams: “We run everything through Artifactory / Nexus / Azure Artefacts, so we’re protected.”
The security community needs to have an honest conversation about what that statement actually means and where it breaks down.
What Mirrors Actually Protect Against
Internal package mirrors are a legitimate, valuable control. They work well against a specific set of supply chain threats:
Typosquatting: mirrors with an approved package allowlist prevent engineers from accidentally installing reqeusts instead of requests. That’s real. It prevents a whole class of opportunistic attack.
Dependency confusion: mirrors configured to always prefer internal packages over public registries prevent attackers from shadow-publishing malicious packages under internal namespace names to public registries. Also real, and a critical control since the 2021 research that triggered a wave of CVDs.
Version drift and availability: if the public registry is unavailable or a maintainer deletes a package (the left-pad scenario), builds continue from the mirror. Useful operational resilience.
Unvetted transitive dependencies: mirrors that enforce dependency graphs scanned at ingestion time can prevent new transitive dependencies from slipping in unreviewed. Real value, rarely implemented fully.
What They Do Not Protect Against
The Miasma campaign exposes the gap: mirrors do not protect against attacker-injected malicious code published under legitimate publisher credentials to legitimate package versions.
When an attacker compromises a maintainer’s npm or PyPI account and publishes a malicious patch release — 1.4.7 to 1.4.8, say — what happens in a typical enterprise mirror setup?
If the mirror is configured to automatically sync the latest versions of monitored packages (which most are, because the alternative is manually approving every upstream version bump for hundreds of packages), it fetches 1.4.8 from the public registry. It passes the attacker’s malicious code to any build pipeline that requests the latest version. The trust signal — “this is coming from our internal Artifactory instance” — is now actively harmful, because it suggests a level of vetting that did not occur.
The Red Hat namespace compromise in Miasma is the most illustrative example. Security tooling that treats the Red Hat namespace as inherently trusted — because why would Red Hat ship malware? — will classify a compromised Red Hat namespace package as safe. The brand trust that Red Hat legitimately earned through decades of enterprise Linux distribution is now being weaponised against the organisations that trust it.
The Uncomfortable Reality of Credential-Based Attacks
Publisher credential compromise is a different threat model than the attacks most dependency management controls are designed against. The attacker isn’t trying to trick you into installing the wrong package. They’re modifying the right package, from the right place, by the right publisher — at least as far as any automated control can verify.
Phylum’s research indicates the Miasma campaign obtained credentials through a combination of phishing and scanning public repositories for committed API keys. The second vector — tokens committed to public GitHub repositories — is entirely preventable through secret scanning with pre-commit hooks and automated repository scanning. Many of those tokens were committed months or years ago and never rotated, sitting in public git history waiting to be harvested.
The first vector — credential phishing — is substantially mitigated by hardware-based MFA. npm now supports security key authentication. PyPI has supported hardware keys for years. The question is how many open-source maintainers of packages installed in enterprise production environments have actually enabled it.
What Effective Supply Chain Defence Looks Like
The honest answer is that effective defence requires layering controls that address different attack vectors, with explicit acknowledgement of what each layer does and does not protect:
Lock files with hash pinning (package-lock.json, pip freeze with hashes, cargo.lock) ensure that only specific, pre-verified versions of packages — identified by exact content hash — are installed in builds. If an attacker publishes a malicious 1.4.8, builds locked to the 1.4.7 hash are unaffected. This is the most effective compensating control for credential compromise attacks, and it should be mandated across all production build pipelines.
Post-install script policy is underused. The primary mechanism by which compromised packages exfiltrate data is post-install hooks. Organisations can configure npm and pip to block or flag post-install script execution as a policy, which would suppress the exfiltration stage even if a compromised package reaches a build environment.
Build environment credential minimisation limits the blast radius when a compromised package does execute. If the CI/CD pipeline environment variable for your cloud provider API key is not present during dependency installation (only injected during the deploy stage), there is nothing to steal. Environment variable scoping in CI/CD pipelines is a low-effort, high-value control.
Active publisher behaviour monitoring tools like Phylum, Socket.io, and Snyk Code detect anomalous publish events — sudden new post-install hooks, unusual outbound network calls, large version-to-version diffs — in real time. These tools operate on the content of the package, not just its provenance, and would flag a Miasma-style injection regardless of which namespace it appeared in.
The Take
Internal mirrors are necessary but not sufficient. They should be accompanied by explicit, documented answers to three questions: What does our mirror protect against? What does it not protect against? What compensating controls address the gap?
Any security architecture document that lists “internal Artifactory proxy” under “Supply Chain” controls and stops there is describing a partial defence as a complete one.
The Miasma campaign compromised the Red Hat namespace. The next campaign might target a vendor namespace your organisation considers even more categorically trustworthy. The control that protects against that scenario is not a mirror. It is hash-pinned lockfiles, minimal CI credentials, and behavioural monitoring — controls that most enterprises have not yet made standard.
Share this article