Skip to content

Potential fix for code scanning alert no. 4: Checkout of untrusted code in trusted context#268

Draft
infiloop2 wants to merge 1 commit intomainfrom
alert-autofix-4
Draft

Potential fix for code scanning alert no. 4: Checkout of untrusted code in trusted context#268
infiloop2 wants to merge 1 commit intomainfrom
alert-autofix-4

Conversation

@infiloop2
Copy link
Collaborator

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 of smartcontractkit/chainlink to check out in a (potentially) privileged job. To fix this without changing existing functionality too much, we should ensure that the ref used for the smartcontractkit/chainlink checkout cannot be directly influenced by arbitrary PRs. The simplest, least invasive mitigation is to stop using the PR branch name when checking out smartcontractkit/chainlink, and instead always use a fixed, trusted branch (like develop) 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:

  1. Remove or neutralize the use of github.head_ref || github.ref_name when computing target_branch. We can simplify the Check if current branch exists in chainlink repo step so that it always sets target_branch=develop (or another trusted branch), and optionally keep the gh api check only for informational logging if desired.
  2. Leave the Checkout chainlink repository step in place, but its ref should now always be set to that fixed, trusted branch via steps.check-branch.outputs.target_branch. Functionally, this means system tests will always run against develop of smartcontractkit/chainlink, independent of the PR branch; this is typically acceptable and aligns with the intent of testing against the latest standard environment.
  3. No new actions or external libraries are required; we only simplify the run script in the existing check-branch step.

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/chainlink repository in this privileged workflow.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

…de in trusted context

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant