The AsyncAPI Compromise and the Limits of Software Provenance

Why valid provenance, trusted publishing, and authenticated build pipelines can still produce malicious software.

As software supply chain attacks have become more sophisticated, the industry’s response has been equally ambitious. Frameworks such as SLSA, Sigstore, in-toto, and trusted publishing have strengthened our ability to verify where software came from and how it was built. But as these controls have matured, attackers have increasingly shifted their focus from breaking security mechanisms to exploiting the trust relationships that exist around them.

If you’re new to software provenance or would like a refresher on how provenance attestations are generated and verified, we’ve covered those fundamentals in our earlier article, Understanding Image Provenance: Proof of Where Your Container Came From. This article assumes that foundation and explores a different question.

On July 14, 2026, several packages from the AsyncAPI project were published to npm carrying malicious code. At first glance, the incident looked like another software supply chain compromise. But a closer examination revealed something unusual. The packages weren’t published using a stolen npm token. They weren’t signed with forged identities. Nor did the attacker bypass the project’s release pipeline.

Instead, the malicious packages were produced by AsyncAPI’s own GitHub Actions workflow, published through npm’s Trusted Publishing integration using OpenID Connect (OIDC), and accompanied by valid SLSA provenance attestations. From the perspective of the build infrastructure, everything had happened exactly as expected.

At first glance, these facts appear contradictory.

If the published packages carried valid provenance, how did malicious code still make its way to users?

The provenance generated for these packages was technically correct. It accurately described the repository, commit, workflow, builder identity, and artifacts that participated in the release. The compromise occurred somewhere else. Understanding where that trust boundary exists is essential because software provenance is becoming a foundational security control across modern software supply chains. Like every security mechanism, however, it is designed to answer a specific set of questions, not every question we might wish to ask.

By reconstructing how the AsyncAPI attack unfolded and why every provenance check still succeeded, we can better understand both the strengths and the limits of software provenance as a security primitive.

Reconstructing the Compromise

Unlike many software supply chain attacks, the AsyncAPI compromise did not begin with a stolen npm token or a malicious package uploaded directly to the registry. Instead, the attacker targeted an earlier stage of the software supply chain: the source repository that fed the project’s release pipeline.

Public reports indicate that the attacker gained the ability to push commits to the next branch of the asyncapi/generator repository. Although the exact method used to obtain that access has not been publicly disclosed, it isn’t necessary to understand the broader lesson from this incident. What matters is what happened after the repository itself was compromized.

Once the malicious commit became part of the repository, the project’s automated release process took over.

The push triggered AsyncAPI’s release-with-changesets.yml GitHub Actions workflow, which built the packages from the modified source. The workflow authenticated to npm using GitHub’s OpenID Connect (OIDC) Trusted Publishing integration, generated software provenance as part of the release, and published the resulting packages to the npm registry. Throughout this process, no npm credentials were stolen, no signing keys were forged, and no unauthorized release mechanism was introduced.

Shortly afterward, a second AsyncAPI repository, asyncapi/spec-json-schemas, was compromised using the same approach. Malicious packages were again published through the repository’s legitimate GitHub Actions workflow, following the project’s established release process.

Viewed as a timeline, the compromise unfolded as follows:

Each step followed logically from the one before it. The attacker didn’t need to circumvent the release pipeline because the release pipeline itself was never the target. Once the source repository had been compromised, the automated build and publishing infrastructure simply executed the workflow it had been designed to perform.

Why the Provenance Was Still Valid

At this point, the incident appears contradictory. The published packages contained malicious code, yet they were built by AsyncAPI’s legitimate GitHub Actions workflow, published through npm’s Trusted Publishing integration, and accompanied by valid SLSA provenance. If provenance is intended to strengthen software supply chain trust, how could all these statements be true at the same time?

The answer lies in understanding exactly what software provenance is designed to establish.

In the AsyncAPI compromise, the generated provenance accurately described the software that was published. The build originated from the expected repository, was triggered by the recorded source revision, executed through the project’s authorized GitHub Actions workflow, and produced the artifacts that were ultimately published to npm. None of those facts were incorrect. The provenance faithfully captured the build process exactly as it occurred.

This is an important distinction. Software provenance does not evaluate the intent behind the source code being built. It does not determine whether a commit is benign or malicious, whether a contributor’s account has been compromised, or whether the contents of a repository reflect the maintainers’ intentions. Its responsibility is narrower, but no less important: to establish the authenticity and integrity of the build process.

That distinction explains why the AsyncAPI provenance remained valid despite the compromise. By the time the GitHub Actions workflow started, the malicious changes had already become part of the repository. From the build system’s perspective, it was simply compiling and publishing the source revision it had been instructed to build. The provenance generated during the release accurately reflected that sequence of events.

This is not a weakness in software provenance. Rather, it is a consequence of its design. Provenance answers questions such as:

• Was this artifact built from the recorded source revision?
• Was it produced by the expected build workflow?
• Did it originate from the authenticated build system?
• Has the artifact remained unchanged since it was built?

Those are precisely the guarantees provenance is intended to provide, and in the AsyncAPI incident, those guarantees continued to hold.

The compromise occurred outside that trust boundary. 

Once an attacker was able to introduce malicious code into the source repository before the build began, the release pipeline had no basis for distinguishing between an intended commit and a malicious one. As a result, it generated provenance for the software it was asked to build, accurately documenting a process that was authentic, even though the resulting software was not trustworthy.

Understanding this distinction is essential. The AsyncAPI compromise did not expose a failure of software provenance. It demonstrated that provenance and trustworthiness answer different questions. Provenance establishes that software was built through an authentic and verifiable process. It does not, by itself, establish whether the software entering that process should have been trusted in the first place.

The Limits of Software Provenance

Every security control is designed to answer a specific set of questions. Firewalls regulate network traffic. Identity systems verify who is requesting access. Encryption protects data from unauthorized disclosure. Each control has a clearly defined purpose, and understanding that purpose is essential to using it effectively.

Software provenance is no different.

Its role is to establish the authenticity of the software production process. It provides verifiable evidence of where an artifact came from, the source revision it was built from, the build system that produced it, and the relationship between the source and the published artifact. Those guarantees are both valuable and necessary for securing modern software supply chains.

The AsyncAPI compromise illustrates where those guarantees begin and where they end. The attacker didn’t manipulate the build process or falsify the provenance. Instead, they influenced what entered the build process. Once the malicious source became part of the repository, the release pipeline faithfully transformed it into authenticated software artifacts, accurately documenting every stage of that process.

In practice, software provenance begins recording the software supply chain only after the build process starts. By that point, several important trust decisions have already been made. A contributor has introduced source code. A repository has accepted a commit. A branch has triggered a release workflow. The build system assumes that these earlier decisions have already established what should be built. Provenance then records how that software was built, not whether it should have been built.

This distinction becomes clearer when we examine the questions provenance is designed to answer.

he final question is perhaps the most important. Trustworthiness depends on factors that extend beyond the scope of provenance itself. It requires confidence in the integrity of the source repository, the development workflow, the maintainers, and the software entering the build process. Provenance provides strong evidence that software was built authentically, but authenticity alone cannot determine whether the resulting software deserves trust.

The lesson from the AsyncAPI compromise is therefore not that software provenance is inadequate. It is that provenance should be understood within its intended security boundary. When interpreted correctly, it remains one of the most important advances in software supply chain security. But like every security control, its guarantees are strongest when combined with complementary practices that establish trust before the build process begins.

Conclusion

The AsyncAPI compromise did not expose a weakness in software provenance. Instead, it clarified the role that provenance plays within a modern software supply chain.

The provenance generated for the compromised packages was accurate. It correctly identified the source repository, the source revision, the build workflow, the builder identity, and the published artifacts. The release pipeline executed through authenticated infrastructure using established Trusted Publishing mechanisms, producing exactly the evidence it was designed to produce.

The compromise occurred before the build process began.

Once malicious code entered the source repository, the build system faithfully transformed that source into software artifacts, and the provenance faithfully documented how those artifacts were produced. From the perspective of software provenance, the recorded evidence was correct. The problem was never the authenticity of the build process; it was the trustworthiness of the source entering that process.

That distinction is becoming increasingly important as software supply chains continue to automate. Modern build systems can now provide strong cryptographic guarantees about software origin, build integrity, and artifact authenticity. Those capabilities represent a significant advancement for software supply chain security. But they should be understood for what they are: guarantees about the integrity of the build process, not judgments about the intent or integrity of the software being built.

The AsyncAPI compromise reminds us that no single security control is designed to answer every question. Software provenance answers one of the most important questions in software supply chain security: Where did this software come from, and how was it built? It does so with a level of assurance that was difficult to achieve only a few years ago.

The equally important question, however, is Should this software be trusted?

The AsyncAPI compromise serves as a reminder that authenticity and trustworthiness are not interchangeable. Provenance provides confidence that software was built through an authentic, verifiable process. Building trustworthy software supply chains requires ensuring that what enters that process is worthy of trust as well.