You've implemented Trusted Publishing for your npm packages. You've eliminated long-lived tokens and are using OIDC-based workflows. The security team signed off. So you're done with credential-based supply chain attacks, right?
Not quite. Myths about Trusted Publishing persist because it solves real problems, but introduces new ones that most teams haven't stress-tested. The SlugFest vulnerability disclosed by Bloom Security shows how a single design assumption can undermine an entire trust model. Over 1,500 npm packages were exposed because practitioners believed myths instead of verifying the actual implementation.
Here's what you need to unlearn.
Myth 1: Trusted Publishing Eliminates Credential Theft Risk
Reality: It eliminates one type of credential theft, the compromise of static npm tokens. It doesn't eliminate identity hijacking.
The SlugFest flaw worked because npm validated GitHub repository names (mutable strings like acme-corp/auth-sdk) instead of repository IDs (permanent numeric identifiers). When a repository gets renamed, transferred, or deleted, that human-readable name becomes available. An attacker who claims acme-corp/auth-sdk after you abandon it inherits your package's publishing trust.
Bloom Security successfully published a new version of a controlled test package from a completely different organization's GitHub account. No passwords stolen. No tokens leaked. The trust relationship itself was the vulnerability.
What this means for you: Audit every Trusted Publishing configuration. Verify that the repository name still resolves to your repository. If you've renamed or transferred repos in the past year, your old bindings may be orphaned and claimable. Remove and recreate them using current repository identifiers.
Myth 2: Repository Names Are Stable Enough to Serve as Trust Anchors
Reality: Repository names are organizational metadata, not cryptographic identifiers.
Your team renames repositories during rebrands. You transfer them between organizations during M&A. You delete proof-of-concept repos after evaluation. GitHub's namespace management prioritizes flexibility for developers, not immutability for trust chains.
npm's original implementation treated owner/repository as a durable trust signal. But these strings change ownership without changing appearance. The fix npm shipped on October 2 introduced a 48-hour expiry for unvalidated configurations, a containment measure, not a structural solution.
What this means for you: Don't build trust models on mutable strings. If you're designing or procuring supply chain tooling, require immutable identifiers (repository IDs, commit SHAs, cryptographic fingerprints) in trust configurations. If your vendor can't explain the difference, that's a due diligence red flag.
Myth 3: Automated Workflows Reduce Human Error
Reality: Automation moves human error from execution to configuration, and configuration mistakes persist longer.
You set up a Trusted Publishing binding once. It runs for months or years. During that time, your team might rename the repository, transfer it to a different org during a spinoff, or archive it after deprecating the package. The binding doesn't break immediately, it just becomes claimable.
Manual publishing forced you to touch credentials regularly. You'd notice if something was wrong. Automated workflows hide configuration drift until someone exploits it.
What this means for you: Treat Trusted Publishing configurations as living artifacts that require periodic review. Add them to your quarterly access reviews. When you deprecate a package or archive a repository, explicitly revoke the publishing trust, don't assume deletion cascades correctly.
Myth 4: Package Registries Validate Publisher Identity Continuously
Reality: Most registries validate identity at binding creation, not at publish time.
npm checked that the GitHub Actions token matched the expected repository name and workflow filename. It didn't re-verify that the repository ID matched the one that originally created the binding. This is a design tradeoff: continuous validation adds latency and complexity, but point-in-time validation creates windows for exploitation.
The researchers found packages with over 200,000 monthly downloads that were vulnerable. One million downloads per month across the exposed set. These aren't obscure packages, they're dependencies in active use.
What this means for you: Don't assume the registry is doing the validation you need. If you're consuming packages (not just publishing them), you need runtime controls that verify package provenance independently. SLSA attestations, Sigstore signatures, and dependency pinning are not optional hygiene, they're your last line of defense when upstream trust models fail.
Myth 5: AI Agents Will Respect Your Dependency Policies
Reality: AI agents optimize for task completion, not policy compliance.
Bloom Security measured approximately 70 agent-installed packages per endpoint per month in their research environments, rising to around 350 on developer machines. These aren't transitive dependencies pulled in by a human-selected package. These are direct installations made by coding assistants trying to solve a problem.
An AI agent doesn't read your approved package list. It doesn't check if a dependency has a current security audit. It selects packages based on documentation, download counts, and semantic fit. A hijacked package with a legitimate name and plausible README will look identical to the agent.
What this means for you: If you're allowing AI coding agents in your environment, you need technical controls that prevent unauthorized package installation. Lock down package manager configurations. Require internal registry proxies that filter against an allowlist. Monitor installation events in real time, not through monthly reviews. The researchers' point stands: "A hijacked package doesn't need to find a developer anymore. It only needs to be the package an agent chooses."
What to Do Instead
Run a configuration audit this week. Export every Trusted Publishing binding. Verify that each repository name still points to a repository your organization controls. Check for renamed, transferred, or deleted repositories. Remove orphaned bindings.
Implement immutable identifier requirements. If you're evaluating supply chain security tooling, require vendors to use repository IDs, not names. If you're building internal tooling, design trust chains around cryptographic identifiers from the start.
Add Trusted Publishing to your access review cycle. Treat these bindings like service accounts. Review them quarterly. Revoke them when packages are deprecated or repositories are archived.
Control AI agent package installation. If you're piloting coding assistants, configure package managers to require approval for new dependencies. Use internal registries with allowlists. Monitor installation telemetry.
Don't wait for the next disclosure. npm fixed this specific flaw. The underlying pattern, trust models built on mutable metadata, exists across the ecosystem. Your job is to find the gaps before researchers do.
