On August 4, 2026, attackers took over the GitHub account of the developer who maintains keyv, a small, boring, wildly popular piece of software that gets downloaded around 127 million times a week. The same person maintains a handful of other utility libraries with names you have never heard of and download counts in the hundreds of millions a month. Within minutes, the attackers had pushed poisoned versions of all of them, carrying a credential-stealing worm that then used the stolen credentials to leap to other developers’ packages. It spread to more than four hundred of them before the day was out.

Here is the detail that matters, the one worth tattooing somewhere. Those poisoned releases were published with valid provenance, properly signed by the legitimate build pipeline. Every automated check that asks “is this signed by the real maintainer?” said yes. Because it was. The attacker was not forging a signature. The attacker was holding the key.

That single incident is not an outlier. It is the shape of the entire year. One security firm counted 37 separate npm supply-chain campaigns hitting 497 packages in just the first half of 2026, more than triple the total for all of 2025. Another report found that over 99 percent of open-source malware in 2025 rode in through the same channel. The attackers stopped trying to sneak junk past the scanners. They started stealing the keys to software the world already trusts, and then signing their malware with those keys.

A signature never meant what you think it meant

We have all been trained to look for the checkmark. Signed app, verified developer, valid certificate, green padlock. The signature is supposed to be the thing that lets you trust code you did not write.

But a signature does not, and never did, prove that software is safe. It proves exactly one thing: that whoever controls a particular key approved this exact bundle of code. That is all. If the key-holder is honest and uncompromised, the signature is meaningful. If the key-holder gets phished, or their build pipeline gets hijacked, or a disgruntled insider decides to have a bad day, then the signature becomes the opposite of protection. It becomes the mechanism that carries the attack, because your system trusts the key and the attacker now holds it.

The 2026 supply-chain wave is that failure mode at industrial scale. The trust was real. The keys were real. And that is precisely why the malware sailed straight through.

Now count the key-holders your phone trusts

Bring that back to the device in your pocket. Ask a simple question: how many different parties hold a key that your phone will trust without asking you?

On a stock phone, the answer is staggering, and you will never see most of them. Google holds keys. The manufacturer holds keys. Every app developer whose app you installed holds a key. And, as the npm story shows, every one of those developers is standing on a tower of other people’s code, their dependencies, and their dependencies’ dependencies, each maintained by someone else holding their own key, any one of whom can be compromised on any given Tuesday. Your phone is quietly extending trust to a cast of thousands you have never met and cannot vet, on the strength of signatures that only prove those thousands of keys have not yet been stolen.

And keys do get stolen, on phones specifically. In late 2022, the platform signing certificates belonging to several major Android manufacturers leaked. These are not ordinary app keys. An app signed with a platform certificate is trusted by the operating system as if it were part of the operating system, granted the deepest level of access on the device. Those leaked certificates were found being used to sign malware. Malware, wearing the manufacturer’s own signature, that the phone would treat as system-level and trusted. Same story as keyv, different registry: the malware was properly signed, and that was the whole problem.

This is the part of mobile security almost nobody thinks about, because the signing all happens invisibly, in the background, on your behalf, by default. You never chose those key-holders. You inherited them the moment you turned the phone on.

Holding your own keys changes the question

There is exactly one lever in this entire mess that you can actually control, and it is the keys on your own device.

When we build a phone to spec, we can build it with your own AVB and signing keys as the root of trust. From that moment on, the rule on that device is simple and absolute: nothing installs, and nothing updates, unless it is signed by you. Not by Google. Not by the manufacturer. Not by a maintainer three dependencies deep who got phished this morning. By you.

That does not magically make the global supply chain safe. It cannot. What it does is shrink the set of parties your device unconditionally trusts from “effectively the entire technology industry” down to “the people who hold your keys.” That is a difference of many orders of magnitude, and it eliminates an entire class of attack outright. The npm-style disaster, where a stranger with a stolen key pushes signed code straight onto machines around the world, simply cannot reach a device that only accepts your signature. There is no key of theirs for your phone to trust.

Pair that with the other things we have written about, a small, deliberate app loadout so there are fewer key-holders to begin with, and your own update infrastructure so the pipeline itself is yours, and you end up in control of the whole chain instead of a spectator to it. You are not hoping every vendor in the world stays uncompromised forever. You have removed your dependence on that hope.

The honest limits

We are not going to tell you this makes you invulnerable, because that would be exactly the kind of overclaim we do not make. If you choose to install something and sign it yourself, and that thing is malicious, your signature does not save you. Owning the keys is not a substitute for judgment about what you run.

What it removes is the terrifying, uncontrollable part: the attack you never touched, never chose, and could not have prevented, arriving through a trusted update because someone on the other side of the planet lost control of a key. In a year where that has happened dozens of times to packages the whole industry depends on, removing that class of risk from your own device is not a small thing. It is arguably the thing.

Who this is for

Anyone who cannot afford to have their device silently modified from the outside. Security teams who need to state, with certainty, that nothing runs on their fleet that they did not approve. Journalists, executives, and operators for whom a single compromised update is not an inconvenience but a catastrophe. Anyone who read about a properly-signed worm tearing through hundreds of trusted packages and thought, correctly, “my phone trusts a lot of keys I have never even seen.”

If you want your device’s root of trust to be yours instead of rented from everyone at once, that is exactly what building to spec gives you. Email hello@spicycorp.com, or book a call, and we will hand you the keys, literally.