Most security advice for crypto users focuses on the surfaces you can see: your seed phrase, the links you click, the sites you sign into. Those matter. But there is a quieter risk underneath all of them — the software itself, and everything it was built from. A wallet can be written perfectly and still ship a backdoor, because modern applications are assembled from hundreds of third-party building blocks and a build pipeline that turns source code into the binary you install. Compromise any link in that chain and you compromise every user downstream.
This is the software supply chain, and attackers have learned it is one of the highest-leverage targets in crypto. This article explains what a supply-chain attack actually is, why wallets are such attractive targets, the defenses that hold up in practice, and what deterministic builds buy you — including how SSP applies all of this.
What a supply-chain attack is
A supply-chain attack does not break into the application directly. Instead, it compromises something the application trusts: a dependency it pulls in, a maintainer's account, or the build pipeline that assembles the final artifact. The malicious code rides in through a legitimate update, signed and delivered through normal channels, so it looks exactly like the software you meant to install.
That indirection is the whole point. Attacking one widely used library — or one build server — can reach thousands of downstream projects and millions of users at once. For a crypto wallet the payoff is direct: code running inside your wallet already has access to the moment that matters, when a transaction is signed and addresses are displayed. A single tampered dependency can swap a destination address or exfiltrate key material without ever touching you through phishing or weak seed-phrase hygiene. That is why this class of attack deserves a place in your mental model.
Two that hit close to home
Two real incidents show how this plays out — one aimed squarely at crypto, one that nearly hit the entire internet.
event-stream and the Copay wallet
In 2018, a popular npm package called event-stream was handed off to a new volunteer maintainer who offered to help. It was a routine, well-meaning-looking transfer of the kind that happens constantly in open source. The new maintainer then added a fresh dependency, flatmap-stream, that contained obfuscated malicious code.
The payload was unusually targeted. Rather than firing for everyone, it activated only inside a specific downstream project: the Copay Bitcoin wallet. There it was crafted to steal wallet seed material and funds from users of that application. Most developers who pulled in event-stream were never affected — the code knew exactly which victim it was looking for.
It is the canonical reminder that "I only installed one small library" is never the full story. You installed everything that library trusts, too.
The XZ Utils backdoor
The 2024 XZ Utils incident (CVE-2024-3094) was even more patient. XZ Utils is a compression library quietly present on most Linux systems. Over a period of years, an attacker built up trust as a helpful contributor, gradually earned maintainer responsibilities, and then slipped in a backdoor designed to interfere with OpenSSH — the software that secures remote logins to servers everywhere.
It was caught almost by accident, by an engineer who noticed a fraction-of-a-second delay. Had it shipped widely, it could have handed remote access to countless machines.
The lesson for crypto is sobering: the attack did not exploit a clever bug, it exploited the trust model of open source itself, playing a multi-year social-engineering game to become the person everyone relied on.
The defenses that actually work
No single control stops supply-chain attacks. What works is a stack of them, each narrowing the attacker's options:
- Pinned dependencies and lockfiles. Pinning exact versions and committing a lockfile means a build cannot silently pull a newer, tampered release. Updates become deliberate, reviewable events rather than automatic ones.
- Minimal dependencies. Every package you add is a party you trust. Fewer dependencies means a smaller attack surface and fewer maintainers who could be compromised.
- Dependency sandboxing. Tools like LavaMoat confine what each package can do at runtime, so a compromised dependency cannot freely reach the network or sensitive APIs.
- Code signing. Signed releases let users verify that a binary came from the real publisher and was not altered in transit.
- Third-party audits. Independent security firms review code and dependencies with an adversarial eye, catching what internal teams normalize.
- Reproducible, deterministic builds. The strongest structural defense, and the one worth understanding in detail.
Deterministic builds, explained
Normally, building software twice from the same source can produce two slightly different binaries — timestamps, file ordering, and build-machine details leak in. That variability is a problem, because it means you cannot tell a benign difference from a malicious one.
A deterministic (or reproducible) build removes that variability. Given the same source code, anyone, anywhere, on any machine, produces a byte-for-byte identical artifact. The implication is powerful: independent people can rebuild the wallet from its public source and confirm that the binary you downloaded matches, bit for bit, what the source produces. If an attacker tampered with the build pipeline or slipped something in afterward, the hashes will not match and the tampering is immediately visible.
This flips the trust model. You no longer have to take the publisher at their word; verification becomes something the whole community can perform and cross-check. The Reproducible Builds project documents the practice across the ecosystem, and frameworks like SLSA define levels of build-integrity guarantees you can hold a project to.
How SSP applies this
SSP treats the build pipeline as part of its threat model, not an afterthought. The wallet ships with a Dockerfile-first deterministic build — the same Docker-defined environment produces the same artifact every time — so a published release can be rebuilt from public source and checked, bit for bit, against what you downloaded. SSP has also undergone independent security review by Halborn, whose audits examine both the code and the dependencies it relies on.
There is one more layer specific to how SSP is built, and it matters here. SSP is a 2-of-2 multisig wallet: every transaction requires an independent approval from a second key, the SSP Key, on a separate device. Be precise about what that does and does not do. Deterministic builds and audits reduce the chance that a tampered build ships in the first place; they are the front line. But even in the worst case — a build that somehow slipped through — the second key is a separate approval surface that still has to sign off on every transaction.
It is not a magic shield, and it does not make a compromised build acceptable. It simply means a single tampered component on one device does not, by itself, move your funds. Defense in depth is the point.
What you can check yourself
You do not have to be a security engineer to benefit from any of this. A few habits go a long way:
- Download from official sources only. Get the wallet from its official site or store listing, never from a link in a message or a search ad. This is the same discipline covered in browser-extension hygiene.
- Prefer projects that publish deterministic builds and audits. A project that lets the community verify its releases — and pays for independent review — is telling you something about how it thinks.
- Verify signatures and hashes when they are offered. If a release ships a signature or checksum, take the minute to check it. Reproducible builds only protect you if someone actually does the comparing.
- Keep your overall opsec tight. Supply-chain defenses sit inside a bigger picture; run through your opsec checklist regularly so no single layer carries all the weight.
None of these require trust in a single party. That is exactly the property you want from self-custody software.
Keep going
A wallet is only as trustworthy as the chain that built it. The good news is that this is one of the few security problems with a clean, structural answer: deterministic builds plus independent audits turn "trust us" into "verify it yourself."
Keep building your defenses with phishing awareness, seed-phrase best practices, browser-extension hygiene, and a regular opsec checklist. Each one closes a door; together they are what self-custody security actually looks like.
