Web3 infrastructure is software. It consists of code repositories, build systems, dependencies, container images, deployment scripts, and monitoring stacks. Supply chain attacks target that ecosystem. A compromised package, build pipeline, or artefact registry can undermine even well written contracts and protocols.
Supply chain risk in a web3 context
Crypto infrastructure has specific traits that make supply chain security important:
- Open source dependencies are common, including libraries that handle signing, encoding, and core protocol logic
- Many teams use multiple programming languages and package ecosystems simultaneously
- Cloud native architectures depend on container images pulled from public registries
- CI systems often have permission to deploy contract code, update front ends, and modify configuration
If any of the links in that chain are subverted, an attacker can change what you deploy without touching your public repositories.
Where supply chains tend to be weak
Source control
- Developer accounts without hardware backed MFA
- Weak branch protections that allow force pushes or direct commits to main
- Lack of signed commits or tags for releases
- Access tokens issued to services but not scoped or rotated
Dependencies
- Unpinned dependencies where specifying only a major version lets upstream changes alter behaviour
- Packages that execute installation scripts without close review
- Transitive dependencies that bring in vulnerable or malicious code without being directly visible in the top level manifest
CI and build systems
- Shared runners building both trusted and untrusted code
- CI jobs with broad cloud privileges such as full admin access to an account
- Secrets stored directly in CI configuration rather than in dedicated managers
- Lack of separation between build networks and the open internet
Artefact and container registries
- No signatures or attestations for images and binaries
- Public registries used as the source of truth for deployment
- No retention or traceability for historic artefacts, making forensic work harder
Deployment
- Deployments pulling “latest” images or unpinned artefacts
- Manual steps where commands can be modified on the fly
- No verification that the artefact being deployed matches what was tested
Principles for stronger supply chain security
Provenance and traceability
Every deployed artefact should be traceable back to:
- A specific source commit
- A specific set of dependencies
- A specific CI job and environment
You can approach this by:
- Embedding commit hashes and build identifiers into artefacts
- Using build tools that generate provenance metadata
- Storing SBOMs and build metadata alongside binaries and images
Strong separation between stages
Development, build, and production should not blur into each other.
- Build systems should not have unrestricted admin rights in production environments
- Human operators should use well defined pathways, such as deployment pipelines, rather than ad hoc commands
- Network access from build systems should be carefully scoped to what is needed
Security as part of the pipeline
Automated checks should be standard.
- Static analysis for common coding errors
- Software composition analysis to track dependency vulnerabilities
- Container scanning before publishing images
- Optional dynamic scans and integration tests against staging
Checks that fail at a high severity level should block promotion, with explicit waivers if an exception is required.
Secret handling
Secrets used by build and deployment systems should:
- Be stored in dedicated secret managers
- Use short lived tokens where possible
- Be scoped to specific tasks
- Be rotated on a schedule and after incidents
Repositories and images should be scanned for accidental inclusion of secrets, followed by remediation and rotation.
DevSecOps as an operating model for web3
DevSecOps in this context means:
- Expressing security expectations as configuration and code in repositories and pipelines
- Making sure developers see security feedback early and often, rather than at the end of projects
- Giving operations and security teams visibility into what is built, where it runs, and how it is configured
- Reducing reliance on manual checks and one off approvals
For web3 infrastructure, it also means integrating contract deployment and protocol upgrades into the same controlled processes that handle back end and front end artefacts.
Action plan for software supply chain security
- Map the journey from code commit to production for each major component: backends, frontends, contracts, and supporting services.
- Introduce branch protections, commit signing, and hardware backed MFA for all source control users.
- Lock and pin dependencies and start generating SBOMs for services that matter.
- Harden CI by using scoped service accounts, ephemeral runners, and secret managers.
- Adopt artefact signing or attestation and verify signatures at deployment.
- Separate environments and enforce that only approved, traceable artefacts can reach production.
- Integrate security checks into pipelines and monitor their outcomes as part of normal operations.
How Spearbit audits supply chain security and DevSecOps
In supply chain focused audits, Spearbit:
- Reviews repository configuration, access controls, and branching strategies
- Examines CI pipelines, runner configuration, and secret handling for escalation paths
- Looks at how artefacts are built, stored, signed or attested, and deployed
- Evaluates how contract deployments fit into this picture and whether they are governed by the same level of control
- Provides stepwise recommendations that improve provenance, reduce exposure, and make the pipeline auditable
For any protocol or infrastructure provider that expects scrutiny from partners or regulators, supply chain security is a key part of the story. Contact us to scope your next successful security engagement.