Bypassing GitHub Actions policies in the dumbest way possible

Nature and Severity of the “Bypass”

• Many argue this is not a traditional vulnerability: if a developer can edit workflows, they already have arbitrary code execution and can curl | sh, clone arbitrary repos, or run custom scripts.
• Others stress the real issue is policy/audit, not direct exploitation: org-wide “allowed actions” lists are meant to control supply-chain risk and provide inventory/compliance, and this local-clone trick defeats that while making dashboards look clean.
• Several note this creates a false sense of security: ineffective controls that appear enforced are worse than having no control at all.

Policies, Compliance, and Threat Models

• For large organizations, the goal of actions policies is to:
  • Centrally approve third‑party actions.
  • Track where they are used.
  • Avoid mutable marketplace tags and silent dependency drift.
• The bypass means:
  • Central IT/security can’t see that a disallowed action is effectively in use.
  • Compliance frameworks that require restricting third‑party code may be violated without detection.
• Some suggest GitHub should either expand enforcement (e.g., cover local uses: paths or forbid run: entirely) or clearly document limitations.

“Unusable Security” and Developer Workarounds

• Several comments frame this as classic “unusable security”: if controls are too restrictive or misaligned with real work, users will route around them.
• Developers report cloning third‑party actions into internal repos as a routine workaround when orgs ban marketplace actions without offering review/whitelisting capacity.
• One camp sees this as necessary pragmatism; another sees it as insubordination that policies should at least surface, if not technically prevent.

Broader Software Control / AppLocker Debate

• Long subthread on whether companies should tightly control what software employees can run (AppLocker, application whitelisting).
• Pro-control arguments: reduces malware/ransomware, mitigates licensing and IP risk (e.g., Oracle Java, VirtualBox, Docker Desktop), and is critical for regulated or sensitive environments.
• Anti-control arguments: extreme allowlisting can cripple developer productivity and leads to absurd workflows; the real answer is balanced policy, role‑dependent controls, and defense in depth (network egress controls, hermetic CI, logging/auditing).

Practical Mitigations and Best Practices

• Suggested practices:
  • Fork or submodule external actions into the org and review/pin by commit SHA.
  • Recognize container actions can still change via mutable image tags.
  • Restrict CI outbound network access and isolate sensitive secrets.
  • Keep CI configs in separate, more-protected repos.
• Several conclude that action policies are only one weak layer; strong security must come from infrastructure and process, not checkbox toggles.