Bypassing GitHub Actions policies in the dumbest way possible

The Severity of GitHub Actions Policy Bypasses

The discussion revolves around a recent finding of GitHub Actions policy bypasses. Some users downplay the issue, arguing that determined attackers can always find a way to execute arbitrary code. Others highlight the risk amplification due to the nature of Actions as part of the CI/CD pipeline and the potential for silent updates of Actions.

• Defense of the Status Quo: One viewpoint is that the bypass isn't critical because other vulnerabilities exist. "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 could be exfiltrated, secrets stolen, and more" - hiatus. This argument suggests that organizations should focus on fundamental security practices like code review. "But there is no policy preventing external downloads in general, is there? I can curl a random script from a malicious website, too." - hiatus makes a similar point about the already-present ability to download and execute arbitrary code.
• Risk Amplification Through CI/CD: Another perspective emphasizes the increased risks related to the CI/CD pipelines and Actions' marketplace. "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." - woodruffw notes the practical limitations of extensive code review in large organizations, highlighting the value of policies in mitigating risks, especially for junior engineers. "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." - woodruffw, further illustrating the potential risk factors unique to GitHub Actions due to automated updates and marketplace.
• The Problem Isn't The Vulnerability But the Usability A few comments consider whether the security policy is usable. If not, users will circumvent it. "This is a prime example of 'If you make an unusable secure system, the users will turn it into an insecure usable one.'" - kj4ips

Application Whitelisting and AppLocker: A Double-Edged Sword

Much of the discussion drifted into the topic of application whitelisting, specifically focusing on AppLocker. The general sentiment is that while application whitelisting is a powerful security measure, it can be cumbersome and difficult to implement effectively in practice.

• The Value of Application Whitelisting: There is agreement that whitelisting is effective when implemented well. "Security practitioners are big fans of application whitelisting for a reason: Your malware problems pretty much go away if malware cannot execute in the first place". - bigfatkitten advocates for AppLocker. "AppLocker is effectively an almost perfect solution to ransomware. (On the employee desktops anyway)" - viraptor states. "The Australian Signals Directorate for example has recommended (and more recently, mandated) application whitelisting on government systems for the past 15 years or so, because it would’ve prevented the majority of intrusions they’ve investigated." - bigfatkitten argues for the widespread adoption of whitelisting policies.
• The Challenge of Implementation: Several users point out the difficulties and potential for overreach in implementing such restrictive measures. "Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of effort just to understand what 'acceptable software' is across your entire org." - kj4ips notes the practical challenges of understanding what constitutes acceptable software across a large organization. "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." - welshwelsh highlights the view that restricting software usage is overly controlling.
• Finding a Balance: Some suggest that restrictions of software usage need to be balanced with employee empowerment. "I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this." - neilv. The complexity and nuance is acknowledged with concerns being expressed about privacy, security, and liability.

Scenarios and Considerations for Software Restrictions.

The discussion pivots to scenarios like developer responsibility, specific environments, and consequences of non-compliance.

• Developer Responsibility vs. Security Measures: There is debate over whether restrictions impede developers in their work. "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." - lelandbatey raises concerns about how strict whitelisting policies could hinder software development. While xmprt argues that a developer running malicious code is responsible, lelandbatey clarifies they are pointing out that a restrictive system would prevent building new software.
• Restricted Environments: There is the assertion that restricting the environments developers work in is a viable solution "Developers are generally given specific environments to run code, which aren’t their laptops — eg, VMs in a development environment." - zmgsabst
• Licensing and Compliance Risks as Justification: Reasons for restricting software usage also include avoiding licensing violations or illegal behavior by the software. "if someone installs the wrong version of Oracle Java on a VM in our farm, the licencing cost is seven figures as they want to charge per core that it could conceivably run on - this would be career-limiting for a number of people at once." - janstice. Similarly, nradov argues that for certain roles (e.g., nurses reviewing medical charts), restricting software usage is justified to reduce the attack surface and prevent HIPAA violations.