Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing GitHub Actions policies in the dumbest way possible

blog.yossarian.net

Post reply on HN
Print view View original

81–90 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#81

Post by wereHamster »

opello wrote: post #63
OptionOfT wrote: post #54

We forked the actions as a submodule, and then pointed the uses to that directory. That way we were still tracking the individual commits which we approved as a team. Now there is interesting dichotomy. On one hand PMs want us to leverage GitHub Actions to build out stuff more quickly using pre-built blocks, but on the other hand security has no capacity or interest to whitelist actions (not to mention that the white…

Maybe there's a future Dependabot feature to create FYI issues when in use tags change?

securityscorecard is easy to integrate (it's a cli tool or you run it as a github action), one of the checks it performs is "Pinned-Dependencies": https://github.com/ossf/scorecard/blob/main/docs/checks.md#p.... Checks that fail generate an security alert under Security -> Code scanning.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#82

Post by lelandbatey »

xmprt wrote: post #76
lelandbatey wrote: post #74

Earlier quoted context omitted.

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

This is a strawman argument. If a developer writes code that does something malicious then it's on the developer. If they install a program then the accountability is a bit fuzzier. It's partly on the developer, partly on security (for allowing an unprivileged user to do malicious/dangerous things even unknowingly), and partly on IT (for allowing the unauthorized program to run without any verification).

It's not a straw man, I'm not trying to defuse liability. Of course a developer running malicious code they wrote is responsible for the outcomes.

I am pointing out that if every unique binary never before run/approved is blocked, then no developer will be able to build and then run the software they are paid to write, since them developing it modifies said software into a new and never before seen sequence of bits.

OP may not have meant to say that "it's good to have an absolute allowlist of executable signatures and block everything else", but that is how I interpreted the initial claim and I am merely pointing out that such a system would be more than inconvenient, it'd make the workflow of editing and then running software nearly impossible.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#83

Post by degamad »

lelandbatey wrote: post #74
neilv wrote: post #72

Earlier quoted context omitted.

> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement. I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this. One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent s…

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

If I have an internal developer in such a scenario, then what makes most sense to me is to issue them a code-signing certificate or equivalent, and whitelisting anything signed by that certificate[1], combined with logging and periodic auditing to detect abuse.

[1] https://learn.microsoft.com/en-us/windows/security/applicati...>

Re: Bypassing GitHub Actions policies in the dumbest way possible

#84

Post by bob1029 »

sureglymop wrote: post #77
bob1029 wrote: post #27

I feel like GitHub's CI/CD offering is too "all-in" now. Once we are at a point where the SCM tool is a superset of AWS circa 2010, we probably need to step back and consider alternatives. A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks. I would much rather write CI/CD to…

I don't understand GitHubs popularity in the first place... You have git as the interoperable version control "protocol" but then slap proprietary issue, PR, CI and project management features on top that one couldn't bring with when migrating away? At that stage what is even the point of it being built on git? Also, for all that is great about git, I don't think it's the best version control system we could have at…

What do you think a more ideal VCS would look like?

Re: Bypassing GitHub Actions policies in the dumbest way possible

#85

Post by viraptor »

welshwelsh wrote: post #70
kj4ips wrote: post #6

This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…

Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

AppLocker is effectively an almost perfect solution to ransomware. (On the employee desktops anyway) You can plug lots of random holes all day long or just whitelist what can be run in the first place. Ask M&S management today if they prefer to keep working with paper systems for the another month, or would they prefer to deal with AppLocker.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#87

Post by viraptor »

lelandbatey wrote: post #74
neilv wrote: post #72

Earlier quoted context omitted.

> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement. I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this. One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent s…

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

> Does every program written by every dev have to be cleared?

No, that's not how things are implemented normally, exactly because they wouldn't work.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#88

Post by gabeio »

viraptor wrote: post #87
lelandbatey wrote: post #74

Earlier quoted context omitted.

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

> Does every program written by every dev have to be cleared? No, that's not how things are implemented normally, exactly because they wouldn't work.

> No, that's not how things are implemented normally, exactly because they wouldn't work.

I used to work for a gov't contractor. I wrote a ~10 line golang http server, just because at the time golang was still new (this was years ago) and I wanted to try it. Not even 2 minutes later I got a call from the IT team asking a bunch of questions about why I was running that program (the http server not golang). I agree the practice is dumb but there are definitely companies who have it setup that way.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#89

Post by SchemaLoad »

TheTaytay wrote: post #26

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.

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.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#90

Post by protocolture »

welshwelsh wrote: post #70
kj4ips wrote: post #6

This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…

Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

>Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

Yet so many receptionists think that the application attached to the email sent by couriercompany@hotmail.com is a reasonable piece of software to run. Curious.

Post reply on HN