Potential fix for code scanning alert no. 4: Checkout of untrusted code in trusted context#268
Draft
Potential fix for code scanning alert no. 4: Checkout of untrusted code in trusted context#268
Conversation
…de in trusted context Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Potential fix for https://github.com/smartcontractkit/cre-cli/security/code-scanning/4
In general, the problem is that the workflow uses PR-controlled branch names (
github.head_ref || github.ref_name) to decide which ref ofsmartcontractkit/chainlinkto check out in a (potentially) privileged job. To fix this without changing existing functionality too much, we should ensure that the ref used for thesmartcontractkit/chainlinkcheckout cannot be directly influenced by arbitrary PRs. The simplest, least invasive mitigation is to stop using the PR branch name when checking outsmartcontractkit/chainlink, and instead always use a fixed, trusted branch (likedevelop) or a known-good ref. This removes the data-flow from untrusted PR metadata to the checkout ref entirely and keeps the rest of the workflow intact.Concretely, within
.github/workflows/pull-request-main.yml:github.head_ref || github.ref_namewhen computingtarget_branch. We can simplify theCheck if current branch exists in chainlink repostep so that it always setstarget_branch=develop(or another trusted branch), and optionally keep thegh apicheck only for informational logging if desired.Checkout chainlink repositorystep in place, but itsrefshould now always be set to that fixed, trusted branch viasteps.check-branch.outputs.target_branch. Functionally, this means system tests will always run againstdevelopofsmartcontractkit/chainlink, independent of the PR branch; this is typically acceptable and aligns with the intent of testing against the latest standard environment.runscript in the existingcheck-branchstep.This change keeps the job structure and subsequent steps (Go setup, binary copy, AWS/ECR interaction, running tests) the same, but removes any possibility that untrusted PR input can influence the ref of the checked-out
smartcontractkit/chainlinkrepository in this privileged workflow.Suggested fixes powered by Copilot Autofix. Review carefully before merging.