When a Web3 firm models its threat landscape, the exercise still tends to begin and end with the smart contract: reentrancy, oracle manipulation, flash loan exploits. That instinct is understandable given how much has been lost to contract-level bugs, but it leaves an entire category of risk unaddressed. The software supply chain, the dependencies, build tools, CI/CD pipelines, and signing systems that turn source code into a running application, has become one of the most consistently exploited attack surfaces across the industry, and it is almost entirely a matter of people and process rather than cryptography.
This is not a hypothetical concern. Nation-state actors and financially motivated criminal groups have both demonstrated, repeatedly and at scale, that compromising a build system or a widely used package is more efficient than attacking hardened production applications one at a time. A single poisoned dependency can reach thousands of downstream projects simultaneously. A single compromised CI/CD credential can grant direct access to production signing keys. Security4Web3 treats supply chain integrity as a core discipline within our DevSecOps for Web3 practice precisely because it sits at the intersection of engineering process, personnel trust, and technical control, the same People, Process, and Technology framework that underpins every other part of a mature security programme.
The Supply Chain Threat Landscape for Web3 Firms
Two incidents outside the crypto industry illustrate the scale of what a supply chain compromise can achieve, and both carry direct lessons for Web3 firms building and shipping software today.
3CX: A Build System Compromise, Not a Code Vulnerability
In March 2023, security researchers identified that the desktop application of 3CX, a widely used enterprise VoIP communications provider, had been trojanised and distributed to customers through the company's own legitimate update channel. The intrusion was attributed to the Lazarus Group, the North Korean state-sponsored threat actor also responsible for some of the largest crypto heists on record. Investigators traced the root cause back further than the 3CX build environment itself: an employee had installed a compromised open source trading application on a personal device, and that initial compromise cascaded through to control of 3CX's build infrastructure. The attackers did not need to find a flaw in 3CX's product code. They needed to find one weak link anywhere in the chain of trust that led to the signed, distributed binary, and they found it in a place far removed from the product itself.
XZ Utils: Two Years of Patient Social Engineering
The XZ Utils incident, discovered in April 2024, is arguably the more instructive case for security leaders because it shows that even a project subject to open, public scrutiny for years can be compromised through sustained trust-building rather than a single technical exploit. An account operating under a fabricated identity spent an extended period contributing legitimate work to the widely used XZ compression library, gradually earning maintainer status, before introducing a sophisticated backdoor into the project's build scripts that would have compromised SSH authentication on a huge number of Linux systems worldwide. It was discovered by chance, not by process, when an engineer at a different company noticed a minor performance anomaly during unrelated testing.
The XZ Utils incident proved that even widely scrutinised open source projects can be compromised through social engineering of maintainers rather than a technical flaw in the code itself. No amount of static analysis or code review catches an attacker who has patiently earned the keys to the building.
For Web3 firms, the lesson from both incidents is the same: supply chain risk is not confined to obviously suspicious packages or unmaintained libraries. It can live inside the most trusted, most widely used components in your stack, introduced by people who spent months or years establishing legitimacy before acting. Effective defence therefore has to combine technical controls with governance over who is trusted, how that trust is granted, and how it is periodically re-verified, which is exactly the discipline covered in our work on cyber threat intelligence for crypto-specific threat actors.
npm and PyPI Package Poisoning: The Crypto Developer Attack Surface
Crypto and Web3 developers are disproportionately targeted by malicious package campaigns on npm and PyPI, and the reasons are structural rather than coincidental. Web3 development stacks pull in a large number of small, single-purpose packages for wallet interaction, signature verification, RPC handling, and blockchain-specific utilities. Many of these packages are maintained by one or two individuals, updated infrequently, and rarely subjected to formal security review before being pulled into production builds.
Typosquatting and Dependency Confusion
The most common technique remains typosquatting: publishing a malicious package with a name deceptively similar to a popular legitimate one, betting that a developer will mistype an install command or copy a subtly incorrect name from an unreliable source. A closely related technique, dependency confusion, exploits how package managers resolve names across public and private registries, tricking a build system into pulling a public, attacker-controlled package instead of an organisation's intended internal one.
The event-stream Precedent
The industry's clearest early warning came in 2018, when a maintainer of the popular npm package event-stream handed control of the project to an unknown contributor who then added a malicious dependency specifically designed to target the Copay Bitcoin wallet, attempting to exfiltrate private keys and wallet credentials from users who had the wallet application built with the compromised code. The attack was narrowly scoped, patient, and specifically engineered for a crypto payout, a template that has been repeated many times since across npm and PyPI in campaigns that plant credential-stealing or wallet-draining payloads inside packages with crypto-adjacent names, or inside legitimate packages after a maintainer account takeover.
What This Means Operationally
Since 2023, security researchers have tracked repeated waves of npm and PyPI packages specifically engineered to harvest browser wallet extensions, seed phrases, and API keys from developer machines, often disguised as blockchain SDKs, trading bots, or testing utilities. The common thread across these campaigns is that they target the developer's workstation and local environment as much as the production build, meaning that endpoint controls, install-time scanning, and developer security awareness training all sit alongside dependency scanning as necessary controls, not optional extras.
CI/CD Compromise: How Attackers Target Your Deployment Pipeline
Modern Web3 firms ship code through automated pipelines that build, test, and deploy multiple times a day. That automation is a productivity gain and, unmanaged, a serious liability, because a CI/CD pipeline typically holds more standing privilege than any individual engineer: it can read source code, pull dependencies, access deployment credentials, and in poorly segmented environments, reach production signing systems directly.
Common Compromise Vectors
Attackers most frequently gain a foothold in CI/CD systems through compromised third-party actions or plugins in the pipeline definition itself, through stolen developer credentials with pipeline-triggering permissions, through poisoned dependencies that execute code during the build step (a technique known as build-time code execution), or through misconfigured self-hosted runners that expose broader network access than intended. Once inside, an attacker rarely needs to modify application logic directly. It is often sufficient to alter a build script, inject an additional step into a workflow file, or exfiltrate environment variables during a routine build.
Segmentation Is the Core Defence
The most effective structural defence is strict segmentation between build environments and anything that can sign or move funds. Build systems should never hold direct access to production signing keys or treasury wallets. Deployment artefacts should be cryptographically signed and verified before promotion to production, and that verification should happen outside the build system itself, on infrastructure the build pipeline cannot influence. Our detailed guidance on CI/CD pipeline security covers the specific configuration controls, including branch protection, mandatory code review, and workflow file restrictions, that reduce this attack surface in practice.
Secrets Leakage in CI/CD: Private Keys in GitHub Actions
Secrets management inside CI/CD platforms is one of the most consistently mishandled aspects of Web3 engineering, and the consequences of getting it wrong are immediate and severe, because the secrets in question are frequently deployment keys, API tokens with treasury access, or in poorly governed setups, private keys used for testnet or even mainnet operations.
Where Leakage Actually Happens
Secrets leak from CI/CD environments through several well-documented routes: hardcoded values committed to source control and later removed but still present in git history, secrets printed to build logs during debugging and never scrubbed, overly broad secret scoping that exposes a credential to every workflow and every contributor rather than the specific job that needs it, and fork-based pull request workflows that inadvertently expose secrets to untrusted, externally submitted code. Each of these is a process failure rather than a technology gap; the tools to prevent all four already exist on every major CI/CD platform.
Operational Controls That Work
The governing principle should be that no long-lived static secret with production impact is ever stored directly inside a CI/CD platform's variable store. Short-lived credentials issued through OIDC federation at the moment a job runs, scoped tightly to the specific action required and expiring immediately afterward, remove the majority of leakage risk because there is no persistent secret to steal in the first place. Where static secrets cannot be avoided, they should be rotated on a defined schedule, restricted to the minimum set of workflows that require them, and monitored for use outside expected patterns. Treasury-impacting operations should never be triggerable from a CI/CD pipeline at all; they belong behind the same dual-control and hardware-backed approval process as any other high-value transaction.
SBOM and Dependency Governance for Web3 Teams
A Software Bill of Materials gives a firm the ability to answer, within minutes rather than days, the question every CISO dreads hearing on the morning a new critical vulnerability is disclosed: are we affected? Without an accurate, continuously updated SBOM, that question requires manually auditing every repository, every environment, and every transitive dependency, a process that in a fast-moving engineering organisation is often incomplete before the vulnerability window has already been exploited elsewhere.
Building a Governance Programme, Not Just a Document
An SBOM produced once at a point in time has limited value. Dependency governance needs to be a continuous process: automated SBOM generation on every build, automated scanning of new and updated dependencies against known vulnerability databases before they are merged, and a defined policy for how quickly flagged issues must be remediated based on severity and exploitability. Equally important is a policy on introducing new dependencies in the first place: who can approve a new third-party package, what minimum criteria it must meet (active maintenance, reasonable adoption, no known history of compromise), and how that decision is documented so it can be reviewed later.
Pinning, Reproducibility, and Provenance
Dependency versions should be pinned rather than allowed to float to the latest release automatically, and updates should go through the same review process as any other code change rather than being applied silently by automated tooling. Where the ecosystem supports it, verifying package provenance, confirming that a package was actually built from the source code it claims to represent, closes a gap that pure version pinning does not address, since a compromised maintainer account can publish a malicious update under a legitimate, expected version number.
Protecting Signing Infrastructure in the Software Supply Chain
Code signing exists to give downstream consumers, whether that is an end user installing a wallet application or an internal system deploying an update, confidence that the software they are receiving is genuine and unmodified. That guarantee is only as strong as the protection around the signing infrastructure itself, and this is precisely where the 3CX compromise did its damage: the attackers gained access to systems capable of producing legitimately signed, trojanised binaries, which meant standard integrity checks provided no protection at all.
Isolating the Signing Function
Signing keys and the systems that use them should be isolated from general build infrastructure, ideally on hardware-backed, access-controlled systems that are invoked only at the final release stage rather than embedded throughout the development pipeline. Every signing event should be logged, attributable to a specific release and a specific authorised individual, and reviewed as part of a regular audit rather than trusted implicitly. Multi-party authorisation for signing releases, requiring more than one authorised individual to approve before a release is signed, adds a meaningful barrier against both external compromise and insider risk, mirroring the dual-control principles that already govern treasury operations in mature Web3 firms.
Third-Party Developer and Vendor Assessment
Every external developer, contracted auditor, integration partner, or infrastructure vendor with access to source code, build systems, or deployment credentials extends the supply chain boundary of the firm, whether or not that boundary is formally recognised. Supply chain risk assessment cannot stop at open source dependencies; it needs to extend to every third party with meaningful access to how software is built and shipped.
What a Working Assessment Programme Looks Like
A working programme evaluates prospective vendors and contractors against defined security criteria before access is granted, not after an incident raises the question retroactively. This includes reviewing their own security practices, verifying the scope of access requested against the scope actually required, and establishing contractual obligations around incident notification and code provenance. Access granted to third parties should be time-bound, scoped to the specific task, and revoked automatically at the end of an engagement rather than left active by default. Our broader framework for vendor risk management sets out the full assessment lifecycle, and it is worth noting that many of the most damaging supply chain compromises documented across the industry, including techniques consistent with Lazarus Group operational techniques, begin with a seemingly low-risk third-party relationship, a contractor, a recruiter, or a freelance developer, that is never assessed with the same rigour as a direct employee.
People Remain the Deciding Factor
Across every scenario in this article, from the 3CX build compromise to the XZ Utils backdoor to npm typosquatting campaigns, the technical mechanism of compromise varies but the underlying failure is consistent: a person, whether an employee, a maintainer, or a reviewer, extended trust that was not adequately verified. Technology can reduce the frequency and impact of these failures through segmentation, automated scanning, and short-lived credentials, but it cannot substitute for a security culture in which engineers are trained to recognise social engineering, contributor vetting is treated as a genuine control rather than a formality, and every stage of the software supply chain assumes that trust must be earned and periodically re-verified rather than granted once and forgotten.
Frequently Asked Questions
What is a software supply chain attack in the context of Web3?
A software supply chain attack compromises the tools, dependencies, build systems, or distribution channels used to create and deploy software, rather than attacking the target application directly. In Web3, this means poisoned npm or PyPI packages, compromised CI/CD pipelines, or tampered build artefacts that inject malicious code into wallets, dApps, or infrastructure before it ever reaches production.
Why are Web3 firms a particularly attractive target for supply chain attacks?
Web3 firms hold or move liquid, irreversible value and frequently rely on fast-moving open source dependencies with smaller maintainer pools than mainstream software ecosystems. A single compromised package or pipeline can lead directly to stolen private keys or drained treasuries, giving attackers a much faster and larger payout than in traditional enterprise environments.
What is an SBOM and why does it matter for supply chain security?
A Software Bill of Materials is a structured inventory of every component, library, and dependency used to build a piece of software, including transitive dependencies. It matters because it allows a firm to identify immediately whether it is exposed to a newly disclosed vulnerability or malicious package, rather than manually auditing every codebase after an incident is announced.
How did the XZ Utils backdoor work and what does it teach Web3 firms?
An account using a fabricated identity spent roughly two years building trust as a co-maintainer of the XZ Utils compression library before inserting a backdoor into the build process that would have compromised SSH access on affected Linux systems. It teaches Web3 firms that maintainer trust and contributor vetting are security controls in their own right, not just code review.
What is the single most effective control against CI/CD compromise?
No single control is sufficient, but enforcing short-lived, scoped credentials issued via OIDC federation rather than long-lived static secrets stored in CI/CD variables removes the most commonly exploited weakness: a leaked or overly broad secret that grants an attacker persistent access to production systems.