{"id":26175,"date":"2026-09-21T15:13:14","date_gmt":"2026-09-21T23:13:14","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2026\/09\/21\/why-software-delivery-cannot-depend-on-trust-alone\/"},"modified":"2026-09-21T15:13:14","modified_gmt":"2026-09-21T23:13:14","slug":"why-software-delivery-cannot-depend-on-trust-alone","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2026\/09\/21\/why-software-delivery-cannot-depend-on-trust-alone\/","title":{"rendered":"Why software delivery cannot depend on trust alone"},"content":{"rendered":"
\n
\n

Researchers at Upwind found that attackers injected malware directly into the AsyncAPI project\u2019s source repositories before the packages were published to the npm registry. <\/p>\n

The compromised packages moved through official publishing channels and thus looked legitimate to developers, who were at risk of pulling malicious code into their workstations and CI\/CD environments simply by importing the packages.<\/p>\n

The blast radius of the method extends well past any single application. Once release infrastructure is compromised, every downstream environment that consumes those packages is exposed.<\/p>\n

Here’s what you can take away from the AsyncAPI attack.<\/p>\n

[ Learn: <\/strong>Why RL Built Spectra Assure Community<\/strong><\/a> | <\/strong>Sign Up for Free<\/strong> <\/a>]<\/strong><\/p>\n

\u2018The truth was malicious\u2019<\/h2>\n

Amiram Shachar, CEO and co-founder of Upwind, told Cybersecurity Dive<\/span><\/a> that multiple official AsyncAPI packages were published with backdoored code from separate repositories and pipelines \u2014 a sign that attackers are increasingly targeting the release process itself.<\/p>\n

\u201cThis wasn\u2019t just a malicious package. It was a compromise of trust.\u201d<\/em>
\u2014<\/em>Amiram Shachar<\/span><\/a><\/p>\n

Dwayne McDaniel, a developer advocate at GitGuardian, called the AsyncAPI case the widest attack path of any recent worm he has tracked.<\/p>\n

\u201cThere were so many branches and pipelines used at once.\u201d<\/em>
\u2014Dwayne McDaniel<\/span><\/a>\u00a0<\/p>\n

Pushing to multiple branches was a deliberate evasion play, he added. Protections cluster around the main and production branches, so infected side branches are easier to hide in until later legitimate commits.<\/p>\n

The attack worked as well as it did because the infected packages shipped with valid provenance attestations. Michael Nov, co-founder and CEO of Prime Security, said the attacker used AsyncAPI\u2019s own trusted publishing workflows \u2014 and so the verification machinery that the industry tells everyone to adopt ended up vouching for the malware.<\/p>\n

\u201cProvenance told the truth. These artifacts really were built by the official pipeline from the official repo. The truth was malicious.\u201d<\/em>
\u2014Michael Nov<\/span><\/a><\/p>\n

And because the payload executed upon module load rather than through an install hook, there had to be operational planning, Nov noted, putting the campaign well above the opportunistic typosquatting most people picture when they hear the words \u201cnpm attack.\u201d<\/p>\n

Dan Moore, Sr. director of customer identity and access management strategy at FusionAuth, said most package attacks are simple tampering: Someone steals an npm token and pushes a doctored tarball straight to the registry. AsyncAPI ran in reverse. The attacker exploited a misconfiguration to ship code under the identity of the project\u2019s release bot, which let the pipeline build, sign, and publish it. The malicious versions came out the far end legitimately published and carrying valid provenance.<\/p>\n

\u201cThe usual advice \u2014 check the attestation, watch the install scripts \u2014 doesn\u2019t catch this attack, because the attestation was real and the code runs when you import the library, not when it installs.\u201d<\/em>
\u2014<\/em>Dan Moore<\/span><\/a><\/p>\n

The attacker also staged payloads across multiple destinations, Moore added, including an Ethereum dead drop that is effectively impossible to take down.<\/p>\n

The trust gap with supply chain security<\/h2>\n

Donald McFarlane, an advisory board member at Xcape, noted that software supply chain security has spent a great deal of effort on proving where an artifact has come from. That work is necessary; this incident shows it is not sufficient.<\/p>\n

\u201cWe also need controls that assess what actually changed, whether that change was authorized, and what the resulting software does.\u201d<\/em>
\u2014Donald McFarlane<\/span><\/a><\/p>\n

Enterprises that do not enforce a cool-down period on newly released packages need strong change and release management controls around open-source dependencies in their CI\/CD processes, including careful auditing and analysis, he said. Every organization should also have a rapid remediation path ready for the moment a malicious package reaches development or production systems.<\/p>\n

Trust is still a weakness in many AppSec programs, said Kelvin Lim, a director and Asia-Pacific head of security engineering at Black Duck Software. Most security teams he talks with in the region have software composition analysis, dependency scanning, and software bills of materials (SBOMs) well covered.<\/p>\n

\u201c[But] far fewer have the same level of visibility into the identities, permissions, and workflows that actually publish their software.\u201d<\/em>
\u2014<\/em>Kelvin Lim<\/span><\/a><\/p>\n

An SBOM tells you what is inside the software but not who published it, what identity they used, and whether that identity should have had the permission. Better scanners are not the answer, Lim said. What is needed is pipeline identity governance: short-lived credentials, tightly scoped permissions, human review for workflows that handle untrusted input, and provenance controls that examine the build environment as well as the final artifact.<\/p>\n

Security teams can use this simple test, he said: Ask, Who can publish a release without another human approving it? \u201cIf the answer isn\u2019t clear, your software supply chain probably has a bigger identity problem than you think,\u201d Lim said.<\/p>\n

Overprivileged credentials are the root cause<\/h2>\n

AsyncAPI\u2019s report traced the root cause of the attack to overprivileged automation credentials, GitGuardian\u2019s McDaniel noted, a problem that should be easy to identify and fix.<\/p>\n

\u201cAttackers will always work to evade known detectors and tripwires, no matter how many we make or how fancy we make them. We must evolve our systems and processes to eliminate the low-hanging fruit of long-lived credentials, especially in our build pipelines and on local machines.\u201d<\/em>
\u2014Dwayne McDaniel\u00a0<\/p>\n

Software delivery can no longer depend on trust, said Ryan McCurdy, vice president of marketing at Liquibase, because attackers can compromise trusted infrastructure and use it to make malicious changes look legitimate.<\/p>\n

\u201cKnowing where a change came from is important, but it doesn\u2019t tell you whether the change itself is safe. The source of the change isn\u2019t what determines risk.\u201d<\/em>
\u2014Ryan McCurdy<\/span><\/a><\/p>\n

Attestation answers a question about origin. Deciding whether a release is safe to ship or consume takes analysis of the final, assembled artifact using binary-level inspection tools that will catch malware, tampering, and behavior changes that a clean provenance record will never surface.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Researchers at Upwind found that attackers injected malware directly into the AsyncAPI project\u2019s source repositories before the packages were published to the npm registry.The compromised packages moved through official publishing channels and thus looked legitimate to developers, who were at risk of pulling malicious code into their workstations and CI\/CD environments simply by importing the packages.The blast radius of the method extends well past any single application. Once release infrastru<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[32775],"tags":[],"class_list":["post-26175","post","type-post","status-publish","format-standard","hentry","category-reversinglabs"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=26175"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26175\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=26175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=26175"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=26175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}