top | item 44248733

(no title)

clysm | 8 months ago

I’m not seeing the security issue here. Arbitrary code execution leads to arbitrary code execution?

Seems like policies are impossible to enforce in general on what can be executed, so the only recourse is to limit secret access.

Is there a demonstration of this being able to access/steal secrets of some sort?

discuss

order

mystifyingpoi|8 months ago

> Seems like policies are impossible to enforce

The author relates to exactly that: "ineffective policy mechanisms are worse than missing policy mechanisms, because they provide all of the feeling of security through compliance while actually incentivizing malicious forms of compliance."

And I totally agree. It is so abundant. "Yes, we are in compliance with all the strong password requirements, strictly speaking there is one strong password for every single admin user for all services we use, but that's not in the checklist, right?"

dijksterhuis|8 months ago

It's less of an "use this to do nasty shit to a bunch of unsuspecting victims" one, and more of a "people can get around your policies when you actually need policies that limit your users".

1. BigEnterpriseOrg central IT dept click the tick boxes to disable outside actions because <INSERT SECURITY FRAMEWORK> compliance requires not using external actions [0]

2. BigBrainedDeveloper wants to use ExternalAction, so uses the method documented in the post because they have a big brain

3. BigEnterpriseOrg is no longer compliant with <INSERT SECURITY FRAMEWORK> and, more importantly, the central IT dept have zero idea this is happening without continuously inspecting all the CI workflows for every team they support and signing off on all code changes [1]

That's why someone else's point of "you're supposed to fork the action into your organisation" is a solution if disabling local `uses:` is added as an option in the tick boxes -- the central IT dept have visibility over what's being used and by whom if BigBrainedDeveloper can ask for ExternalAction to be forked into BigEnterpriseOrg GH organisation. Central IT dept's involvement is now just review the codebase, fork it, maintain updates.

NOTE: This is not a panacea against all things that go against <INSERT SECURITY FRAMEWORK> compliance (downloading external binaries etc). But it would be an easy gap getting closed.

----

[0]: or something, i dunno, plenty of reasons enterprise IT depts do stuff that frustrates internal developers

[1]: A sure-fire way to piss off every single one of your internal developers.