Software supply chain attacks are on the rise because of their reach. Here are 10 valuable lessons from the recent GitHub namespace attack.
Hijacking code repositories, or repojacking, wasn't new when security researchers discovered a serious vulnerability in the mechanism GitHub uses to retire namespaces, but the flaw in the development hub made the software community painfully aware of how defenseless it could be in the face of such software supply chain attacks.
Repojacking targets a legitimate namespace in GitHub. The architecture of the hub allows user names to be changed through a renaming feature. After a change, traffic to the old name is redirected to the new name. The flaw discovered by security firm Checkmarx in October could allow adversaries to use the feature to send users of renamed repositories to malicious destinations and put at risk thousands of software packages.
GitHub is the most popular code hosting platform in the world, with 90 million users and 330 million projects — putting a target on its back, said Om Vyas, chief product officer and co-founder of Oak9, a cloud-native infrastructure security provider.
"GitHub, being a central repository for developers to host their open-source software for others to consume, is a prime target to spread malware at an exponential rate."
—Om Vyas
Naomi Buckwalter, product security director at Contrast Security, said that if a threat actor can discover and exploit a vulnerability in a popular project, which also happens to be used in hundreds and thousands of applications around the world, then chances are that it’d be much, much easier to successfully attack multiple organizations at once.
"This is a huge return on investment for threat actors. Hack once, pwn everywhere. Hijack just one popular Github repository, and you can have a backdoor into multiple organizations. What threat actor wouldn’t like to try that?"
—Naomi Buckwalter
Now that the dust has settled around the GitHub namespace flaw, here are 10 valuable lessons for software development teams.
1. Understand what open-source software you're using, and the vulnerabilities within
Using open-source software is now standard operating procedure on most, if not all, modern development teams, Buckwalter said. "A single vulnerability in a popular open-source library can cause havoc. Just look at the fallout from Log4Shell."
2. Monitor whether open source has been renamed or moved
Henrik Plate, a security researcher at the dependency management company Endor Labs, said monitoring open source is key. "Rather than relying on automated redirects—and related protection mechanisms—to work properly, you should update those resource references to the new locations," Plate said.
3. Audit code in repositories, and create a private fork for your own use
Melissa Bischoping, director and endpoint security research specialist at Tanium, said auditing was paramount. "Avoid pulling code 'live' from sources such as GitHub repos that you don’t control and audit. Otherwise, it’s impossible to conduct proper security reviews on every single change," said Bischoping.
4. Use a software bill of materials (SBOM) for an accurate inventory of your software components
Use SBOMs to give you insight into dependencies and risks, Bischoping suggested. "While we hope to see more software providers offering clear and transparent documentation of their dependencies and libraries, SBOM serves as an essential tool to empower the users of third-party software to understand if and when these vulnerabilities impact them."
5. Secure your GitHub account
Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, said it’s important to understand that any GitHub attack first starts with compromising a GitHub account. "Enabling two-factor authentication or the use of the GitHub Mobile registration are two key options to reduce the potential for any GitHub account to be compromised," Mackey said.
6. GitHub repository owners should define an end-of-life for their repos
Mackey said ownership and management of repos is key. "That includes having trusted individuals as owners or group accounts and defining a GitHub successor — in addition to publishing explicit end-of-life or deprecation statements," Mackey said.
7. Software teams should look for evidence of good health in GitHub repositories
Mackey said that anyone choosing a new project shouldn’t be looking at the historical popularity of a project, but instead for evidence that the project is actively maintained and is healthy. Healthy projects can be determined by the project’s GitHub Insights and its Code Contributors and Code Frequency data.
"If the project is popular, and there is limited activity or activity is limited to a handful of contributors, then that project isn’t as healthy as its popularity might indicate," said Mackey. "Unhealthy, but popular, projects are precisely the types of projects that attackers will gravitate towards, as unauthorized changes to the code or configuration are more likely to fly under the radar screen for an extended period of time," he added.
8. Get really good at asset management
Buckwalter noted that asset management comes down to three things: Knowing what open-source libraries are currently used in your environment, their true source locations, and their known vulnerabilities.
"There is a saying in information security: 'You can’t protect what you don’t know about,'" Buckwalter said. "The same holds true for supply chain attacks via Github. Keep an accurate asset inventory of your open-source libraries and make sure they always point to their true source locations — not the location that’s been redirected — and keep the libraries themselves up-to-date."
9. Contribute more time and money to open-source projects
Software supply chain attacks have become a never-ending story, said Scott Gerlach, co-founder and CSO of StackHawk, an API security testing provider.
"All of the light being shined on the issue should drive developers to actively check in on the public packages and repos they use," Gerlach said. "But that’s the problem. Repos and package services like npm, composer and PyPi, are run by volunteers in their free time. If we really expect these widely-used resources to become more secure, people will have to start contributing more time and money into maintaining them."
10. Security must be a first-class concern for software projects
John Campbell, director of content engineering at Security Journey, an application security education firm, said security must be muscle-memory to developers and those who support the software development lifecycle (SDLC).
"Security education fills the gaps in higher education programs for many professional software developers," Campbell said. "A solid, ongoing secure code training program establishes security principles that developers can rely on to make good, proactive decisions and provide prescriptive actions to improve the organization’s security posture."
It's all about awareness and taking action
By understanding security principles, developers can implement supply chains and build pipelines that are protected against attacks, Campbell said.
"We can reduce the attack surface by implementing processes that maintain software components by pinning them to specific component versions, while using private vendors to control them and avoiding direct links to repos like Github."
—John Campbell
