security(release): enable npm provenance, use `--frozen-lockfile` in deploy/publish workflows, restrict `workflow_dispatch`

[IgorShevchik]

Background

Surfaced during the June 2026 multi-angle project audit (security + CTO reviews). Adjacent to #64 but none of these items are covered there (#64 = permissions: blocks, action SHA-pinning, pull_request_target audit, branch protection — not re-reported here).

Scope

1. npm provenance is configured halfway

.github/workflows/npm-publish.yml:8-11 grants id-token: write, but the publish step (lines 72-74) runs pnpm publish --no-git-checks with no --provenance and package.json has no publishConfig.provenance. Result: the elevated OIDC permission is unused and the package ships without a provenance attestation.
Action: add --provenance (or "publishConfig": { "provenance": true }); verify the Trusted Publishing binding on npmjs.com actually exists; otherwise drop the unused id-token: write.

2. pnpm install without --frozen-lockfile at the most sensitive moments

ci.yml:36 correctly uses --frozen-lockfile, but deploy.yml:52 (Pages build) and npm-publish.yml:64 (the publish build) do not. A drifted or tampered lockfile, or an in-range dependency bump, gets silently resolved at build/publish time.
Action: pnpm install --frozen-lockfile in both.

3. workflow_dispatch permits publishing from any ref

Action: restrict the dispatch path to main/tags (guard step comparing github.ref), so a stray branch can't be published manually.

4. Note

The CI gate in npm-publish.yml is a 30-minute polling loop waiting for the ci check on the SHA — works, but consider workflow_run chaining for robustness.

Priority: P2 (§1–§2 quick, high supply-chain value).

[IgorShevchik]

Closed by #468 — though not quite in the way the issue expected, so here is the honest scorecard.

§1, provenance — done, and the diagnosis needed a correction. The issue said the package ships without an attestation. It does not: npm view @bitrix24/b24ui-nuxt@2.12.0 dist.attestations returns one, because npm attaches provenance by itself when a publish authenticates through trusted publishing. The id-token: write was doing its job all along.

The flag went in anyway, and the reason took two attempts to get right. The first version of the PR claimed a removed OIDC binding would fall back to token auth and publish unattested — wrong, because this job holds no npm token at all, so without OIDC the publish simply fails at authentication. What --provenance actually guards is the next step a person takes in that situation: adding a NODE_AUTH_TOKEN to get publishing working again. Under token auth npm stops attesting silently; with the flag and the id-token: write already present, it keeps attesting. That is the difference between provenance being a property of this repository and a property of a setting on npmjs.com.

§2, --frozen-lockfile — done, and the hole was not there. pnpm turns the setting on by itself whenever CI is set, and Actions always sets it, so deploy.yml's bare pnpm install was already frozen. The flag is explicit now because a guarantee resting on an environment variable is not visible to anyone reading the file, and .github/scripts/assert-lockfile-frozen.py keeps it there. The regression it exists to catch is the deliberate one — --no-frozen-lockfile added to turn a red build green — which is a one-line change nobody re-reads.

frozen-lockfile=true in .npmrc came up as a cheaper equivalent and is not one: .npmrc is committed, so it reaches contributors, and both PORTING.md §6 and the contribution guide tell people to run a bare pnpm install that would then start failing. That reasoning now lives in the script's docstring so it does not have to be worked out again.

§3, restricting workflow_dispatch — already solved, better than proposed. The issue asked for a guard comparing github.ref. npm-publish.yml instead asserts through the compare API that github.sha is merged main history, which is strictly stronger: a release run's ref is the tag, and a tag can point anywhere. A commit built on top of main returns ahead, a fork branch returns diverged, and only identical or behind proceed. It also fails closed when the API is unreachable. Nothing to do.

§4, the 30-minute polling loop — not done, filed as #469. It works and it has not failed; the objections are idle runner time, an arbitrary ceiling that would fail a slow-but-fine CI run, and re-implementing something the platform provides. The rewrite is not a one-liner — workflow_run executes the default branch's copy of the workflow and carries the default branch head as github.sha, and this publish has three trigger paths that would all need to converge on the same guard — so it gets its own issue rather than being smuggled in here.

A note for anyone auditing this later: two of the four items turned out to be already-safe, and the PR says so in both places rather than claiming credit. A security issue that closes with "this was fine, here is why" is worth as much as one that closes with a fix — and a lot more than one that closes with a fix for a problem that did not exist.

Thanks for filing it. The June audit is still paying for itself.

---

Generated by Claude Code