B6n/console me

[mqarty]

Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

• I acknowledge that all my contributions will be made under the project's license.

[semgrep-code-twilio-labs]

Semgrep identified an issue in your code:

The release workflow trusts the mutable actions/setup-node@v4 tag. A repointed tag could execute attacker-controlled code before dependency installation and tamper with the repository or package release.

More details about this

actions/setup-node@v4 uses the mutable v4 tag rather than an immutable commit. If the actions/setup-node owner—or an attacker who compromises that repository—moves v4 to a malicious commit, the next push to main runs that code in the release job with contents: write permission.

A plausible attack is:

1. An attacker repoints actions/setup-node's v4 tag to a malicious implementation.
2. A maintainer pushes to main, starting this Release workflow.
3. The malicious action runs before npm ci, can alter the checked-out workspace or runner state, and can tamper with package.json, the lockfile, or scripts used by npm ci.
4. Those changes execute during dependency installation or later release commands such as npx changeset version; the job can then commit attacker-controlled changes through the workflow's contents: write permission.
5. The compromised release process can publish altered packages or persist malicious code in the repository. The workflow also validates and later uses NPM_TOKEN, increasing the impact if the injected code runs in a step where that secret is available.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: actions/setup-node@v4
	uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4
	- name: Setup Node
	# Replace with the verified 40-character commit SHA for actions/setup-node v4.
	uses: actions/setup-node@<VERIFIED_VALUE_REQUIRED> # v4

View step-by-step instructions

1. Replace the mutable setup-node tag with the verified 40-character commit SHA for the intended actions/setup-node release: uses: actions/setup-node@<40-character-commit-sha>.
2. Keep a version comment next to the SHA so the selected release remains clear, for example: uses: actions/setup-node@<40-character-commit-sha> # v4.x.x.
3. Pin the actions/checkout@v4 step in the same workflow to its verified 40-character commit SHA as well, since it uses the same mutable-reference pattern.
4. Confirm that every external uses: reference in this workflow either uses a full 40-character commit SHA or is a local action such as ./...; do not use branch names or tags such as @v4.

💬 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.

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

[semgrep-code-twilio-labs]

Semgrep identified an issue in your code:

The release workflow trusts the mutable actions/checkout@v4 tag. If that tag is repointed, attacker-controlled action code runs in a job with repository write access and can alter the release process or repository contents.

More details about this

actions/checkout@v4 is a mutable tag in the Release workflow. The release job runs on pushes to main with contents: write, so the action owner could silently move v4 to a malicious commit without changing this repository.

A plausible attack is:

1. An attacker compromises the actions/checkout release process and repoints v4 to malicious code.
2. The next push to main starts the Version and Publish job, and the malicious checkout code runs before npm ci and the later release steps.
3. Because this job has write access through its GitHub Actions token, the malicious action can read repository contents, alter files in the workspace, or push unauthorized changes back to the repository.
4. It could also modify package or release configuration so that npm ci, npx changeset version, or subsequent publishing steps execute attacker-controlled behavior. The compromise would affect every workflow run until the tag is moved back, with no change to this workflow file.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: actions/checkout@v4
	uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4

View step-by-step instructions

1. Replace the mutable checkout tag with the full 40-character commit SHA for the intended actions/checkout release:
   uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4
2. Pin actions/setup-node@v4 to the full 40-character commit SHA for the approved release as well, keeping a version comment for readability, for example: uses: actions/setup-node@<40-character-commit-sha> # v4.
3. Verify that each SHA comes from the action’s trusted upstream release or tag. Full commit SHAs prevent an action reference from changing silently when a tag or branch is repointed.

💬 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.

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

[semgrep-code-twilio-labs]

Semgrep identified an issue in your code:

The workflow runs actions/checkout from the mutable v4 tag. If that tag is repointed, a pull request can execute attacker-controlled code with this job’s repository access and available credentials.

More details about this

actions/checkout@v4 uses the mutable v4 tag rather than an immutable commit SHA. GitHub resolves that tag when this workflow starts, so the action owner—or an attacker who compromises the action repository—could repoint v4 to a malicious commit. On a pull request targeting main, the changeset-required job would then execute the attacker-controlled checkout code before Validate changeset presence runs; that code could read workflow tokens, repository contents, or secrets available to the job and exfiltrate them.

A plausible attack is:

1. An attacker gains control of the actions/checkout repository or its release tag and changes v4 to a malicious commit.
2. A pull request triggers changeset-required on ubuntu-latest.
3. The uses: actions/checkout@v4 step downloads and runs the malicious action.
4. The action abuses the job's permissions or tokens to send repository data or credentials to an attacker-controlled server, even though the shell commands in Validate changeset presence appear harmless.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: actions/checkout@v4
	uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0

View step-by-step instructions

1. Replace the mutable v4 reference with the full 40-character commit SHA for the reviewed actions/checkout release:
   uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
2. Keep the existing with configuration unchanged. Pinning the action to a commit prevents the action owner from silently changing the code selected by the workflow.

💬 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.

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