The ai npm account is the sole publisher of postcss (243M/wk), browserslist (167M/wk), caniuse-lite (172M/wk), nanoid (171M/wk), autoprefixer (63M/wk), and postcss-js (53M/wk). Combined: ~869 million weekly downloads behind one set of credentials.
None of these packages have npm provenance attestations.
I see #2092 was closed because the proposed approach was "not secure" — fair, storing an npm token in a GitHub Actions secret is weaker than a local publish. But npm OIDC Trusted Publishing is fundamentally different: no stored secrets at all. The registry accepts a short-lived OIDC token from GitHub Actions and stamps the package with an attestation linking it to a specific commit, workflow, and runner. If the ai account is phished or the local token is stolen, a locally-published version is indistinguishable from a legitimate release. With provenance, it isn't — consumers (and npm itself) can verify the source.
This isn't theoretical. In the past 60 days:
- Shai-Hulud worm (May 19): compromised
atool npm account → 637 malicious versions across 323 packages in 39 minutes, ~16M weekly downloads affected
- axios token theft (Mar 30): sole publisher, 113M weekly downloads
- LiteLLM (Mar 2026): sole publisher, PyPI
All three exploited the exact same gap: single publisher + no provenance = undetectable local-machine compromise.
fast-xml-parser (88M/wk, single publisher) adopted OIDC provenance this month after the same pattern was flagged. Took one PR, and now every version since 5.9.1 carries a verifiable attestation.
PostCSS already has a release workflow (.github/workflows/release.yml) that runs on tag push and creates GitHub releases. Adding provenance: true to an npm publish step in the same workflow would be minimal lift.
A secondary hardening worth considering: adding one backup publisher to the npm scope. Not to change who publishes — just so that if the ai account is locked, compromised, or unavailable, recovery doesn't require npm support intervention.
Behavioral supply chain data from a batch audit:
| Package |
Score |
Publishers |
Downloads/wk |
Provenance |
| postcss |
83 |
1 |
243M |
— |
| caniuse-lite |
82 |
1 |
172M |
— |
| nanoid |
80 |
1 |
171M |
— |
| browserslist |
82 |
1 |
167M |
— |
| autoprefixer |
81 |
1 |
63M |
— |
| postcss-js |
79 |
1 |
53M |
— |
The
ainpm account is the sole publisher of postcss (243M/wk), browserslist (167M/wk), caniuse-lite (172M/wk), nanoid (171M/wk), autoprefixer (63M/wk), and postcss-js (53M/wk). Combined: ~869 million weekly downloads behind one set of credentials.None of these packages have npm provenance attestations.
I see #2092 was closed because the proposed approach was "not secure" — fair, storing an npm token in a GitHub Actions secret is weaker than a local publish. But npm OIDC Trusted Publishing is fundamentally different: no stored secrets at all. The registry accepts a short-lived OIDC token from GitHub Actions and stamps the package with an attestation linking it to a specific commit, workflow, and runner. If the
aiaccount is phished or the local token is stolen, a locally-published version is indistinguishable from a legitimate release. With provenance, it isn't — consumers (and npm itself) can verify the source.This isn't theoretical. In the past 60 days:
atoolnpm account → 637 malicious versions across 323 packages in 39 minutes, ~16M weekly downloads affectedAll three exploited the exact same gap: single publisher + no provenance = undetectable local-machine compromise.
fast-xml-parser(88M/wk, single publisher) adopted OIDC provenance this month after the same pattern was flagged. Took one PR, and now every version since 5.9.1 carries a verifiable attestation.PostCSS already has a release workflow (
.github/workflows/release.yml) that runs on tag push and creates GitHub releases. Addingprovenance: trueto an npm publish step in the same workflow would be minimal lift.A secondary hardening worth considering: adding one backup publisher to the npm scope. Not to change who publishes — just so that if the
aiaccount is locked, compromised, or unavailable, recovery doesn't require npm support intervention.Behavioral supply chain data from a batch audit: