The largest theft this industry has ever seen did not break a smart contract, a key management system, a multisig, or a hardware wallet. In February 2025, attackers took roughly $1.5 billion from Bybit by compromising a developer workstation at its wallet provider and altering the JavaScript that the provider's interface served to one specific customer. The signers saw a routine transfer on screen. Their hardware wallets signed something else.
Every custody control in that setup worked as designed. The cold wallet was cold and the multisig required several humans. The failure sat upstream, in code that nobody on the victim's side wrote, reviewed, or could see changing.
That is the supply chain problem in a single incident. Most crypto organizations I assess still file it under engineering hygiene. It belongs under treasury risk.
Why crypto gets hit harder
Supply chain attacks hit every sector. When a poisoned package lands in a retailer, the attacker gets credentials and then needs weeks of work to turn that access into money. In a crypto organization, the distance between code execution and irreversible loss can be one transaction. There is no chargeback, no fraud desk, and no correspondent bank to call.
The architecture makes it worse. dApp front ends and wallet interfaces are JavaScript applications built from hundreds of npm dependencies, and that JavaScript constructs the transaction the user signs. Whoever controls it controls what gets signed. Developer laptops and build pipelines routinely hold deployer keys, RPC credentials, exchange API keys, and cloud roles.
The adversary is also not a teenager with a typosquat. State-backed groups, North Korean operators above all, have spent years perfecting this. Their fake recruiter campaigns hand developers a "coding test" repository that quietly pulls malicious npm packages. The interview is the intrusion.
Registry poisoning: what it looks like now
Typosquatting is no longer the main threat model. It still exists: PyPI sees a steady stream of packages imitating Bitcoin and Solana libraries whose only purpose is to exfiltrate private keys. The serious incidents of the last three years were different. They were compromises of legitimate, trusted packages through their maintainers.
- Ledger Connect Kit, December 2023. A former employee was phished while their npm access was still live. Malicious versions shipped a wallet drainer to every dApp loading the library. The window was about five hours and the loss about $600,000. The phishing email was ordinary. The offboarding gap is what made it work.
- @solana/web3.js, December 2024. An account with publish rights was phished, and two versions went out that exfiltrated private keys. The victims were backends and bots that handled keys directly and happened to update during a window of a few hours.
- chalk, debug, and related packages, September 2025. The maintainer received a convincing fake npm support email. Together these packages account for more than two billion weekly downloads. With the entire JavaScript ecosystem at their disposal, the attackers deployed a crypto clipper. It hooked the browser's network and wallet APIs and swapped destination addresses for look-alikes. That choice tells you where attackers think the money is. The take was small because the community caught it within hours, and I would not build a risk model on that kind of luck.
- Shai-Hulud, September 2025. This was a self-propagating worm that harvested tokens from each infected machine and used them to publish infected versions of the victim's own packages. A second wave in November moved execution to the preinstall phase and reached tens of thousands of repositories, including packages maintained by well-known crypto projects.
Python deserves the same attention and rarely gets it. Crypto organizations run Python in quant research, trading bots, data pipelines, operations scripts, and now AI tooling. Those environments often hold exchange API keys with trading or withdrawal permissions, and they get a fraction of the scrutiny applied to the production application.
AI coding assistants add a new layer. Models hallucinate package names, and attackers register them. In the Nx compromise of August 2025, the malware invoked AI command line tools already installed on developer machines to help it hunt for wallets and secrets. The tooling we adopt to move faster is now part of the attack surface.
CI/CD: the most privileged user you have
Your pipeline holds cloud credentials, registry publish tokens, and deployment keys, and it executes third-party code on every commit. It also has no MFA, no security awareness training, and nobody watching its behavior.
- tj-actions/changed-files, March 2025. Attackers repointed the action's version tags to a malicious commit, so every repository referencing it by tag ran attacker code that dumped secrets into build logs. More than 23,000 repositories were exposed. Investigators traced the chain back through another compromised action. The original target appears to have been an open source project belonging to a major crypto exchange. The rest of the ecosystem was collateral damage.
- Ultralytics, December 2024. A crafted branch name injected commands into a workflow, poisoned the build cache, and caused the project's official release pipeline to publish a cryptominer to PyPI. The source repository stayed clean. A code audit would have found nothing, because the code was never the problem.
The patterns I keep finding in assessments are consistent:
- actions pinned by mutable tag
- long-lived cloud keys stored as repository secrets
- pull_request_target workflows that run fork code with access to secrets
- self-hosted runners that persist between jobs and are shared across projects
- a deployer private key sitting in CI as an environment variable
One contrast should bother any board. The same organization that requires four executives to approve a treasury movement lets a single merged pull request change the JavaScript that tells those executives what they are approving.
What I tell CISOs to do
- Treat the build and release path as part of the custody perimeter. Threat model it with the same rigor you apply to a key ceremony. If a system can change what a signer sees or what a contract deploys, it is in scope.
- Make installs deterministic.
- Commit lockfiles, use npm ci, and use pip with hash checking.
- Route everything through an internal registry proxy.
- Disable install scripts by default.
- Add a cooldown on new versions. Malicious releases are typically detected within hours or days, so a seven-day quarantine on fresh versions would have sidestepped nearly every incident above.
- Harden the pipeline.
- Pin actions to full commit SHAs and restrict which actions are allowed.
- Set the default token to read-only.
- Replace stored cloud keys with short-lived OIDC credentials.
- Use ephemeral runners.
- Ban workflows that check out untrusted code with secrets in scope.
- Fix publishing. Use trusted publishing through OIDC on npm and PyPI so there is no long-lived token to steal. Require hardware security keys for anyone with publish rights. Review those rights at every offboarding.
- Protect front end integrity. Production deploys of anything that builds transactions need multi-person approval. Monitor the bundle you serve against the bundle you built. Use subresource integrity and a strict content security policy for third-party scripts.
- Assume the interface lies. Signers should verify decoded transaction data through an independent path, on a separate device, with simulation. Enforce destination allowlists and policy rules in the custody platform itself, where a compromised front end cannot reach them.
- Separate developer workstations from signing devices, with no exceptions. Keep secrets out of dotfiles and shell history. Treat any unsolicited repository as hostile and run coding tests in disposable virtual machines.
- Rehearse the bad day. When a package you depend on is announced as compromised, you should know within an hour whether you use it, which versions, where it ran, and which secrets were reachable. An accurate SBOM turns that into a query. Pair it with a secret rotation runbook you have actually run.
For regulated entities there is also a compliance angle. DORA's technical standards already expect financial entities to track third-party libraries, open source included, as part of ICT risk management. Your dependency tree is ICT third-party risk whether or not your register of providers says so, and supervisors will get there.
The uncomfortable conclusion
We have spent a decade hardening keys with HSMs, MPC, quorum policies, and air gaps, and that work was necessary. The attackers noticed and moved upstream. They no longer need your keys if they can write the code that uses them.
Your custody architecture is only as strong as your least-reviewed dependency and your most over-privileged pipeline. Halborn helps you find out which ones those are before someone else does.