[raj-dubey1]

What

Pin every GitHub Actions uses: reference in the workflows to a full 40-character commit SHA, with a trailing # vX.Y.Z comment preserving the human-readable version. No behavior change — each SHA is the exact commit the floating major tag currently resolves to.

18 references across 3 workflow files:

Action	Was	Now (pinned)
actions/checkout	@v5	@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 # v5.1.0
actions/setup-node	@v5	@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
actions/upload-artifact	@v7	@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
docker/setup-buildx-action	@v4	@f87e5991a6d7451dcb8d9637bfbc97413f497069 # v4.4.1
actions/github-script	@v9	@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0

• .github/workflows/ci.yml — 14 refs
• .github/workflows/publish-mcp.yml — 1 ref
• .github/workflows/search-eval-drift.yml — 3 refs

Why

A floating tag like @v5 is mutable: whoever controls the action's repo can move it to point at different code, which then runs in our CI with our GITHUB_TOKEN. Pinning to an immutable commit SHA removes that supply-chain risk — the workflow runs exactly the reviewed code until we deliberately bump the SHA. This is the GitHub-recommended hardening for third-party actions.

It also clears the one finding class that is currently keeping this repo's centralized scan below the listing threshold on hashgraph-online/awesome-ai-plugins (the awesome-ai-plugins directory we're being listed in). That scan scored 79 (threshold 80); GITHUB_ACTION_UNPINNED was the dominant finding, so pinning these should take it over the line.

Note: false positives to disregard (no code change)

The same scan flags 2× DANGEROUS_DYNAMIC_EXECUTION (high) in src/lib/frontmatter.ts. These are false positives: that file is a hardening wrapper whose entire purpose is to prevent dynamic execution — it detects gray-matter's language tag and refuses anything that isn't YAML/JSON, and replaces gray-matter's executable engines (javascript/js/coffee/cson/toml, whose built-in javascript engine is a literal eval()) with ones that throw. The scanner is tripping on the engine names and the word eval in the explanatory comments, not on any actual dynamic execution. No change is warranted here; flagging for reviewer awareness. (The scan's remaining items are advisory low/info: a missing .github/dependabot.yml, a missing .codexignore, and optional .codex-plugin/plugin.json metadata fields — intentionally left out of this PR to keep it to the supply-chain fix.)

How the SHAs were resolved

Each floating major tag was dereferenced to the commit it currently points to via the GitHub API (repos/<owner>/<repo>/commits/<tag>), and the # vX.Y.Z comment is the exact semver tag at that commit. No SHAs were guessed.

🤖 Generated with Claude Code

https://claude.ai/code/session_0127KpBfkiKKcFaYsrXLfUd2

[raj-dubey1]

Closing in favor of cometchat-team/docs-mcp#57, which makes the same SHA pins in the private source repo.

Reason: ci.yml, publish-mcp.yml and search-eval-drift.yml are mirrored here from the private repo by sync-to-public.yml (rsync -a --delete on every push to private main). Pinning them in this public mirror is overwritten on the next sync, which restores the private floating-tag versions — so the hardening wouldn't stick. Pinning in private flows here through the mirror and stays. The private PR is also rebased onto current main, so it doesn't revert the later search-eval-drift.yml changes this PR predated.