4 ms·

I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed

I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.

woodruffw 1y ago
A mitigation for this exact policy mechanism is included in the post. (The point is not directly malicious introductions: it's supply chain risk in the form of engineers introducing actions/reusable workflows that are themselves malleable/mutable/subject to risk. A policy that claims to do that should in fact do it, or explicitly document its limitations.)
x0x0 1y ago
The risk is the same reason we don't allow any of our servers to make outgoing network connections except to a limited host lists. eg backend servers can talk to the gateway, queue / databases, and an approved list of domains for apis and nothing else. The same guard helps prevent accidents, not maliciousness, and security breaches. If code somehow gets onto our systems, but we prevent most outbound connections, exfiltrating is much harder. Yes, people do code review but stuff slips through. See eg Google switching one of their core libs that did mkdir with a shell to run mkdir -p (tada! every invocation better understand shell escaping rules). That made it through code review. People are imperfect; telling your network no outbound connections (except for this small list) is much closer to perfect.
hk1337 1y ago
I haven't tested this but the main risk that is possible is users creating PRs on public repositories with actions that run on pull request.
- 1oooqooq 1y ago
  if your unprotect pr job can have side effects besides accessing the public repo and returning a boolean for passing status, what hope is there?
  - throwaway290 1y ago
    any job can have side effects so there is no hope indeed
SamuelAdams 1y ago
The risk is simple enough. GitHub Enterprise allows admins to configure a list of actions to allow or deny. Ideally these actions are published in the GitHub Marketplace. The idea is that the organization does not trust these third-parties, therefore they disable their access. However this solution bypasses those lists by cloning open-source actions directly into the runner. At that point it’s just running code, no different from if the maintainers wrote a complex action themselves.
SchemaLoad 1y ago
Companies that care about this kind of thing usually have the CI config on another repo from the actual code so you can't just rewrite it to deploy your dev branch straight to prod.
paulddraper 1y ago
Well…you’re right. The dumb thing is GitHub offers “action policies” pretending they actually do something.

woodruffw 1y ago

A mitigation for this exact policy mechanism is included in the post. (The point is not directly malicious introductions: it's supply chain risk in the form of engineers introducing actions/reusable workflows that are themselves malleable/mutable/subject to risk. A policy that claims to do that should in fact do it, or explicitly document its limitations.)

x0x0 1y ago

The risk is the same reason we don't allow any of our servers to make outgoing network connections except to a limited host lists. eg backend servers can talk to the gateway, queue / databases, and an approved list of domains for apis and nothing else. The same guard helps prevent accidents, not maliciousness, and security breaches. If code somehow gets onto our systems, but we prevent most outbound connections, exfiltrating is much harder. Yes, people do code review but stuff slips through. See eg Google switching one of their core libs that did mkdir with a shell to run mkdir -p (tada! every invocation better understand shell escaping rules). That made it through code review. People are imperfect; telling your network no outbound connections (except for this small list) is much closer to perfect.

hk1337 1y ago

I haven't tested this but the main risk that is possible is users creating PRs on public repositories with actions that run on pull request.

1oooqooq 1y ago
if your unprotect pr job can have side effects besides accessing the public repo and returning a boolean for passing status, what hope is there?
- throwaway290 1y ago
  any job can have side effects so there is no hope indeed

SamuelAdams 1y ago

The risk is simple enough. GitHub Enterprise allows admins to configure a list of actions to allow or deny. Ideally these actions are published in the GitHub Marketplace. The idea is that the organization does not trust these third-parties, therefore they disable their access. However this solution bypasses those lists by cloning open-source actions directly into the runner. At that point it’s just running code, no different from if the maintainers wrote a complex action themselves.

SchemaLoad 1y ago

Companies that care about this kind of thing usually have the CI config on another repo from the actual code so you can't just rewrite it to deploy your dev branch straight to prod.

paulddraper 1y ago

Well…you’re right. The dumb thing is GitHub offers “action policies” pretending they actually do something.