npm audit signatures on @sume-com/sdk 0.2.0: what it proves, what not

Run npm audit signatures on @sume-com/sdk 0.2.0 before deploy. It checks the registry signature; the registry lists no provenance attestation for this version.

4 min readSume
All posts

Run npm audit signatures after installing @sume-com/sdk@0.2.0: it verifies the registry signature of the tarball you installed, and in our run it reported no invalid and no missing signatures. It does not prove that the package was built from a particular commit. The npm registry metadata for 0.2.0 that we read lists a signature but no provenance attestation, so a clean result means the registry vouches for the bytes, not that a build log does. That is still useful: it catches a tampered mirror or a corrupted cache, which is the common failure in a CI pipeline.

This is worth doing now because Node.js 26.11.0, released October 7, bundles npm 11.20.0 according to its release notes, and many teams will refresh their toolchains and lockfiles as Node 26 moves to LTS. The commands below were run with npm 10.9.2 on a fresh project; we did not run them on npm 11.20.

What each check tells you

The SDK is small by design: the SDK docs and the package metadata agree that it is MIT licensed and has no runtime dependencies. That keeps the audit surface to one package, which makes the signature step cheap. The table lists what we saw and what it implies.

npm checks for @sume-com/sdk 0.2.0 (read 2026-10-08)
CheckResult in our runWhat it means
LicenseMITMatches the SDK docs
Runtime dependenciesNone listedOne package to audit
Registry signaturesPresent on 0.2.0npm audit signatures can verify them
npm audit signaturesNo invalid, no missingTarball matches the signed registry record
Provenance attestation on 0.2.0None in registry metadataNo build-to-source link to check

Steps

  • Pin the version exactly with --save-exact. In a 0.x range a caret allows only patch updates, so a new minor needs an explicit edit.
  • Run npm audit signatures in CI after npm ci, and fail the job on any invalid or missing result.
  • Record the dist.integrity value from npm view next to the version in your change log so a later reinstall can be compared.
  • Keep the audit in the same job that builds the container image, so the artifact you ship is the artifact you checked, not a later reinstall.
  • Review the lockfile diff whenever the SDK version changes; the signature check does not tell you what changed.

Commands

The last line reads the registry record directly and prints how many signatures and attestations it lists.

npm install --save-exact @sume-com/sdk@0.2.0
npm audit signatures
npm view @sume-com/sdk@0.2.0 license dependencies dist.integrity
curl -s "https://registry.npmjs.org/@sume-com%2fsdk/0.2.0" | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{const d=JSON.parse(s).dist;console.log("signatures:",d.signatures.length,"attestations:",d.attestations??"none")})'

What Sume does not do

Sume does not claim a supply-chain attestation for 0.2.0 on this page, and the check above does not replace reading the code or pinning your dependencies. Because the generated functions and helpers in the SDK are plain TypeScript compiled to ESM, you can also read the published dist folder after install if your policy needs a manual review.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume