How to Mitigate the Risks of Using Open Source Packages with Git Dependencies

Imagine a popular open-source project called cool-library that includes a dependency directly from a Git repository in its package.json:

{
  "dependencies": {
    "useful-library": "git+https://github.com/legit-developer/useful-library.git"
  }
}

Initially, the useful-library repository was maintained by a reputable developer, and everything seemed fine. Over time, the project gained traction and was widely adopted by developers around the world.

One day, the maintainer of useful-library decided to hand over the project to another developer due to personal commitments. The new maintainer, unfortunately, had malicious intentions. He subtly modified the useful-library codebase to include a backdoor that would exfiltrate sensitive data from any project using it. These changes were pushed to the Git repository without raising any alarms.

Since cool-library had a direct Git dependency, anyone installing or updating it would automatically fetch the latest version of useful-library with the embedded backdoor. Developers and organizations would unknowingly pull the compromised code into their projects, leading to data breaches and other security incidents.

A week after the malicious changes were made, a security researcher noticed unusual network traffic originating from applications using cool-library. Upon investigation, the backdoor in useful-library was discovered, and an advisory was issued. The open-source community quickly responded by removing the compromised dependency, but the damage had already been done. Sensitive information from numerous projects had been leaked, and the trust in cool-library was significantly eroded.

This hypothetical scenario illustrates the risks associated with using Git dependencies in open-source projects. Without thorough vetting and constant monitoring, a seemingly benign update can lead to severe security breaches.

Potential Dangers of Compromised GitHub Repositories#

Specific examples of Git dependency attacks in the wild are less commonly documented compared to other types of supply chain attacks. However, the concept remains important to understand due to the potential risks.

In 2018, the npm security team foiled a plot to steal cryptocurrency when the electron-native-notify npm package was compromised. An attacker gained access to the maintainer's GitHub account and injected malicious code into the electron-native-notify repository. The malicious code included a post-install script that collected and sent sensitive information to a remote server. The compromised version was published to npm, and projects depending on this package unknowingly included the malicious code.

This particular attack utilized a strategy where the maintainer published a legitimately useful package to npm (electron-native-notify) and then waited until it was in use by the intended target. Once the package was more widely adopted, it was updated to include a malicious payload.

Although this example does not directly reference a Git dependency in a package.json, it illustrates the risks associated with dependencies hosted on GitHub. If a project were to pull dependencies directly from a Git repository, there is always the risk of accounts getting compromised.

What Are the Risks Associated with Git Dependencies?#

While there are some legitimate use cases for referencing Git dependencies, and not every package that does this is malicious, it’s important to understand the security risks associated with them:

• Non-Immutable Dependencies: Dependencies fetched directly from remote Git URLs can be problematic because they are not inherently immutable. This means the code can be tampered with after it's downloaded, potentially injecting malicious code into your project.
• Unpredictability: Git tags can be moved around, much like a branch. Unlike versioned packages from official registries, Git dependencies can point to tags or branches that can be changed or moved after being initially set. This can lead to unpredictability in your codebase because the dependency's code might change unexpectedly, potentially introducing breaking changes or vulnerabilities.
• Reproducibility Issues: Dependencies from remote Git URLs can make it difficult to ensure a reproducible build. This means that if you try to rebuild your project on a different machine, you might end up with a different set of dependencies due to changes in the remote Git repository.
• Security Vulnerabilities: Directly referencing Git repositories can bypass the typical vetting processes that are in place for packages published to official registries. This increases the risk of introducing malicious code or vulnerabilities, as the code in the repository might not have undergone the same scrutiny as versioned packages.

Apart from the direct security risks, there are also a number of other stability, consistency, and compliance concerns that can result from using Git dependencies:

1. Lack of Version Control:

• Git dependencies often point to branches or commit hashes that change over time, leading to unpredictability as updates may introduce breaking changes or vulnerabilities without notice.

⠀2. Stability and Reliability Issues:

• Dependencies from Git repositories can be disrupted if the repository owner makes changes or deletes it, causing build failures and affecting application stability and reliability.

⠀3. Dependency Drift:

• Over time, Git-sourced dependencies can drift from their initial state, causing inconsistencies and compatibility issues that are hard to track and manage.

⠀4. Difficulty in Auditing:

• Git dependencies are harder to audit compared to those from official package registries, complicating efforts to maintain a secure software supply chain and monitor changes.

Legitimate Use Cases for Git Dependencies

There are legitimate reasons why a Git dependency might be found in an open source package, so it’s important to be aware of some of the most common ones. It’s often used as a way to give access to unreleased features or bug fixes, incorporate forks and custom modifications, test an experimental feature branch, host private or proprietary code, or include as part of a monorepo workflow.

While Git dependencies can introduce certain risks, such as the potential for supply chain attacks, there are many legitimate reasons for their use. Developers should be aware of the trade-offs and ensure they implement proper security measures to mitigate the risks.

Navigating Socket’s Git Dependency Alert#

Socket identifies Git dependencies as a high severity alert, because of the risks it introduces to supply chains.There are two related alerts: Git dependency and GitHub dependency, which is specific to that platform.

The Git/GitHub Dependency alerts are triggered when a package includes dependencies that are sourced directly from a Git repository or GitHub URL, rather than from a versioned package registry like npm, PyPI, or Maven Central. These dependencies are not immutable can be used to inject untrusted code or reduce the likelihood of a reproducible install.

Clicking on the alert links to the package.json file where the GitHub repository is listed as a dependency:

If you are using Socket and one of your packages triggers this alert or you see it on a dependency update, it’s a good idea to investigate further. In the most ideal world, you would be using only versioned packages.

Best Practices for Git Dependencies

• Prefer Versioned Packages:
  • Whenever possible, use versioned packages from official registries. These packages have a more predictable update cycle and are subject to the registry's security policies and checks.
• Pin Specific Commits or Tags:
  • If you must use a Git dependency, pin it to a specific commit or tag rather than a branch. This ensures that the dependency remains stable and predictable over time.
• Regular Audits:
  • Regularly audit your dependencies, including those sourced from Git repositories. Ensure that they are still maintained, secure, and compatible with your application.
• Use Security Tools:
  • Employ security tools and practices, such as Socket, to monitor and analyze your dependencies for potential risks and vulnerabilities.

Many Socket users elect to configure their Security Policies to Warn for the Git Dependency alert, but you can also make it more a more serious concern and Block these dependencies. By understanding and mitigating the risks associated with Git dependencies, you can better ensure the security and stability of your applications.

Socket’s alerts make it easier to monitor packages with Git dependencies. If you are not yet using Socket, you can install the GitHub app for free in two clicks. This will give you a complete overview of your usage of packages with Git dependencies and will scan for 70+ other supply chain risks.