When an Open Source Dependency Disappears: Lessons from the GetX Incident

Every engineering team has that moment, the one that makes you stop, refresh the page, and wonder if the problem is on your machine. 

For many Flutter developers, that moment arrived when one of the ecosystem’s most widely adopted packages suddenly disappeared from GitHub.

The repository behind GetX, a framework used by thousands of production applications for state management, navigation, and dependency injection, began returning a simple 404 Not Found. Within hours, developers were searching for answers, build pipelines were failing, and engineering teams everywhere were asking the same question:
What happens when a software that your application depends on simply vanishes?

The incident lasted longer than a broken link. It exposed a dependency risk that exists in almost every modern software stack, the one that often goes unnoticed until something goes wrong.

A missing Repository is more than an Inconvenience

Modern software is built on layers of open source dependencies. Every successful build, deployment, and release quietly assumes those dependencies will always be available, trustworthy, and maintained.

When that assumption breaks, the impact extends well beyond a missing package.

The GetX incident surfaced three risks that every engineering organisation should understand. 

Supply Chain Exposure

An abandoned package namespace can become an attractive target. If ownership changes hands, attackers may attempt to publish compromised versions that appear legitimate. Teams relying on automatic dependency updates could unknowingly introduce malicious code into production.

Broken Delivery Pipelines

Many CI/CD workflows retrieve dependencies during every build. When a package disappears, deployments fail immediately. Release schedules slip, hotfixes stall, and recovery quickly becomes a business problem rather than simply an engineering issue.

The Bus factor

Perhaps the most uncomfortable lesson was how much critical infrastructure depended on a single GitHub repository maintained by one individual. A library trusted by millions of developers effectively had a single point of failure.

None of these risks were unique to GetX. The incident simply made them impossible to ignore.

Treating the Incident Like a Security Event

Restoring the build was never the first priority. 

Before trusting the locally cached version of GetX, the engineering team approached the situation as a potential supply chain compromise.

The objective was straightforward, verify that the code, already running inside production environments was identical to the code developers believed they were using.

The audit focused on three areas commonly associated with malicious package tampering. 

Network Activity

The team reviewed the codebase for unexpected HTTP clients, socket connections, or outbound network requests that could communicate with external systems. 

Process execution

Every instance of **Process.run()**and similar APIs was inspected to ensure the package wasn’t capable of launching shell commands or executing scripts on a developers machine.

Concealed code

Large Base64 blobs, compressed payloads, and intentionally unreadable logic received additional scrutiny. These techniques can conceal malicious behaviour and deserve careful investigation whenever software provenance becomes uncertain. 

The review confirmed that the cached version matched the trusted release. The package itself remained clean. 

The repository, however, was no longer something the team could rely on.

Taking Ownership of a Critical Dependency

With the audit complete, the next objective was resilience. 

Rather than continuing to depend on a public repository whose future was uncertain, the team brought the dependency under its own control.

The recovery process followed three deliberate steps:

1. Extract the verified source code from the local cache.
2. Mirror the package into an internal Bitbucket repository managed by the engineering team. 
3. Redirect dependency resolution by updating pubspec.yml to reference the private Git repository instead of the public registry. 

YAML

dependencies:
  get:
    git:
      url: git@bitbucket.org:our org/getx mirrored.git
      ref: main

From that point forward, every build retrieved the package from infrastructure owned and maintained by the organization.

The immediate issue was resolved, and future releases were no longer dependent on the availability of a public repository.

The Bigger lesson is not just limited to GetX

Incidents like this tend to disappear from the news cycle within days.

The engineering lessons should not.

Open source software powers nearly every modern application, yet many organizations treat public package registries as permanent infrastructure. In reality, those ecosystems are maintained by individuals, volunteers, and small communities. Repositories change ownership. Maintainers step away. Projects are archived. Accounts disappear.

Planning for those possibilities is part of responsible software engineering. 

What Engineering Teams can do today

The GetX incident offers practical lessons that apply far beyond Flutter. 

• Regularly audit critical third party dependencies.
• Pin versions for production releases instead of relying on automatic upgrades.
• Maintain internal mirrors for packages that are essential to business operations.
• Verify package integrity before promoting dependencies into production.
• Identify libraries with a high bus factor and include them in operational risk assessments.

These practices require modest effort compared to the disruption caused by an unavailable or compromised dependency.

Open Source Thrives because of community

One encouraging aspect of the incident was the community response. 

Within hours, multiple developers had created mirrors and forks of the original repository. That collective effort prevented a temporary disruption from becoming a long term ecosystem failure.

Open source has always been strongest when responsibility is shared. Healthy communities create resilience that no single maintainer can provide. 

Building software means managing trust

The GetX repository eventually became available through community efforts, yet the incident left behind a valuable reminder.

Every external dependency represents a trust relationship. 

Engineering teams carefully review the code they write, test the infrastructure they operate, and monitor the systems they own. Third party packages deserve the same level of attention. 

Strong software delivery isn’t measured only by how quickly applications reach production. It’s also reflected in how well teams prepare for the unexpected. 

Because sometimes the next production incident doesn’t begin with a failed deployment.

It begins with a 404.