GitHub Supply Chain Attack Raises Awareness Across The Cybersecurity Community

DALL·E 2025-03-22 00.13.26 - A hyper-realistic image depicting a supply chain attack in cybersecurity. A businessman in a modern office is reviewing a shipment document on his com

The recent GitHub software supply chain attack has exposed up to 23,000 repositories, which now has CISA sounding the alarm. The vulnerability is affecting a widely used third-party GitHub Action named tj-actions/changed-files. This compromise poses a significant risk because it permits unauthorized access to private RSA keys, GitHub Personal Access Tokens (PATs), npm tokens, and access keys.

The cybersecurity community has given us their insights on the significance of this attack and what can be learned surrounding software supply chain vulnerabilities to help prevent and mitigate these threats in the future.

Alex Ilgayev, Head of Security Research, Cycode

This attack on tj-actions/changed-files is a wake-up call for our software supply chain security community. With over 23,000 repositories potentially compromised, attackers weren’t just stealing secrets—they were targeting the foundation of open-source development. We understand proactive risk management and how to help detect, analyze, and remediate threats in GitHub Actions. Our research team extensively investigated this incident and acted right away to develop a CI/CD leak scanner to help the community determine if their pipelines have been compromised.

Any CI/CD pipeline referencing malicious actions involved with tj-actions/changed-files may have leaked critical credentials, putting organizations in more risk of exploitation. This isn’t an isolated incident—it’s part of a growing trend where attackers weaponize trusted open-source components to infiltrate enterprise environments. Given GitHub’s rapidly growing adoption, it’s more critical than ever for organizations to act fast and secure their pipelines.

Audit workflows, rotate secrets, and use proactive security measures to detect and block supply chain attacks before they escalate. The stakes are too high for reactive security so teams must have it top of mind. For Cycode’s complete guide for this supply chain attack, visit here.

David Stuart, Cybersecurity Evangelist, Sentra

The attack on GitHub underscores the critical need for better protection against data leakage and misconfiguration in code repositories. Preventing data loss – whether through overexposure, misconfigurations, or the accidental inclusion of sensitive information like passwords and secrets – requires a proactive approach.

Organizations should focus on two key areas: strengthening data posture management to identify and protect sensitive data before exposure occurs and continuously monitoring for threats targeting data stores where valuable intellectual property or credentials may reside. By taking these steps, companies can reduce the risk of sensitive data falling into the wrong hands.

Joe Silva, CEO, Spektion

The recent supply chain attack on GitHub Actions is upstream of typical supply chain attacks as it impacts the supply chains of multiple projects. The fact that private repositories should be considered compromised indicates potential risk across a broad swath of commercial software leveraging GitHub Actions. There may be subsequent disclosures of software being exploited due to this event, and ultimately this degrades trust in the commercial and open-source software ecosystem, as well as creates increased risk in homegrown software created by users in companies.

This GitHub incident demonstrates the increasing frequency of supply chain attacks. Once primarily the domain of sophisticated nation-states, these attacks, as with other TTPs in the past, are increasingly proliferating to non-state actors as the technical and economic limitations on the attacks diminish. The proliferation of these attacks and the overall degraded trust they create in the software ecosystem makes it more important than ever that organizations have run-time visibility into software risk, rather than rely on disclosures/CVEs or detection of attacks after impacted software has already been exploited.

Dr. Katie Paxton-Fear, Principal Security Research Engineer, Harness

GitHub Actions automates software development workflows, executing small scripts triggered by code changes. Common uses include running tests to prevent faulty code from reaching users. The “tj-actions/changed-files” action, as its name suggests, provides a list of files modified since the last commit.

An attacker successfully added a malicious function to this automation, designed to steal credentials and transmit them. The method employed was intriguing: they inserted obfuscated code that executed a Python script, which located and exfiltrated credentials—a relatively common tactic. The key to their success lay in circumventing maintainer scrutiny. Initially attributed to a compromised bot access token, the attack actually hinged on including an outdated component alongside the malicious payload. The “tj-actions” bot, programmed to update outdated components, automatically generated a new commit. This commit, critically, included both the updated component and the attacker’s malicious code. Although the attacker’s original pull request was ignored due to a lack of verification, the bot’s commit was automatically verified and deployed as it was trusted.

Users of the “changed-files” action should immediately rotate their credentials. This involves invalidating existing credentials and generating new ones, effectively neutralizing any stolen information.

This incident highlights the growing threat to open-source projects. Attackers are increasingly targeting these projects to distribute malware or steal credentials, leveraging their trusted status. Open-source maintainers must stay informed about evolving attack techniques and remain vigilant. While this attack doesn’t undermine the value of open source, it underscores the limited resources and security challenges faced by many projects. Organizations heavily reliant on open-source software should consider providing support to enhance the security posture of these vital projects.

The takeaway for this attack is that the method they used to actually get the code passed the maintainers, so much so the maintainers actually didn’t attribute it correctly the first time. Because the attackers knew the bot is trusted, they managed to essentially use a dependency bot as a malware mule.

Nick Mistry, SVP, CISO, Lineaje

The recent GitHub supply chain attack, which exposed sensitive data from 23,000 projects, highlights a critical, often overlooked risk: the security of build tooling and CI/CD pipeline plugins. This attack wasn’t due to a vulnerability in application code, but a compromised plugin within the build process, emphasizing the need for Software Bill of Materials (SBOMs) that cover not just application code, but also build tools and dependencies.

Plugins, which are used to automate workflows, often have high-level permissions and are not checked as thoroughly as code dependencies, making them targets for attackers. To reduce these risks, organizations should regularly analyze vulnerabilities across the entire software environment, including build systems.

This attack emphasizes the need for a thorough approach to supply chain security, including real-time monitoring and automatic threat detection for both code and build tools to ensure the safety of every part of the software delivery process. It’s time to talk about the need for an SBOM for your build pipeline to account for this GitHub incident and to help prevent similar ones in the future.

Conclusion

In conclusion, the recent attack on the GitHub supply chain is a clear reminder of the weaknesses in software development procedures. Given that up to 23,000 repositories were affected, this incident emphasizes how important it is to implement proactive security measures.