GitHub Actions supply chain attack spotlights CI/CD risks
Experts say a GitHub Actions vulnerability should renew enterprises' attention to securing build pipelines the same way they secure production environments.
Last week's GitHub Actions supply chain attack shows that five years after SolarWinds, enterprises still aren't properly securing build pipelines, according to security specialists.
A vulnerability discovered March 14 in a GitHub Actions repo, tj-actions/changed-files, allows attackers to discover secrets by reading Actions log digests. Tj-actions/changed-files is a tool that identifies which files have changed in a code pull request or commit. Developer teams use this tool to streamline CI/CD workflows so that they only perform tasks such as tests and deployments on changed files. The compromised repository was taken down March 15 and a patched version was published, but it's still possible that the malicious script attackers inserted into the affected repo has already executed and leaked secrets to workflow logs in downstream environments.
To invoke this GitHub Action, repositories can reference it using tags in code, as opposed to the more secure method of pinning Actions to a full-length secure hash algorithm function. Any public repository that invoked the compromised version of the GitHub Action this way would publicly leak credentials in its log digest. A public post by SecurityStep researchers who uncovered the bug said some 23,000 GitHub repositories use the affected repo.
It gets worse, according to software supply chain security experts.
"Repositories that referenced the action by tag (e.g. tj-actions/changed-files@v2) were immediately affected," wrote Matt Moore, co-founder and CTO at Chainguard, in an email to Informa TechTarget. "At the same time, automated tools, like Dependabot and Renovate, unwittingly spread the compromised action, updating even pinned versions of this action to the offending digest."
No one has a comprehensive picture of what credentials might have been accessed and compromised by the attacker, who remains unknown. Downstream open source projects that use code from public repositories where the compromised Action was embedded could have leaked secrets and passed on the bug through CI/CD pipelines.
There are some early indications that sensitive data has been leaked, according to Moore.
"We have seen and reported credentials for each of the major clouds, long-lived GitHub Personal Access Tokens, signing keys and more," Moore said. "We've also seen and reported impact to government agencies, large tech companies and several other distributions' repositories -- to name a few."
While the biggest risk of the GitHub Actions supply chain attack is to public repositories, Dimitri Stiliadis, co-founder and CTO at software supply chain security vendor Endor Labs, said private repositories aren't automatically safe.
"In some cases, the secrets used in open source repos are the same as private repos," he said. "Let's assume one of these public repos has a CI/CD pipeline that generates a Docker container that is published on the Docker Hub, and then a bunch of enterprises are downloading this container and using it. Now, the attacker that got the secrets can potentially go to Docker and push a container version that is malware, and now the malware can propagate to all the enterprises that use it."
'Another wake-up call'
If the attack pattern sounds familiar, that's because it's similar to previous high-profile software supply chain attacks, such as the compromise of a CI/CD pipeline at SolarWinds revealed in 2020, or the compromise in early 2021 of Codecov, a code coverage tool, which allowed unauthorized exports of information stored in users' CI/CD environments -- including the release signing key used by HashiCorp for Terraform. Or the threat uncovered in 2024 to a widely used open source set of command-line tools, XZ Utils, and the list goes on, according to Stiliadis.
The takeaway from those incidents and the GitHub Actions vulnerability is the same, according to both Moore and Stiliadis. IT organizations must start to secure development environments the same way they do production environments. But Stiliadis said that call to action hasn't been heeded in many corners of the industry.
"Another wake-up call, right?" he said. "For me, that's the headline. Treat your dev pipelines as if they were production environments. We have tools, and we have things to do that -- we are just not doing."
Another now time-honored bit of advice: Use short-lived credentials, which would limit the time an attacker has to use compromised credentials maliciously, Moore said.
"Credential leaks are one of the most common ways systems are compromised," Moore wrote, citing the 2024 Verizon Data Breach Investigations Report, which found that 31% of all breaches over the past 10 years have involved the use of stolen credentials.
"Long-lived credentials are at the heart of that," he said. "Companies should stop using long-lived credentials wherever possible, including [with] cloud service providers, like AWS, Azure and GCP. Eliminating the use of long-lived credentials wherever possible is one of the most impactful things that engineers can do to protect their organizations."
Instead, companies continue to focus their application security efforts on tools that have proven ineffective against supply chain attacks, such as code scanners. The most popular answers from 368 respondents to a November 2023 survey by Enterprise Strategy Group, now part of Omdia, included six kinds of scanners, along with software bills of materials for a small minority.
"This vulnerability highlights that using a software composition analysis scanner to check for known [common exposures and vulnerabilities] CVEs in open source software is insufficient for securing an organization's software supply chain," said Katie Norton, an analyst at IDC.
Instead, guidance from NIST last year suggested that determining the digital provenance of software through authenticated statements called attestations would be a more effective guard against such advanced attacks on CI/CD pipelines. GitHub is working on Immutable Actions, now in preview, that will include build attestations and provenance information.
For now, "Companies can and should secure their workflows by pinning actions to specific commits instead of tags to prevent unauthorized updates, and by restricting action permissions to read-only by default," Moore said.
Beth Pariseau, senior news writer for Informa TechTarget, is an award-winning veteran of IT journalism covering DevOps. Have a tip? Email her or reach out @PariseauTT.
