Following the compromise of a popular GitHub tool, developers are in David Bowie mode, having to turn and face their code repo’s strange ch-ch-changes.
The poisoning of an automation mechanism used in over 23,000 repositories exposed software-development credentials known as secrets. While GitHub promptly stopped the attack days after the report’s release, the discoverers of the supply-chain threat see similar compromises on the horizon as the secret’s out.
“It is a very nightmare-ish scenario that we are facing right now, with all these credentials that have been leaked,” StepSecurity co-founder and CEO Varun Sharma told IT Brew. “We can expect a lot more of these supply-chain attacks.”
What happened? On March 14, StepSecurity’s anomaly detection spotted the compromise of tj-actions/changed-files—a third-party GitHub Action that allows developers to see which files changed after a pull request or commit.
According to details from StepSecurity’s report, an access-token compromise of the “tj-actions” automation account used by the maintainer allowed a threat actor to modify the action’s code and retroactively update versions to reference the malicious commit, or revision.
The compromised action sent code-development “secrets”—credentials like passwords, encryption keys, API tokens, and digital certificates—into publicly viewable GitHub action logs, StepSecurity researchers said in their post.
GitHub, on March 15, both removed the tj-actions/changed-files Action for use and then later restored it free of the malicious exploit code.
Action! There is currently no evidence to suggest a compromise of GitHub or its systems, Jesse Geraci, online safety counsel at GitHub, wrote to us, adding that GitHub tj-actions is a user-maintained, open-source project.
“We reinstated the account and restored the content after confirming that all malicious changes have been reverted and the source of compromise has been secured. Users should always review GitHub Actions or any other package that they are using in their code before they update to new versions. That remains true here as in all other instances of using third-party code," Geraci shared in a written statement to IT Brew.
Top insights for IT pros
From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.
More to come. TideLift’s 2024 State of the Open-Source Maintainer report, released in September of that year, found that 60% of maintainers are not paid for their work—and professional maintainers are more likely to be able to prioritize remediating security vulnerabilities. (Maintainers also admitted to spending three times more on security work compared to 2021.)
“For trivial things, sometimes it makes sense to build them yourself, rather than rely on third-party dependencies that you don’t know,” Dimitri Stiliadis, co-founder and CTO of Endor Labs, told us.
Sharma imagines a scenario where attackers use the exposed secrets to create more code chaos and supply-chain attacks.
Owners of packages used by other developers, for example, can use secrets to publish new versions. An owner of a brand-new secret can potentially launch a malicious package that starts to look for more credentials.
“It’s now really up to these open-source maintainers who have these credentials in their logs. They need to take action. They need to find out where those credentials are logged, and then they need to rotate them to prevent these supply-chain attacks,” Sharma said.
On March 18, StepSecurity claimed “conclusive evidence” of compromises in several actions related to the GitHub organization reviewdog. “It’s possible that the tj-actions/changed-files incident may have been caused due to this, as several GitHub Actions workflows in the tj-actions organization use the compromised Actions. However, there is no conclusive evidence currently to link these two supply-chain security incidents,” the post read.