Posts Tagged ‘GitHubActions’
[DevoxxFR2026] GitHub Actions as a Supply Chain Security Time Bomb: Real-World Attacks and Defensive Strategies
Lecturer
Thierry Abalea is the co-founder and CEO of Shipfox, a French AI Factory platform specializing in coding agent workflows. With a background in software development and security, he focuses on practical approaches to securing modern CI/CD pipelines in cloud-native environments.
Abstract
GitHub Actions has become a cornerstone of modern CI/CD practices, yet it remains insecure by default. Recent supply chain attacks such as those targeting tj-actions, s1ngularity, GhostAction, and Shai-Hulud have demonstrated how adversaries systematically exploit workflows to exfiltrate secrets and compromise downstream projects. This presentation dissects concrete attack vectors observed in 2025, explains why traditional mitigations fall short, and outlines actionable defenses including scoped secrets with approval workflows, minimal GITHUB_TOKEN permissions, egress controls, runner hardening, and runtime protection tools. Attendees gain a clear understanding of the current threat landscape and practical steps to secure their pipelines.
The Critical Role and Inherent Risks of CI/CD in Modern Development
Continuous integration and continuous deployment pipelines manage extraordinarily sensitive assets: source code manipulation, secret handling for production access, and package publishing. Any compromise here can lead to widespread downstream damage. Thierry Abalea emphasizes that while GitHub Actions provides powerful automation, its permissive default configuration creates a vast attack surface. Workflows often run with broad permissions, handle long-lived secrets, and interact with external networks without sufficient restrictions.
The 2025 attack wave—including Singularity targeting Nx builds, Shai-Hulud as the first npm-propagating worm, and multiple incidents against Trivy—highlighted how GitHub Actions serves as both an entry point for initial compromise and a vector for secret exfiltration and lateral movement. These incidents affected hundreds of organizations, underscoring that CI/CD security can no longer be treated as secondary to application security.
Dissecting Major Supply Chain Attacks via GitHub Actions
Several high-profile incidents illustrate common exploitation patterns. The Singularity attack combined batch injection vulnerabilities in pull request workflows with the pull_request_target trigger. This allowed attackers to exfiltrate secrets from forked repositories, including NPM tokens used to publish malicious packages. Downstream consumers of the compromised Nx tool were subsequently affected.
Shai-Hulud represented a novel worm-like propagation through npm. Attackers gained secrets via similar workflow vulnerabilities, published malicious packages, and leveraged maintainer permissions across multiple projects. This created cascading compromises as infected packages spread through dependency trees.
Trivy, a widely used open-source security scanner, suffered repeated attacks. Initial exploitation via pull_request_target and unsafe interpolation led to remote code execution, secret exfiltration (including high-privilege GITHUB_TOKENs), repository privatization, and deletion of releases. A follow-up attack succeeded due to incomplete secret rotation, enabling further malicious package publications.
These cases reveal recurring themes: overly permissive triggers, secret exposure in workflows, and insufficient isolation between CI environments and production assets.
Why Default GitHub Actions Security Falls Short
GitHub Actions operates with broad defaults that favor convenience over security. Workflows can trigger on untrusted events like pull_request_target, granting access to repository secrets. The GITHUB_TOKEN often possesses excessive permissions, especially in repositories created before 2023. Actions referenced by mutable tags (e.g., v3) can be hijacked by attackers controlling upstream repositories. Self-hosted runners, if not properly isolated, allow one compromised job to affect the entire machine.
Network egress remains largely unrestricted, enabling easy data exfiltration to attacker-controlled servers or even private repositories. Traditional advice—pinning actions and limiting secrets—proves insufficient against sophisticated chained exploits.
Practical Defenses: Hardening GitHub Actions Workflows
Effective protection requires a defense-in-depth approach. Begin by scoping secrets with approval rules, ensuring only necessary workflows can access them. Minimize GITHUB_TOKEN permissions on a per-workflow basis, adhering to the principle of least privilege. Implement egress controls to restrict outbound connections from runners.
For self-hosted runners, enforce ephemeral instances and strong isolation. Tools like Step Security provide runtime hardening and firewall-like controls around runners, while GitHub’s upcoming Level 7 runner protections promise kernel-level isolation outside the runner’s reach.
Static analysis tools such as CodeQL (free for open source) and Zizmor detect workflow vulnerabilities. Dependency review bots help manage pinned versions. Organizations should treat CI/CD as production-equivalent, applying the same scrutiny to workflows as to application code.
Runtime protections and regular secret rotation further reduce the blast radius of potential breaches. Automation of security scanning within pull requests ensures issues are caught early.
Conclusion: Treating CI/CD as Production Infrastructure
GitHub Actions represents both a productivity powerhouse and a significant supply chain risk. By understanding real attack patterns and implementing layered defenses—from minimal permissions and scoped secrets to runtime controls and automated analysis—teams can substantially reduce their exposure. Security must be integrated from the outset of workflow design rather than bolted on afterward. As attackers increasingly target the CI layer, proactive hardening becomes essential for maintaining trust in modern software delivery pipelines.
Links:
[NDCMelbourne2025] Front End Testing with GitHub Actions – Amy Kapernick
In a dynamic session at NDC Melbourne 2025, Amy Kapernick, a seasoned front-end developer and advocate for automation, unveils a streamlined approach to front-end testing using GitHub Actions. With a focus on practicality, Amy guides developers through constructing a robust continuous integration and continuous deployment (CI/CD) pipeline, ensuring that front-end tests run seamlessly against live websites. Her presentation underscores the necessity of automation to maintain quality in web development, offering actionable insights for teams seeking to integrate testing into their workflows without manual intervention.
The Imperative of Front-End Testing
Amy begins by highlighting the unique challenges of front-end testing, emphasizing that unlike unit tests, which can operate with dummy data, front-end tests require a live, functioning website to evaluate real-world performance. For instance, assessing accessibility for visually impaired users or determining page load speeds demands an environment that mirrors production. Amy illustrates this with a CSS code snippet, questioning whether it can reveal unintended style bleed or performance bottlenecks without a live interface. By advocating for environments as close to production as possible, she ensures that tests yield accurate, actionable results, setting the stage for automation to eliminate manual testing inconsistencies.
Automating with GitHub Actions
The core of Amy’s approach lies in leveraging GitHub Actions to automate front-end testing within a CI/CD pipeline. She explains that GitHub Actions’ workflows, defined in YAML files, enable developers to trigger tests on specific events, such as pull requests to a production branch. Amy walks through creating a workflow with jobs like “build” and “test,” detailing steps such as checking out repository code, setting up Node.js, and installing dependencies. By using existing GitHub Actions packages, like those for checking out code and configuring Node, she simplifies the process, ensuring tests run consistently without manual effort. This automation, Amy notes, prevents code merges that fail tests, safeguarding application quality.
Deploying and Testing Live Websites
A pivotal aspect of Amy’s workflow involves deploying a live website for testing, using Netlify for its ease and deploy preview capabilities. She demonstrates a custom bash script to deploy to Netlify, addressing challenges like handling sensitive data, such as site IDs, which GitHub Actions may flag as secrets. Amy ingeniously encodes the deployment URL to bypass security restrictions, decoding it for testing with tools like Lighthouse and Playwright. These tools provide comprehensive reports on performance and UI functionality, respectively, which Amy configures to upload as artifacts, ensuring developers can review results and address issues before merging code.
Enhancing Workflows with Additional Automation
Beyond testing, Amy showcases GitHub Actions’ versatility by integrating a package that converts code comments into GitHub issues, ensuring tasks like “fix later” are tracked. This automation assigns issues to the code’s author and auto-closes them when resolved, streamlining project management. Amy also touches on other uses, such as linting, checking broken links, and generating assets like static tweet images for blog posts. These examples highlight how GitHub Actions can extend beyond testing to enhance overall development efficiency, making it a powerful tool for modern workflows.
Links:
[DefCon32] DEF CON 32: Grand Theft Actions – Abusing Self-Hosted GitHub Runners
Adnan Khan and John Stawinski, security researchers, delivered a riveting presentation at DEF CON 32, exposing systemic vulnerabilities in GitHub Actions’ self-hosted runners. Their research revealed how misconfigurations enable attackers to compromise major open-source projects like PyTorch, leading to supply chain attacks. Earning over $250,000 in bug bounties, Adnan and John shared tactics, techniques, and procedures (TTPs) to elevate trivial compromises into critical breaches, urging organizations to bolster CI/CD security.
Exploiting Self-Hosted Runner Misconfigurations
Adnan and John opened by explaining GitHub Actions’ role as a leading CI/CD platform and its reliance on self-hosted runners—machines executing workflow jobs. They detailed how insecure defaults allow attackers to compromise runners, gaining access to sensitive repositories. Their attack on PyTorch demonstrated how a runner compromise enabled code contributions to the main branch, malicious release uploads, and backdooring related projects, highlighting the catastrophic potential of such flaws.
Escalating Privileges in GitHub Actions
Delving deeper, the duo showcased techniques to escalate privileges within GitHub Actions workflows, leveraging GitHub’s permissive features. Their research campaign uncovered vulnerabilities in organizations like Microsoft, TensorFlow, and ByteDance, exploiting misconfigured runners to achieve critical impacts. Adnan’s live demo illustrated how attackers could manipulate workflows to gain unauthorized access, emphasizing the need for robust access controls and monitoring in CI/CD pipelines.
Real-World Impact and Bug Bounty Success
Adnan and John shared war stories from their extensive bug bounty submissions, noting that internal CI/CD systems are often more vulnerable than public ones. Their work, yielding significant bounties, exposed a lack of awareness around CI/CD security. They highlighted successful mitigations by triage teams, urging organizations to learn from their findings. The duo’s research on platforms like HackerOne provides a blueprint for identifying similar vulnerabilities in other systems.
Strengthening CI/CD Security
Concluding, Adnan and John emphasized the need for heightened awareness among developers, architects, and executives to prevent supply chain attacks. They recommended isolating privileged runners, auditing configurations, and educating teams on CI/CD risks. Their call to action inspired attendees to explore these attacks and implement controls, ensuring organizations are better equipped to thwart the next critical breach in their CI/CD pipelines.