Harden CI/CD workflows with pinned action versions and security

[OskarDamkjaer]

All changes committed and pushed. Here's the motivation for each change:

---

Change Motivation & Sources

1. Pin all actions to full commit SHAs

Why: In March 2025, the tj-actions/changed-files action (used in 23,000+ repos) was compromised when attackers stole a PAT and rewrote mutable version tags to inject malicious code that dumped CI secrets to public logs. Mutable tags (@v4) can be silently rewritten at any time — pinning to a commit SHA makes this impossible.

Sources:

• [GitHub Blog: Actions Policy Now Supports SHA Pinning (Aug 2025)](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
• [GitHub Docs: Security hardening — using third-party actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
• [StepSecurity: Pinning GitHub Actions for Enhanced Security](https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide)

2. Add timeout-minutes: 30 to all jobs

Why: The default timeout is 360 minutes (6 hours). A stuck process — a hanging test, a deadlocked build, or a network issue — will silently consume your entire runner allocation. Explicit timeouts ensure fast failure and prevent billing surprises.

Sources:

• GitHub Docs: jobs.<job_id>.timeout-minutes
• [GitHub Well-Architected: Actions Best Practices](https://wellarchitected.github.com/library/application-security/recommendations/actions-security/)

3. Add explicit permissions to all workflows

Why: Without explicit permissions, GITHUB_TOKEN inherits the repository's default permissions (typically write for most scopes). This violates the principle of least privilege — if a workflow is compromised, the attacker gets broader access than necessary. Setting permissions: contents: read at the workflow level and elevating per-job narrows the blast radius.

Sources:

• [GitHub Docs: Setting permissions for GITHUB_TOKEN](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token)
• [GitHub Security Lab: Preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/)

4. Standardize NODE_OPTIONS to --max_old_space_size=8192

Why: The value was inconsistent: setup-and-build used 4096, ci.yaml used 8192, deploy-demo.yml used 4096. This causes unpredictable OOM failures depending on which workflow runs and whether the build step's NODE_OPTIONS or the workflow-level one takes effect. Standardizing to 8192 across all workflows eliminates this inconsistency.

Sources:

• Node.js Docs: --max-old-space-size

5. Add concurrency groups to remaining workflows

Why: Without concurrency controls, multiple runs of the same workflow can execute simultaneously — wasting resources (benchmark, formatting check) or causing race conditions (publish workflows pushing versions concurrently). For publish workflows, cancel-in-progress: false ensures a running publish completes rather than being cancelled mid-release.

Added to: benchmark.yaml, pre-release-vscode-extension.yaml, publish-vscode-extension.yaml, formatting-integrity-check.yaml

Sources:

• [GitHub Docs: Using concurrency](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency)

6. Check CI conclusion before npm publish

Why: publish-npm-packages.yaml triggers on workflow_run: completed, but completed fires regardless of whether CI passed or failed. Without if: github.event.workflow_run.conclusion == 'success', a failed CI run could still trigger a publish attempt. Added the condition to both the stable and canary release jobs.

Sources:

• GitHub Docs: workflow_run event

[changeset-bot]

⚠️ No Changeset found

Latest commit: 987c5d5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR