Git dependency

Information

There are a number of security risks associated with using packages that have Git dependencies. Most notably, these are non-immutable dependencies. Dependencies fetched directly from remote Git URLs can be problematic because the tampered with after it's downloaded, potentially injecting malicious code into your project.

Additionally, using packages with git dependencies can create reproducibility issues and security vulnerabilities, as they 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.

Git dependencies can also introduce other risks to stability, reliability, and compliance:

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.

Recommended actions

When you get a Git dependency or GitHub dependency alert for one of your packages or updates, there are a few best practices to keep in mind.

• 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.

It's also important to understand that there are a number of legitimate use cases for git dependencies in open source packages. They are often used as a way to give access to unreleased features or bug fixes, incorporate forks and custom modifications, testing an experimental feature branch, hosting private or proprietary code, or as part of a monorepo workflow.

Developers should be aware of the trade-offs and ensure they implement proper security measures to mitigate the risks when using packages with git dependencies.

• 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:
  • Use Socket to monitor and analyze your dependencies for potential risks and vulnerabilities. These tools can provide alerts and recommendations to help you mitigate the risks associated with this practice.

How to Configure Your Security Policy

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.

Examples

Here's an example of a package with this alert. It is considered a high severity alert in the supply chain risk category.

The alert links to package.json where the Git repo is listed as a dependency:

Specific examples of Git dependency attacks in the wild are less commonly documented compared to other types of supply chain attacks. Although many high profile attacks have not directly reference a Git dependency in a package.json, it is very common to see dependencies hosted on GitHub getting compromised.

For example, 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.

Detection Method

Packages are flagged with this alert when they include dependencies that are sourced directly from a remote Git URL.

Additional resources

npm Documentation: Dependencies

• This page covers how to specify versioned dependencies in a package.json file, emphasizing the benefits of using versioned packages for consistency and stability.

Yarn Documentation: Selective Dependency Resolutions

• This page discusses how to manage dependencies with specific versions, helping ensure that your project remains stable and predictable.

NPM Documentation: Package Lock Files

• This page explains how to use package-lock.json to ensure consistent dependency versions and avoid issues with Git-hosted dependencies.