-3-2.webp)
Surprise! Your GitHub Actions Are Dependencies, Too
GitHub Actions are open source dependencies - secure them accordingly! Learn how to effectively manage the security risks associated with GitHub Actions with a proactive approach focusing on three key areas: visibility, hardening, and dependency management.
GitHub Actions are open source dependencies - secure them accordingly! Learn how to effectively manage the security risks associated with GitHub Actions with a proactive approach focusing on three key areas: visibility, hardening, and dependency management.
GitHub Actions are open source dependencies - secure them accordingly! Learn how to effectively manage the security risks associated with GitHub Actions with a proactive approach focusing on three key areas: visibility, hardening, and dependency management.
GitHub Actions are open source dependencies - secure them accordingly! Learn how to effectively manage the security risks associated with GitHub Actions with a proactive approach focusing on three key areas: visibility, hardening, and dependency management.
GitHub Actions are open source dependencies - secure them accordingly! Learn how to effectively manage the security risks associated with GitHub Actions with a proactive approach focusing on three key areas: visibility, hardening, and dependency management.
GitHub Actions is one of the most popular CI/CD platforms, in part because of how easy it is to adopt if you’re already managing your source code repositories using GitHub. Among other features, the GitHub Actions platform has a system that makes it easy to use various pre-built Actions (steps that are used in a GitHub Actions Workflow) built by others — for example, if you have a build workflow that needs to install a Java JDK, instead of writing shell scripts you can use GitHub’s action/setup-java pre-built step.
Pre-built Actions are a huge accelerator for DevOps, as they allow you to gain all the benefits of code reuse for your CI/CD pipelines — they’re essentially special-purpose applications designed for the GitHub Actions CI/CD platform. Many of these Actions are open source projects, and so the Actions ecosystem has all of the advantages — and challenges — of open source dependency management.
GitHub Actions are Dependencies
Did I say “dependency management”?! I did! We might be used to thinking of “dependencies” as the libraries that become part of our applications, but the tools we use to build and test our applications are dependencies (and part of our supply chain) too. And since Actions are a sort of application component (often written in TypeScript or JavaScript, but can also be deployed as Docker images containing any code the authors want), they even have their own open source library dependencies. And just like any kind of dependency we have, we need visibility and a system for identifying and prioritizing risks.
Think of it a bit like an application is a car. The cars you build have parts that come from many different suppliers, and it’s pretty obvious that those are dependencies in the supply chain. But assembling the car also requires an assembly line, and that line has many tools and machines that, like the car they’re helping build, have their own parts lists and supply chains. A robot that stops working or goes haywire is a problem for you, just like a bad batch of seat springs might be. Your CI/CD pipelines are assembly lines for software, and the quality and security of the software you build depends as much on the quality and safety of the tools in that pipeline — including pre-built Actions — as it does on the quality of the “parts” (the open-source libraries your developers incorporate) that you use.
The analogy isn’t perfect, of course, but the reality is that using compromised or vulnerable Actions does pose some risk to you — from things as minor as causing breaking builds to things as serious as an adversary using a compromised Action to insert malicious code in the application you just built (and will now be deploying to production or distributing to your customers). Ensuring that you use Actions safely is an important part of defending your supply chain, and also of ensuring that you’re a safe part of the supply chain for your customers.
(GitHub) Actions Have Consequences: There Are Special Risks For Actions and Workflows
Because a pre-built Action is just an application — typically a JavaScript application or a Docker container image — it can have application risk. Any JavaScript application could have risks itself, or could be using open source components with vulnerabilities and other similar dependency risks. And of course, the same applies to applications in Docker containers. Pre-built GitHub Actions are no exception to this.
But Actions are special-purpose applications that run in the context of a GitHub Actions Workflow. So when you assess risk from Actions, your approach has to consider both the built-in defenses used by, and the special risks posed by, that unique context. And these aren’t just theoretical risks. We’ve seen adversaries exploit a vendor’s pre-built pipeline script to compromise secrets in their customer’s CI environments, and compromised NPM packages that deploy malware end up in JavaScript-flavored Actions.
While GitHub does several things to try to mitigate these risks, organizations have to take their own steps to make sure that the Actions they consume are trustworthy and safe for their uses.
Addressing Security And Safety Risks in GitHub Actions
To effectively manage the security risks associated with GitHub Actions, security organizations must adopt a proactive approach focusing on three key areas:
- Get visibility into adopted Actions and their dependencies
- Harden your Workflow configurations and runner environments
- Bring your dependency management program to GitHub Actions and other reusable components
Get visibility into adopted GitHub Actions and their dependencies
Without comprehensive visibility into the GitHub Actions we adopt and their dependencies, making informed risk decisions becomes challenging. It's imperative to understand the composition of our Actions and their underlying dependencies. This includes identifying known vulnerabilities and other potential risks, similar to any application assessment.
Harden your GitHub Workflow configurations and runner environments
Implementing measures such as least privilege, endpoint controls, and other environmental considerations can mitigate the risks posed by GitHub Actions. While pipelines differ from production environments -- after all, they typically don’t need to be accessible to a wide audience -- applying stringent controls can help ensure that vulnerabilities are harder to exploit and have a smaller “splash area” than they might in a production environment.
Bring your dependency management program to GitHub Actions and other reusable components
Managing dependencies within GitHub Actions requires careful consideration. You have to strike a balance between controlling change (such as by pinning each action you use to a specific SHA reference, so that it’s nearly impossible for a different version to be used without going through your change controls) and ensuring that you are able to update in a timely manner (such as by pinning actions to a high-level version tag like `@v1`).
Where you land on this will depend a great deal on how your organization values responsiveness and developer (or DevOps) productivity vs. control. One solution I like is to maintain forks of actions and have a process for analyzing them and updating them on a schedule. Then engineers can use a more-permissive pinning strategy and avoid doing updating work, while DevOps or DevSecOps teams can transparently manage upgrading/patching.
Dependency management starts earlier in the SDLC, though. Conducting thorough research before adopting actions, such as by assessing that project’s health and controls, and evaluating the trustworthiness of the maintainers of the actions you adopt, is essential. Establishing strategies for routine upgrades (such as the fork strategy discussed above) and responding to disclosed vulnerabilities further enhances your security posture.
Endor Labs Can Help
Endor Labs, a leading CI/CD product, offers robust solutions to address GitHub Actions' security challenges and more. Try it for free in our 30-day trial or contact us to discuss your use cases.
GitHub Actions Risk Analysis
Endor Labs introduces a groundbreaking Actions risk analysis feature, empowering organizations to enumerate actions and their dependencies effectively. By surfacing known vulnerabilities, excessive permissions, and configuration issues, Endor Labs enables informed actions choices, supported by EndorScore, dependency trees, and risk enumeration. Together, these capabilities allow you to reduce the time to research actions before adopting them, prompt surface important risks that require updates or mitigation actions, and ensure that you have confidence in your whole chain of dependency when you do adopt an action.
GitHub RSPM Integration
Endor Labs RSPM (Repository Security Posture Management) features analyze your GitHub configuration posture to ensure it continues to align with your organization policies and practices, including controls like requiring signed commits and ensuring CODEOWNERS enforcement. These types of controls provide an important defense against malicious changes to your workflow definitions and Actions configurations.
Tool Discovery
Endor Labs provides valuable visibility into the tools and products used within your GitHub Actions, enabling organizations to track and manage their CI/CD toolchain effectively. This visibility and our policy engine combine to enable you to enforce rules like “you must run one of these three approved SAST tools” or “you can’t use a tool not on this list of approved tools”.
Artifact Signing and Traceability
Endor Labs provides a no-new-infrastructure approach to signing artifacts in a way that enables you to trace containers and application binaries and other artifacts back to the workflow configuration that generated them. This allows you to both verify that an artifact is authentic (that is, it was produced by an approved workflow), and efficiently investigate suspected supply chain compromises.