[cs-raj]

Problem

release-v1-legacy.yml and the two workflows it calls publish the 5 cli 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 four runs also end red: the post-publish gh release create step fails with HTTP 403. And the packages' repository fields are not in the form npm checks at publish time.

The pre-commit Snyk scan also blocks every commit on this branch: traverse@0.6.11 has a prototype pollution advisory, which main already overrides.

Fix

The three workflows 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	5 × JS-DevTools/npm-publish@v3 steps, tag: v1-x: utilities, command, config, auth, then core	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 × 5	repository: "contentstack/cli" (auth, command, config), empty url (utilities), https://github.com/contentstack/cli (core)	git+https://github.com/contentstack/cli.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 (403)	—
.talismanrc	—	checksum exemption for release.yml: Talisman flags the pinned action SHA (false positive)
pnpm-workspace.yaml, pnpm-lock.yaml	no traverse override, 0.6.11 locked	traverse: 0.6.14 override, as on main; lockfile refreshed with update:lockfile

Deviations from the policy's sample workflow, all because this is a pnpm monorepo with 5 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: when a release publishes only core, the skipped packages' prepack never runs, and core's build needs their lib/.
5. One publish step per package, in the old workflows' order (utilities, command, config, auth, core), 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, build and unit tests pass (277 passing). The publish steps, run with npm publish stubbed, go in the old order with --tag v1-x, skip the 5 versions already on npm, pick up a bumped one, 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	162	25	✅ Passed
🟡 Medium Severity	1	204	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

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	1	90 / 365 days	⚠️ Warning
🔵 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: 162
• Medium without fixes: 204
• Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.