In-Depth Analysis: How InvisiRisk BAF Effectively Mitigates GitHub Actions Supply Chain Attacks Like the tj-actions/changed-files Compromise (CVE-2025-30066)
- David Pulaski
- Mar 26
- 4 min read
Updated: Apr 1
Introduction
The modern software development lifecycle is heavily reliant on automation, with CI/CD pipelines playing a central role. GitHub Actions has emerged as a leading platform for automating these workflows, enabling developers to streamline development and deployment processes. However, this increased reliance on automation also introduces new security challenges, as highlighted by the recent supply chain attack targeting the widely used tj-actions/changed-files GitHub Actions. This incident, impacting a large number of repositories, serves as a stark reminder of the potential consequences of supply chain vulnerabilities and the critical importance of implementing robust security measures within the CI/CD pipeline. This security incident is tracked as CVE-2025-30066. In this blog post, we will provide a comprehensive and in-depth analysis of the tj-actions/changed-files attack, detailing its mechanics and impact, and demonstrate precisely how InvisiRisk’s Build Application Firewall (BAF), with its proactive default security policies, would have effectively prevented this attack, safeguarding development environments and sensitive data.
Brief Examination of the tj-actions/changed-files Attack
The tj-actions/changed-files is a popular and widely adopted GitHub Actions designed to simplify the process of identifying files that have been changed within a repository, typically in the context of pull requests or pushes.
Here's a detailed breakdown of the tj-actions attack vector, outlining the stages of the attack and the techniques employed:
Injection of Malicious Code: A Node.js function containing base64-encoded payloads was inserted into the GitHub Actions.
Malicious Code Execution: Once the GitHub Actions was compromised, the injected malicious code was designed to be executed within the CI runner environment during the execution of workflows that utilized the compromised GitHub Actions. This execution occurred within the Runner Worker process.
Downloading a Payload: The base64 payload is decoded to reveal a script that downloads additional Python code from a GitHub gist. Specifically, the malicious code used a curl command to retrieve a malicious Python script from an external source.
Memory Scanning: The Python script identifies the GitHub Runner’s process (specifically the “Runner.worker” process), opens its memory mappings, and searches for sensitive credentials using regular expressions.
Exfiltration of Data: The results are written to the GitHub Actions build logs. The attackers must have access to these logs to extract the secrets.
Objective: Secret Exfiltration: The primary objective of the malicious code retrieved from the external source was to extract sensitive information from the CI runner's memory.
InvisiRisk BAF: A Real-Time and Layered Defense Strategy
InvisiRisk BAF is a security solution specifically designed to protect the software build process from various threats, including supply chain attacks. It employs real-time protection, leveraging a set of default security policies that are designed to block vulnerabilities, enforce the use of trusted sources, and prevent unauthorized actions from being performed during the build process.
InvisiRisk comes out-of-the-box with a set of default policies that covers a wide range of protection for your build system. Among them, the policy "Only Allows Trusted Package Registry" would have prevented the tj-actions attack:
"Only Allows Trusted Package Registry" Policy: One of the core default security policies implemented by BAF is the "Only Allows Trusted Package Registry" policy. This policy is designed to control and restrict the sources from which packages and other dependencies can be retrieved during the build process.
Interception of External Requests: When the compromised tj-actions GitHub Actions attempted to use the curl command to download the malicious Python script from the external source (gist.githubusercontent.com), BAF would have intercepted this network request. BAF is designed to monitor and intercept network traffic originating from the build environment to enforce its security policies.
Trusted Source Verification: Upon intercepting the curl request, BAF would have performed a check against its list of trusted package registries and sources. It would have verified whether gist.githubusercontent.com is included in the list of approved sources.
Blocking the Untrusted Request: In this case, gist.githubusercontent.com would not have been found in BAF's list of trusted sources. As a result, BAF would have taken action to block the network request, blocking the curl command from establishing a connection and downloading the malicious python script.
Prevention of Malicious Code Execution: By blocking the retrieval of the malicious payload from the untrusted source, InvisiRisk BAF effectively prevents the execution of the malicious code within the CI runner environment. This prevents the attacker from achieving their objective of extracting sensitive secrets and credentials.
Mitigation of the Attack: Through the enforcement of the "Only Allows Trusted Package Registry" policy, InvisiRisk BAF successfully mitigates the tj-actions attack. The attack is neutralized at the stage of payload retrieval, preventing any further damage or compromise.
Visualizing InvisiRisk BAF's Protective Mechanism
This incident highlights the necessity of embedding security directly into build processes to safeguard against evolving threats. Adopting solutions like InvisiRisk BAF ensures resilient, attack-resistant automation pipelines.
References
コメント