Microsoft's security team published its analysis of the July 14 compromise of the AsyncAPI npm packages, including @asyncapi/specs and the generator packages. Two details change how I think about this class of attack.
The way in was familiar: a GitHub Actions workflow using pull_request_target ran code from an attacker's pull request with the repository's privileges and exposed the bot account's token. It is the same door the TanStack attackers used in May.
The way the payload ran is the new part. Most npm malware runs in an install script, which is why –ignore-scripts has been the standard advice. This payload did not use install hooks at all. It ran when the module was loaded, when some code did require or import on it, which means it ran in every process that used the package, every time, and no install flag could stop it.
I think this settles something. The install-time defenses were always a partial answer, and now they are not an answer. Supply chain defense for a JavaScript team lives in two places: the configuration of the release pipeline, where pull_request_target and secrets exposure are decisions someone made and can unmake, and the policy for what is allowed into the dependency tree in the first place, with a minimum age, a review of lockfile changes, and secrets scoped so a compromised package finds nothing to take.
Front-end teams own both.
If a dependency ran code the moment it was imported, what in your pipeline would notice?
Photo source: https://photos.robertstowe.com/tasmania