Notifications
Clear all
Topic starter
19/08/2026 3:48 pm
TL;DR: Seventy-plus ghost releases across trusted npm @types packages were detected after a GitHub Actions workflow kept republishing identical deprecated versions every 30 minutes, according to StepSecurity. The case matters because release monitoring, workflow guardrails, and package governance are now part of software supply chain resilience, not optional hygiene, showing how a one-line automation bug can create noisy supply chain behaviour with ecosystem-wide trust implications.
NHIMG editorial — based on content published by StepSecurity: How StepSecurity Caught a Release Storm in Microsoft’s @types Packages
By the numbers:
- StepSecurity detected 70+ ghost releases across npm's most trusted TypeScript packages.
- The workflow repeated releases every 30 minutes, turning a one-time deprecation into an ongoing publication loop.
- StepSecurity traced the anomaly across multiple @types packages in a 24-hour window.
Questions worth separating out
Q: Where do release automation workflows fail in practice?
A: They fail when the workflow assumes a publish decision has already been validated, but the state check is wrong or incomplete.
Q: Why do CI/CD workflows make supply chain worms harder to contain?
A: CI/CD systems are built to consume new code automatically, often with privileged access to secrets, caches, and release rights.
Q: How can security teams detect release storms before they spread?
A: Track publication frequency, version churn, and repeated metadata patterns over time, then compare them with normal maintainer behaviour.
Practitioner guidance
- Implement publish-state assertions Require every release workflow to assert the current package state before publishing, including checks for deprecated, already-published, or no-op conditions.
- Test undefined and fallback paths Add unit and integration tests for undefined inputs, missing labels, and default resolution in release scripts.
- Alert on release cadence anomalies Create monitoring for package publication bursts, repeated semantic version bumps, and identical release metadata within short windows.
What's in the full article
StepSecurity's full post covers the operational detail this post intentionally leaves for the source:
- The exact publish-packages.yml workflow logic that looped on a 30-minute schedule and how it evaluated notNeededPackages.json
- The one-line code fix that stopped the repeated releases and the maintainer response timeline
- The release pattern evidence across multiple @types packages, including the version churn sequence and anomaly detection trail
- The repository references and issue history that show how the bug was isolated and merged through the fix process
👉 Read StepSecurity's analysis of the @types package release storm and workflow bug →
Release storms in @types packages: what governance gap did this expose?
Explore further
19/08/2026 4:25 pm
Release automation now behaves like an identity-bearing control plane. A scheduled GitHub Actions workflow that can publish packages on behalf of a project has delegated authority, not just operational convenience. When that authority is not tightly bounded by state checks, versioning rules, and signed release evidence, the workflow can repeatedly exercise standing privilege. Practitioners should treat build and publish systems as governed identities with lifecycle controls, not just CI plumbing.
A question worth separating out:
Q: Who is accountable when an automated package publish loop happens?
A: Accountability should sit with the owners of the workflow, the maintainers of the publishing logic, and the platform team responsible for release governance. In practice, that means someone must own state validation, permission scope, and anomaly response. For regulated environments, this maps to change control and auditability expectations, not just engineering debugging.
👉 Read our full editorial: Release storms in trusted npm type packages expose supply chain gaps
