Release job runs install-time scripts and unpinned tooling while holding the npm OIDC publish token #2483

Severity: Medium (supply chain). CWE: CWE-829, CWE-1357. Status: design weakness, plausible attack path; not exploited.

What

In .github/workflows/main.yml the release/publish job (about lines 212-300) has permissions: id-token: write
(npm trusted publishing) and, in the same job:

1. npm install -g npm@^11.5.1 floats to whatever 11.x is current.
2. npm install (not npm ci) does not fail on lockfile drift, and the root postinstall
   (scripts/install-clients.mjs) runs npm install with lifecycle scripts enabled in clients/web, clients/cli, clients/tui.
3. Every action in the job (actions/checkout@v7, actions/setup-node@v7) is a mutable tag.

Any dependency install script executing in this job runs in the same process environment where the OIDC token request
variables exist, so a compromised transitive dependency could request an OIDC token and publish under the trusted-publisher identity.

Why it matters

The scheduled workflows in this repo already do the right thing (npm ci --ignore-scripts in sdk-watch.yml:98 and
dependabot-alerts.yml:94), so the release job is the outlier and the only one that can publish.

Verified / not verified

• Verified by reading the workflow and scripts/install-clients.mjs (spawns npm install per client, no --ignore-scripts).
• npm audit --package-lock-only and osv-scanner show 0 known vulnerabilities today, so this is a hardening issue, not a live compromise.
• Not verified: whether the trusted-publisher config on npmjs.com restricts by workflow file and environment.

Suggested change (for maintainers' workflow)

• Split into a build job (no id-token) that produces the tarball as an artifact, and a publish job that only
  downloads it and runs npm publish --provenance, with no dependency install.
• If a single job is kept: npm ci, and run the repo's own install-clients.mjs explicitly with clients installed via npm ci --ignore-scripts.
• Pin npm to an exact version and all actions to commit SHAs (see the companion issue on SHA-pinning).
• Consider a protected GitHub Environment with required reviewers for publish.

Reviewed at 1e31c78 (v2.8.0). No fix code is offered, per CONTRIBUTING.md.

Prompt used (per CONTRIBUTING.md)

"Audit this repository's CI workflows and one crypto module against the OpenSSF/CRA-friendly checklist. Run Semgrep,
osv-scanner, gitleaks and trufflehog; read every cited line before accepting a finding; reproduce any crypto claim on the
lowest supported Node version; drop findings that are test fixtures or already mitigated."