Release storms in trusted npm type packages expose supply chain gaps

At a glance

What this is: StepSecurity found a release storm in Microsoft’s @types packages caused by an automated GitHub workflow repeatedly publishing identical deprecated npm versions.

Why it matters: For IAM, NHI, and supply chain governance teams, the case shows how automation faults in build and release systems can create trusted-but-uncontrolled identity and integrity risk.

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.

👉 Read StepSecurity's analysis of the @types package release storm and workflow bug

Context

A release pipeline can be trusted by users and still be unsafe in operation. In this case, the problem was not malicious code but uncontrolled automation in a package publishing workflow, which matters because software supply chains now behave like identity systems with standing privileges, delegated actions, and weak lifecycle checks.

The identity angle is real: GitHub Actions workflows act on behalf of repositories, packages, and maintainers, so a small logic error can repeatedly exercise high-trust publishing rights. That makes release automation a governance issue as much as an engineering bug, especially when deprecated packages, npm publishing, and workflow credentials intersect.

Key questions

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. A scheduled job can then keep exercising the same trusted permission set and repeat the same release action. The failure is not just in code, but in the lack of control-plane validation around publication state and exception handling.

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. That means malicious code can execute before a human notices the change. The more automated the pipeline, the smaller the defender's reaction window becomes.

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. A true release storm usually shows identical or near-identical artefacts appearing in a compressed time window. Detection works best when package telemetry is correlated with workflow logs and repository change history.

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.

Technical breakdown

How a scheduled GitHub Actions workflow can create release storms

A scheduled workflow can repeatedly execute the same publish logic whenever its trigger fires, which is safe only if the state check is reliable. In this incident, the workflow read a file listing packages that no longer needed types and then attempted to publish a deprecated npm version. Because the guard condition failed, each run behaved like a fresh publish event. The result was not code drift but version drift, which is still operationally harmful because it floods package history, obscures genuine changes, and erodes signal quality for downstream consumers.

Practical implication: treat scheduled publishing workflows as stateful systems and test the deprecation path as carefully as the release path.

Why undefined values in release logic can override intended defaults

A common automation failure mode is not a crash but a silent default mismatch. Here, the code intended to pass the label latest but instead passed undefined, which altered how the underlying library handled the publish decision. That meant the workflow did not correctly recognize that the package had already been handled, so the loop continued. In supply chain tooling, these failures matter because the control plane is often implicit, spread across scripts, package metadata, and third-party APIs rather than enforced in one place.

Practical implication: validate every publish parameter explicitly and add unit tests for empty, undefined, and fallback cases in release automation.

Why trusted package ecosystems need release anomaly detection

Release storms are more than noise when they occur in high-traffic dependency ecosystems. Even if the versions are harmless, repeated publication can hide malicious activity, train responders to ignore alerts, and complicate provenance review. For software supply chains, anomaly detection must look at publication frequency, version churn, and workflow behaviour together. That is especially important in ecosystems like npm where package trust is distributed and human review does not occur on every automated action.

Practical implication: monitor release frequency anomalies and correlate them with workflow execution logs, package metadata, and maintainers’ expected change cadence.

Threat narrative

Attacker objective: The relevant objective pattern is abuse of trusted automation to make repeated package publication look normal and reduce the visibility of real supply chain compromise.

1. Entry occurred through a scheduled GitHub Actions publish workflow that executed with trusted repository automation on every 30-minute trigger.
2. Escalation happened when a broken label assignment prevented the workflow from recognizing previously deprecated packages, so each run retained publish authority.
3. Impact was repeated npm publication of identical deprecated versions, creating 70+ ghost releases and a noisy trust signal across the TypeScript package ecosystem.

NHI Mgmt Group analysis

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.

Ghost releases create governance debt because they blur the line between benign noise and malicious camouflage. High-frequency version churn in trusted packages trains teams to discount unusual signals, which is exactly how adversaries benefit from automated ecosystems. The named concept here is release storm camouflage: repeated low-signal publication activity that makes genuine compromise harder to detect. Security teams should baseline release cadence and require exception handling for any unexpected burst.

Supply chain integrity depends on verifying the publish decision, not only the publish target. The workflow in this case had the right destination but the wrong control logic, which is a familiar failure mode in modern software pipelines. NIST CSF and NIST SP 800-53 both point toward control validation, auditability, and change integrity as core governance requirements. Practitioners should focus on proving why a package was published before they assume the publisher is trustworthy.

Automated package maintenance is becoming a non-human identity problem. The workflow acted with its own delegated permissions, produced repetitive external effects, and required lifecycle governance similar to any other NHI. That matters because service identities in CI/CD are often over-permissioned, weakly observed, and insufficiently offboarded when logic changes. Teams should apply the same scrutiny to release workflows that they apply to privileged service accounts.

Open-source ecosystem trust now depends on anomaly response speed as much as code quality. StepSecurity’s detection and the maintainer response show that rapid correction limits blast radius, but the underlying lesson is broader. Ecosystem operators need release monitoring, workflow review, and rollback discipline before a bug becomes an operational pattern. Practitioners should measure how quickly they can detect and interrupt repeated publication anomalies.

What this signals

Release storm camouflage: repeated low-signal publishing events can normalise anomalous behaviour and reduce the chance that teams notice a real compromise. The operational lesson is to baseline cadence, not just content, because automated pipelines can generate noise without changing code. For programmes already managing secrets and workflow credentials, this is a reminder that visibility into non-human identities must extend into CI/CD execution paths, not stop at vault inventory.

The governance signal is that CI/CD is now part of the identity perimeter. When a workflow can publish on behalf of a project, it needs the same accountability you would expect from any privileged service account. Teams that already map automation to lifecycle controls will be better positioned to spot when a normal pipeline becomes a repeated authority exercise.

For practitioners, the next step is not broader monitoring alone but control binding. If a release job cannot prove why it is publishing, then the environment has a non-human identity with standing privilege and weak lifecycle checks. That is the point at which supply chain governance and NHI governance become the same problem.

For practitioners

• 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. This prevents a scheduled job from re-exercising the same privilege without a new change.
• Test undefined and fallback paths Add unit and integration tests for undefined inputs, missing labels, and default resolution in release scripts. The bug in this case came from a default not being applied, so test coverage must include silent failure paths.
• Alert on release cadence anomalies Create monitoring for package publication bursts, repeated semantic version bumps, and identical release metadata within short windows. Pair the alert with workflow execution logs so teams can distinguish normal automation from a release storm.
• Review workflow permissions as delegated identity Treat GitHub Actions and similar pipelines as privileged non-human identities, then scope credentials, permissions, and repository write access accordingly. Use the NHI Lifecycle Management Guide to align provisioning, rotation, and offboarding for automation credentials.

Key takeaways

• The incident shows that a trusted package workflow can become a repeated authority path when state validation fails.
• The scale was not a one-off glitch, but 70+ ghost releases in a short window, which is enough to distort trust signals in a major dependency ecosystem.
• The control that matters most is explicit publish-state verification combined with release cadence monitoring and delegated identity governance.

Key terms

• Release Storm: A release storm is a burst of repeated software publications that should have happened once or not at all. It usually points to broken automation, not deliberate change, and it can pollute package history, mask real activity, and erode trust in the software supply chain.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.
• Publish-State Validation: Publish-state validation is the control that confirms a package, artefact, or release has not already been handled before automation runs again. It prevents duplicate actions caused by stale metadata, undefined defaults, or repeated scheduled triggers, and it is a core safeguard in release governance.

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

👉 StepSecurity's full post covers the release chain, root cause, and fix timeline in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control discipline needed for workflows, service identities, and delegated automation.