[cs-raj]

Problem

release-v1-legacy-plugins.yml publishes the 20 cli-plugins packages to npm under the v1-x dist-tag with a long-lived NPM_TOKEN, on every push to v1-legacy.

The SE1 publishing policy requires OIDC trusted publishing instead: no token, one release.yml that runs when a release is published, Node 24.

The last two runs also end red: the post-publish gh release create step fails with HTTP 401 (PKG_TOKEN is no longer valid, and its version variable is empty). And 15 packages' repository fields do not name this repo in the form npm checks at publish time.

Fix

release-v1-legacy-plugins.yml and .github/config/release.json are replaced by one release.yml, the same filename as on main, so one trusted publisher per package covers both lines.

	Before	After
Trigger	push to v1-legacy, manual run	release: published
npm auth	NPM_TOKEN	OIDC: id-token: write, no token
Publish	20 × JS-DevTools/npm-publish@v3 steps, tag: v1-x	one step per package in the same order, each running npm publish --access public --tag v1-x unless that version is already on npm
Node / npm	22.x / npm 10	24 / latest npm
Install	clean:all, then pnpm install --no-frozen-lockfile	pnpm install --frozen-lockfile
Checkout	branch head, credentials persisted	the release tag, persist-credentials: false
Actions	checkout, setup-node, pnpm/action-setup @v4	checkout @v7, setup-node @v7, pnpm/action-setup pinned to its v6.1.0 commit
package.json × 15	repository: contentstack/cli (11 packages), contentstack/audit, contentstack/cli-cm-regex-validate, a non-canonical cli-plugins URL (content-type), missing (variants)	git+https://github.com/contentstack/cli-plugins.git with directory, as on main: npm checks it against the publishing repo
Removed	json-to-variables + release.json (unused), corepack steps, gh release create (401)	—
.talismanrc	—	checksum exemption for release.yml: Talisman flags the pinned action SHA (false positive)

Deviations from the policy's sample workflow, all because this is a pnpm monorepo with 20 packages on a maintenance line:

1. pnpm/action-setup step: the repo uses pnpm.
2. cache: 'pnpm' instead of 'npm': there is no package-lock.json.
3. pnpm install --frozen-lockfile instead of npm ci: the same lockfile-strict install, for pnpm.
4. Explicit pnpm -r --sort run build: plugins depend on each other (import on audit and variants, clone on export and import, …), and a package skipped as already published never runs its prepack, so its dependents need its lib/ built up front.
5. One publish step per package, in the old workflow's order, skipping versions already on npm: one release publishes only what was bumped, and a failed step names its package and stops the job.
6. --tag v1-x: this line must never move latest.
7. Latest action majors instead of @v4 (v4 runs on Node 20, which is end-of-life); the third-party pnpm/action-setup is pinned to a commit SHA, as SRE recommended.

Verification

Node 22 and Node 24: frozen-lockfile install and build pass, and 4,128 unit tests pass. The 20 publish steps, run with npm publish stubbed, go in the old order with --tag v1-x, skip the versions already on npm, pick up bumped ones, and a failed step stops the job.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	262	25	✅ Passed
🟡 Medium Severity	0	382	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 262
• Medium without fixes: 382
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	204	25	✅ Passed
🟡 Medium Severity	0	166	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 204
• Medium without fixes: 166
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed