Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/release-on-merge.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ jobs:
- uses: pnpm/action-setup@v5
with:
version: 7.6.0
- uses: actions/setup-node@v6
- uses: actions/setup-node@v7

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

GitHub Actions step actions/setup-node@v7 uses a mutable version tag that can be silently repointed by the action owner to malicious code, enabling supply-chain attacks.

More details about this

The GitHub Actions step actions/setup-node@v7 uses a mutable version tag (v7) instead of a pinned commit SHA. This means the action owner can silently update what code runs in your workflow without any change to this file.

Here's a concrete attack scenario:

  1. An attacker compromises the actions/setup-node repository and gains control over the v7 tag
  2. They push malicious code to the repository and repoint the v7 tag to their compromised commit
  3. Your workflow runs and @v7 now resolves to the attacker's commit instead of the legitimate version
  4. The malicious code executes with full access to your repository secrets (GITHUB_TOKEN), allowing the attacker to steal credentials, push code, or modify your releases
  5. This could be used to inject malware into your published packages or exfiltrate sensitive data

This is exactly how the trivy-action and kics-github-action compromises worked—attackers repointed version tags to run their own code.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference actions/setup-node@v7 with a full 40-character commit SHA for the exact actions/setup-node release you want to keep using, for example uses: actions/setup-node@<full-40-character-sha>.
  2. Keep the existing with: settings unchanged so only the action version pin changes.
  3. Confirm the SHA comes from the official actions/setup-node repository release or tag that matches your intended version, and avoid short SHAs or version tags such as @v7. Pinning to a full commit SHA prevents the referenced action code from changing unexpectedly.
💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

Need help? Review go/semgrep-playbook or Reach out in #security-vulnerabilities on Slack.

You can view more details about this finding in the Semgrep AppSec Platform.

with:
node-version: '16'
cache: 'pnpm'
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/test-on-pull-request.yml
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ jobs:
- uses: pnpm/action-setup@v5
with:
version: 7.6.0
- uses: actions/setup-node@v6
- uses: actions/setup-node@v7

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

GitHub Actions step uses mutable tag v7 instead of a pinned commit SHA, allowing the action maintainer to silently update the code executed in your workflows—enabling supply-chain attacks.

More details about this

The GitHub Actions workflow uses actions/setup-node@v7, which references a mutable tag instead of a specific commit. Tag v7 can be repointed at any time by the action maintainer to point to different code without your knowledge.

Here's how an attacker could exploit this:

  1. Compromise the action repository: An attacker gains access to the actions/setup-node repository (e.g., through compromised credentials or social engineering).

  2. Repoint the tag: The attacker moves the v7 tag to commit a malicious version they've created. This tag could now install a backdoored version of Node.js or inject malware into your build environment.

  3. Trigger the workflow: The next time your workflow runs (on any pull request), the step - uses: actions/setup-node@v7 will fetch and execute the attacker's malicious code instead of the legitimate action.

  4. Compromise your environment: The malicious action could steal environment variables (like GITHUB_TOKEN), exfiltrate source code, inject backdoors into your built artifacts, or compromise your CI/CD pipeline entirely.

This attack pattern mirrors real compromises like the trivy-action and kics-github-action incidents, where attackers exploited mutable tag references to distribute malware through the supply chain.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference actions/setup-node@v7 with a full 40-character commit SHA for the exact release you want to trust, for example uses: actions/setup-node@<full-commit-sha>.
  2. Resolve the SHA from the action's release page or repository so the pinned commit matches the current v7 version you intended to use.
  3. Keep the existing with: block unchanged under the pinned action reference, for example node-version: '16' and cache: 'pnpm' do not need to change. Pinning to a commit prevents the action owner from moving a tag or branch to different code later.
  4. If you want to keep the version readable for future updates, add a short comment next to the pinned SHA indicating the human-friendly version, such as # actions/setup-node v7.
💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

Need help? Review go/semgrep-playbook or Reach out in #security-vulnerabilities on Slack.

You can view more details about this finding in the Semgrep AppSec Platform.

with:
node-version: '16'
cache: 'pnpm'
Expand Down
Loading