Remove Easyjson Dependency: A Supply Chain Risk Guide

Hey guys! Let's dive into a critical discussion about supply chain security and how we can better protect our projects. Today, we're tackling an indirect dependency on a Go library called easyjson (github.com/mailru/easyjson), and why it's crucial to remove it. This library, while seemingly innocuous, has maintainers based in Russia and affiliated with VK Group, a company with strong ties to the Russian government. This connection raises serious concerns about potential supply chain risks, as highlighted in the Hunted Labs report, "The Russian Open Source Project That We Can’t Live Without".

The Problem: Why easyjson Poses a Risk

As developers, we often rely on external libraries to streamline our workflow and avoid reinventing the wheel. However, every dependency we introduce adds a potential point of vulnerability. When a dependency has connections to entities with questionable security practices or geopolitical risks, the stakes are even higher. In the case of easyjson, its maintainers' affiliation with VK Group – which has a history of cooperating with Russian security services, including sharing user data – is a red flag. The Hunted Labs report paints a stark picture, warning that a compromised easyjson library could lead to:

• Supply chain backdoors: Malicious code injected into the library could grant attackers unauthorized access to systems that use it.
• Remote code execution: Attackers could exploit vulnerabilities in the library to execute arbitrary code on target machines.
• Espionage: The library could be used to collect sensitive information and transmit it to malicious actors.
• Data exfiltration: Attackers could steal valuable data from systems that rely on the library.
• Potential "kill switch" functionality: A backdoor could be implemented to remotely disable or disrupt systems using the library.

These are not hypothetical threats. Supply chain attacks are on the rise, and targeting widely used libraries is a common tactic for attackers. By compromising a single library, they can potentially gain access to thousands of systems that depend on it. Therefore, it's our responsibility to proactively mitigate these risks.

Identifying the Indirect Dependency: github.com/wk8/go-ordered-map/v2

So, how did we even end up with this dependency? Well, our project has a direct dependency on github.com/wk8/go-ordered-map/v2, which, in turn, relies on easyjson. This is what we call an indirect dependency – a dependency that your project doesn't directly import, but is brought in by one of your direct dependencies. Understanding these indirect dependencies is crucial for maintaining a secure supply chain.

The Solution: Removing the Dependency

The good news is that we can remove this indirect dependency and reduce our risk exposure. The process might involve a few different strategies, and the best approach will depend on the specific context of our project. Let's explore some options:

1. Evaluate Alternatives to github.com/wk8/go-ordered-map/v2

The most direct way to eliminate the indirect dependency on easyjson is to remove the direct dependency that brings it in – in this case, github.com/wk8/go-ordered-map/v2. We should explore alternative libraries that provide similar functionality but don't rely on easyjson. There are several excellent Go libraries for working with ordered maps. Some popular options include:

• golang.org/x/exp/maps (Go 1.18+): This package, part of the official Go experimental libraries, provides generic map functions, including ordered map functionality. If our project is using Go 1.18 or later, this might be a great option, as it's part of the standard library ecosystem and well-maintained.
• github.com/elliotchance/orderedmap: This library offers a robust implementation of ordered maps with a rich set of features. It's a well-established and actively maintained project.
• Roll our own: For simpler use cases, we might even consider implementing our own ordered map functionality. This gives us complete control over the implementation and eliminates external dependencies altogether. However, this option requires careful consideration of the performance and security implications.

When evaluating alternatives, we need to consider factors like: performance, API compatibility, ease of use, maintenance activity, and security reputation. A thorough evaluation will help us choose the best replacement for github.com/wk8/go-ordered-map/v2.

2. Patch or Fork github.com/wk8/go-ordered-map/v2 (If Necessary)

If we determine that github.com/wk8/go-ordered-map/v2 is the only viable option for our project (perhaps due to specific features or performance characteristics), we might consider patching or forking the library. This involves modifying the library's code to remove the dependency on easyjson.

• Patching: If the dependency on easyjson is limited to a specific part of the library, we might be able to create a patch that replaces the easyjson functionality with an alternative implementation. We can then submit this patch to the library maintainers or maintain our own patched version.
• Forking: If a patch isn't feasible or the library maintainers are unresponsive, we can fork the repository and maintain our own version of the library with the easyjson dependency removed. This gives us complete control over the library's code, but it also means we're responsible for its maintenance and security.

Forking should be a last resort, as it adds a long-term maintenance burden. However, in situations where there's no other viable option, it can be a necessary step to mitigate supply chain risks.

3. Vendor Dependencies and Use Go Modules Effectively

Regardless of the approach we take to remove the easyjson dependency, it's crucial to use Go modules effectively and vendor our dependencies. Go modules provide a robust mechanism for managing dependencies and ensuring reproducible builds. Vendoring involves copying the dependencies into our project's repository, which isolates us from changes in the upstream libraries.

By vendoring our dependencies, we can:

• Ensure consistent builds: We're not relying on external sources for dependencies, so our builds will be consistent over time.
• Mitigate supply chain attacks: Even if a dependency is compromised upstream, our vendored version will remain unaffected (at least until we update it).
• Gain greater control over our dependencies: We can inspect and modify our vendored dependencies if needed.

To vendor dependencies in Go, we can use the go mod vendor command. This will copy all the dependencies listed in our go.mod file into the vendor directory.

Implementing the Solution: A Step-by-Step Guide

Okay, so we've discussed the problem and the potential solutions. Now, let's outline a practical step-by-step guide to removing the indirect dependency on easyjson:

1. Analyze the Dependency Tree: Use go mod graph to visualize the dependency tree and confirm the indirect dependency on easyjson via github.com/wk8/go-ordered-map/v2.
2. Evaluate Alternatives: Research alternative libraries to github.com/wk8/go-ordered-map/v2 that don't depend on easyjson. Consider golang.org/x/exp/maps or github.com/elliotchance/orderedmap.
3. Test the Alternatives: Implement the chosen alternative in a non-production environment and thoroughly test its functionality and performance.
4. Implement the Change: Replace github.com/wk8/go-ordered-map/v2 with the chosen alternative in our codebase.
5. Run Tests: Run all unit and integration tests to ensure the change hasn't introduced any regressions.
6. Vendor Dependencies: Use go mod vendor to vendor the dependencies.
7. Commit the Changes: Commit the changes to our repository with a clear and descriptive commit message.
8. Deploy to Production (Gradually): Deploy the changes to production in a controlled manner, monitoring for any issues.

Conclusion: Prioritizing Supply Chain Security

Removing indirect dependencies like the one on easyjson is a critical step in securing our software supply chain. By understanding the risks, evaluating alternatives, and implementing a robust dependency management strategy, we can significantly reduce our exposure to potential attacks. Supply chain security is an ongoing process, not a one-time fix. We must remain vigilant, regularly review our dependencies, and proactively address any potential vulnerabilities. Let's work together to build a more secure and resilient software ecosystem!

By taking these steps, we can safeguard our projects and our users from the potential consequences of a compromised dependency. Let's make supply chain security a priority in our development practices!

This article aims to inform and guide developers in mitigating supply chain risks associated with indirect dependencies, specifically focusing on the removal of easyjson. Remember to always stay informed about the latest security threats and best practices to keep your projects secure.