Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

AsyncAPI supply chain attack: what CI/CD compromise means for teams


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 17031
Topic starter  

TL;DR: Attackers used compromised GitHub push access, not stolen npm tokens, to publish malicious AsyncAPI packages with valid OIDC provenance, showing how trusted CI/CD release workflows can be turned into malware delivery paths, according to StepSecurity. The lesson for practitioners is that provenance proves workflow legitimacy, not commit legitimacy, so push controls and runner egress monitoring matter.

NHIMG editorial — based on content published by StepSecurity: Coordinated AsyncAPI Supply Chain Attack with Miasma RAT delivered via compromised CI/CD pipelines

By the numbers:

Questions worth separating out

Q: What breaks when CI/CD release workflows can be triggered by a compromised push credential?

A: The release pipeline becomes an attacker-controlled publishing path.

Q: Why do provenance attestations not fully solve supply chain compromise?

A: Provenance proves which workflow produced the artifact, but it does not prove the triggering change was authorised or safe.

Q: How do security teams know if a package compromise has become runtime execution?

A: Look for behaviour that occurs when the package is imported, not only when it is installed.

Practitioner guidance

  • Tighten branch protection on release-bearing repositories Require code-owner review, signed commits, and restricted push rights on branches that can trigger publishing workflows.
  • Limit CI/CD workflow trigger authority Review which events can invoke release jobs, especially push-based triggers, version tags, and commit-message patterns.
  • Monitor runner egress and child-process behaviour Baseline expected network destinations for build jobs and block unexpected outbound access such as IPFS gateways, DHT nodes, or unusual HTTP C2 endpoints.

What's in the full article

StepSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

  • Commit-by-commit attack timeline across both AsyncAPI repositories, including the exact workflow runs that published each malicious version
  • Static decoding notes for the obfuscated dropper and the stage-two Miasma RAT payload architecture
  • Runtime telemetry from monitored GitHub Actions jobs showing the outbound channels used by the payload
  • Exposure-window and remediation chronology for each affected package version

👉 Read StepSecurity's analysis of the AsyncAPI CI/CD supply chain attack →

AsyncAPI supply chain attack: what CI/CD compromise means for teams?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 16618
 

Trusted publishing shifts the control point, but it does not remove the identity problem. OIDC-based package publication reduces secret theft, yet the real security question becomes who can trigger the workflow and under what conditions. In this attack, the release pipeline was functioning as designed, which means the governance gap sat in branch control and repository trust rather than the registry itself. Practitioners should treat the workflow trigger as a privileged boundary, not a convenience feature.

A few things that frame the scale:

A question worth separating out:

Q: Who is accountable when a release workflow publishes malicious code through trusted publishing?

A: Accountability spans repository owners, release engineers, and platform teams that control branch protections and workflow permissions. Trusted publishing shifts responsibility upward into the CI/CD identity layer, so organisations need clear ownership for who can trigger releases, approve workflow changes, and monitor execution behaviour.

👉 Read our full editorial: Compromised CI/CD pipelines turned AsyncAPI release workflows into malware



   
ReplyQuote
Share: