Open Source Gets Political: What The easyjson Debate Misses (and what to do about it)
A look at the easyjson controversy, open source provenance, and how Go's built-in protections help teams manage risk without overreacting.
A look at the easyjson controversy, open source provenance, and how Go's built-in protections help teams manage risk without overreacting.
A look at the easyjson controversy, open source provenance, and how Go's built-in protections help teams manage risk without overreacting.
A look at the easyjson controversy, open source provenance, and how Go's built-in protections help teams manage risk without overreacting.
A look at the easyjson controversy, open source provenance, and how Go's built-in protections help teams manage risk without overreacting.
What’s going on
A recent article called attention to the Go package easyjson, citing its ties to VK, a Russian tech company with sanctioned leadership. While the coverage raises important questions about software provenance, it’s critical to separate speculation from technical reality.
There are currently no vulnerabilities or known security risks in easyjson. The concern is not about code behavior—it’s about who maintains it, and what the future might hold. That’s a valid conversation to have, especially in sensitive sectors. But it’s also not a new one.
Based on our data, there are hundreds of other open source packages that depend on easyjson and potentially thousands of applications.
This library has been vetted
easyjson is a well-known, widely used JSON serialization library in the Go ecosystem. It’s used in projects like Kubernetes, where security and reliability are not taken lightly.
When concerns first surfaced in 2023, Kubernetes maintainers and CNCF reviewed the dependency in detail. The result? The project was deemed safe and was retained. The maintainers evaluated the risk, considered alternatives, and opted to keep easyjson because it was performant, stable, and had shown no signs of malicious behavior.
In other words, the review process worked as intended.
When we look at easyjson, we can see that overall it gets a solid Endor Score, and has some minor quality concerns.
Go has built-in supply chain protections
Unlike some other ecosystems, Go offers structural safeguards that reduce the risk of supply chain tampering. Modules are versioned and pinned by default through go.mod and go.sum. Once a dependency version is locked, it cannot be silently altered—even by the original maintainer.
This makes it extremely difficult for anyone to inject malicious updates unnoticed. Developers have full visibility into what version is used, and builds are fully reproducible. Any decision to upgrade must be explicit.
So even if a maintainer’s circumstances change, the risk to downstream users remains tightly controlled.
This is about provenance, not exploits
There are currently no known security issues in easyjson. The media narrative conflates national origin with active risk. That distinction matters. It’s important to evaluate the software supply chain, but that requires facts, not assumptions.
It’s also worth noting that much of the open source ecosystem depends on projects maintained outside the U.S. The developer behind core-js, a critical JavaScript utility, is based in Russia. The DeepSeek AI models hosted on HuggingFace are developed in China. Open source is global by nature, and security posture should be based on what the code does—not just where it came from.
Nevertheless if an organization has requirements to limit the origin of their open source components, they can use information available to try to limit such occurrences. For example, part of our evaluation criteria of open source is whether maintainers are associated with known entities or organizations.
In most cases though, when concerned about provenance and long term maintainability issues the answer is often to “vendor” the dependencies. By “vendoring” we mean that one can keep a local copy of the dependency and use the local copy rather than relying on upstream downloads. By vendoring the dependency an organization can review every update commit, guarantee that the build is local and under controls and avoid any supply chain risks. The Go ecosystem makes this very easy and it can be seen that lots of well maintained open source projects like Kubernetes actually vendor their dependencies for this reason.
If you decide to move on, make it an informed decision
Some organizations may still choose to avoid any package with geopolitical sensitivity. That’s understandable. The important thing is to approach that decision rationally, not reactively.
Start by determining where easyjson is used and whether it’s in active code paths. Reachability analysis can help teams identify whether a dependency is actually used in execution or simply present in the tree.
Next, run an upgrade impact analysis to see what would break if the dependency were removed or replaced. This gives development teams a clear view of the risk involved in migrating.
For those who want alternatives, tools like DroidGPT can recommend drop-in replacements like json-iterator, which is maintained by trusted contributors in the Go and Kubernetes communities. But beware that even json-iterator is a library mainly maintained in China, so you would be swapping a Russian package with a Chinese one, and it doesn’t seem inherently more secure than easyjson - getting us back to the discussion above.
Context matters more than clicks
The easyjson story reflects a broader trend: media coverage of open source risk often emphasizes the dramatic, while underplaying the safeguards built into mature ecosystems. In this case, the Go module system and the Kubernetes OSS review process are examples of robust, community-driven protection mechanisms doing their job.
There is no perfect solution to supply chain risk. But the right response is process, not panic.
With the right tools and context, teams can assess dependencies on their own terms—based on real usage, real risk, and real impact.
