Why software delivery cannot depend on trust alone

Spectra Assure Free Trial Get your 14-day free trial of Spectra Assure for Software Supply Chain Security Get Free TrialMore about Spectra Assure Free TrialResearchers at Upwind found that attackers injected malware directly into the AsyncAPI project’s 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 infrastructure is compromised, every downstream environment that consumes those packages is exposed. Here's what you can take away from the AsyncAPI attack. [ Learn: Why RL Built Spectra Assure Community | Sign Up for Free ] Amiram Shachar, CEO and co-founder of Upwind, told Cybersecurity Dive that multiple official AsyncAPI packages were published with backdoored code from separate repositories and pipelines — a sign that attackers are increasingly targeting the release process itself. “This wasn’t just a malicious package. It was a compromise of trust.” —Amiram Shachar Dwayne McDaniel, a developer advocate at GitGuardian, called the AsyncAPI case the widest attack path of any recent worm he has tracked. “There were so many branches and pipelines used at once.” —Dwayne McDaniel 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. 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’s own trusted publishing workflows — and so the verification machinery that the industry tells everyone to adopt ended up vouching for the malware. “Provenance told the truth. These artifacts really were built by the official pipeline from the official repo. The truth was malicious.” —Michael Nov 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 “npm attack.” 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’s 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. “The usual advice — check the attestation, watch the install scripts — doesn’t catch this attack, because the attestation was real and the code runs when you import the library, not when it installs.” —Dan Moore Sr. The attacker also staged payloads across multiple destinations, Moore added, including an Ethereum dead drop that is effectively impossible to take down. 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. “We also need controls that assess what actually changed, whether that change was authorized, and what the resulting software does.” —Donald McFarlane 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. 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. “[But] far fewer have the same level of visibility into the identities, permissions, and workflows that actually publish their software.” —Kelvin Lim 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. Security teams can use this simple test, he said: Ask, Who can publish a release without another human approving it? “If the answer isn’t clear, your software supply chain probably has a bigger identity problem than you think,” Lim said. AsyncAPI’s report traced the root cause of the attack to overprivileged automation credentials, GitGuardian’s McDaniel noted, a problem that should be easy to identify and fix. “Attackers 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.” —Dwayne McDaniel 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. “Knowing where a change came from is important, but it doesn’t tell you whether the change itself is safe. The source of the change isn’t what determines risk.” —Ryan McCurdy 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. AI coding requires the stack be reconstructed with mathematical proofs built in — a task well suited to the Lean language. Here’s the reality. A new report finds weakening trust in AI-only testing — and more willingness to keep humans in the loop. Here's why. While this repository vector is not new, researchers have uncovered a new twist for exploiting trusted metrics to hide malicious code.