Motivation
- Scorecard has two checks for GitHub workflow misconfigurations: 1) uses of
pull_request_target coupled with untrusted checkouts, and 2) script injections in workflow definitions
- When using the
on: pull_request_target trigger, an attacker who opens a pull request can control the branch the workflow executes from as well as the workflow logic. pull_request_target is considered untrusted when coupled with an untrusted checkout.
pull_request_target triggers also apply on pull requests on workflows on non-default git branches
Some factors mitigate an exploit of Dangerous-Workflows, but not comprehensively. First, read-only workflow permissions leave open the possibility of environment variable token exfiltration. Second, workflows may be restricted to “Require approval for all outside collaborators,” but this doesn't prevent running a workflow with pull_request_target.
Today, Scorecard (and Allstar) don’t scan GitHub workflows in non-default branches, even though those could be exploited by pull_request_target.
Proposal
Allstar should scan all branches with the Scorecard Dangerous-workflow check. To avoid Scorecard downloading a repo multiple times, Allstar should clone the repo and run scorecard --local on local branch checkouts.
This change should slightly more than double Allstar’s required storage (over a single Scorecard tarball download) and add extra time for a full clone. It would add a dependency on go-git. GitHub git operation quota is unlimited, so no impact is expected on Allstar token quota.
Alternatives Considered
Adding new probes
Since the hasDangerousWorkflow* probes are stable, Scorecard could add two new, non-probes:
- hasDangerousWorkflowUntrustedCheckoutAnyBranch
- hasDangerousWorkflowScriptInjectionAnyBranch
When running the Dangerous-Workflow check, Scorecard middleware should fetch the .github workflow directories of every branch in a repository and expose workflow files to Dangerous-Workflow raw data collection. This approach would make this data available in the cron. However, since Scorecard is structurally ref-centric, adding hidden behavior to scan non-default branches would be counter to user expectations.
Motivation
pull_request_targetcoupled with untrusted checkouts, and 2) script injections in workflow definitionson: pull_request_targettrigger, an attacker who opens a pull request can control the branch the workflow executes from as well as the workflow logic.pull_request_targetis considered untrusted when coupled with an untrusted checkout.pull_request_targettriggers also apply on pull requests on workflows on non-default git branchesSome factors mitigate an exploit of Dangerous-Workflows, but not comprehensively. First, read-only workflow permissions leave open the possibility of environment variable token exfiltration. Second, workflows may be restricted to “Require approval for all outside collaborators,” but this doesn't prevent running a workflow with
pull_request_target.Today, Scorecard (and Allstar) don’t scan GitHub workflows in non-default branches, even though those could be exploited by
pull_request_target.Proposal
Allstar should scan all branches with the Scorecard Dangerous-workflow check. To avoid Scorecard downloading a repo multiple times, Allstar should clone the repo and run
scorecard --localon local branch checkouts.This change should slightly more than double Allstar’s required storage (over a single Scorecard tarball download) and add extra time for a full clone. It would add a dependency on
go-git. GitHub git operation quota is unlimited, so no impact is expected on Allstar token quota.Alternatives Considered
Adding new probes
Since the hasDangerousWorkflow* probes are stable, Scorecard could add two new, non-probes:
When running the Dangerous-Workflow check, Scorecard middleware should fetch the .github workflow directories of every branch in a repository and expose workflow files to Dangerous-Workflow raw data collection. This approach would make this data available in the cron. However, since Scorecard is structurally ref-centric, adding hidden behavior to scan non-default branches would be counter to user expectations.