Security in Web3 development is not simply a matter of running a smart contract audit before launch. That framing, while common, reflects a deeply flawed understanding of where vulnerabilities originate and when they are most expensive to fix. By the time a security audit occurs, the code has been written, reviewed, tested, and often deployed to a staging environment. The architectural decisions have been made. The dependencies have been chosen. Many of the highest-risk decisions have already been locked in.
DevSecOps is the discipline of embedding security controls throughout the software development lifecycle rather than appending them at the end. For Web3 teams, this means security is present at the pre-commit stage, in the CI/CD pipeline, in dependency management, in deployment workflows, and in how secrets are handled by every person on the team. It is not a tooling decision. It is an organisational and process decision that requires commitment from engineering leadership and active participation from every developer.
This guide is written for CISOs, security-conscious engineering leads, and head-of-engineering roles at Web3 firms who are building or maturing a DevSecOps practice. It covers the full scope of the discipline: from pre-commit controls through to deployment governance and security metrics, within the unique context of Web3 development.
What Is DevSecOps
The term DevSecOps emerged from the DevOps movement as it became clear that the speed of continuous integration and continuous delivery had outpaced traditional security review processes. In a CI/CD environment where code is merged and deployed multiple times per day, a security review cycle that takes weeks creates an impossible bottleneck. DevSecOps resolves this tension by automating security checks and embedding them into the development workflow so that they run at the speed of the pipeline.
Shift-Left Security
Shift-left is the core principle of DevSecOps. The "shift" refers to moving security activities to the left on a timeline of the software development lifecycle: earlier, closer to the point of code creation. The logic is straightforward and well-supported by industry data. A vulnerability identified at code-writing time costs a fraction of what the same vulnerability costs to fix after deployment. In Web3, where deployed smart contracts often cannot be patched without a complex upgrade process, and where vulnerabilities can be exploited within hours of a mainnet deployment, the cost differential is even more severe.
Shift-left does not mean that later-stage activities such as penetration testing or formal security audits become unnecessary. It means that by the time code reaches those stages, the low-hanging fruit has already been removed, allowing reviewers to focus on architectural and logic-level issues rather than basic coding errors that automated tools could have caught earlier.
DevOps vs DevSecOps vs SecDevOps
The distinction between these terms is worth clarifying. DevOps refers to the cultural and technical practices of integrating development and operations to enable faster, more reliable software delivery. DevSecOps adds security as a shared responsibility integrated throughout the DevOps pipeline. SecDevOps is a less common term that emphasises security-led development, where security requirements drive development decisions from the outset rather than being integrated into an existing DevOps process. For most Web3 teams, DevSecOps is the applicable framing: security embedded in, rather than leading, the development process.
Why Web3 Teams Cannot Afford to Bolt Security On
Web3 development has several characteristics that make post-development security bolting-on particularly dangerous. Smart contracts are immutable once deployed without an upgrade mechanism, meaning that a vulnerability identified post-deployment may require a full contract migration with all the user communication, liquidity migration, and governance overhead that entails. Assets controlled by vulnerable contracts are at immediate risk once a vulnerability is public or exploited. And the Web3 ecosystem's transparency, where all contract code is publicly verifiable on-chain, means that an attacker can identify vulnerability patterns in deployed bytecode and exploit them without ever having access to the source code.
The Web3 DevSecOps Challenge
Web3 development presents a unique set of challenges for DevSecOps implementation that differ meaningfully from those in traditional software development.
Immutable Deployments
In traditional software, a vulnerability can be patched and redeployed. In Web3, deployed smart contracts are permanent entries on a public blockchain. Upgrade mechanisms such as proxy patterns introduce their own security considerations, and not all protocols are designed to be upgradeable. The consequence is that the pre-deployment security bar must be substantially higher than in environments where fast patching is possible.
Irreversible Asset Losses
Blockchain transactions are final. A single vulnerability in a contract or deployment pipeline that results in an unauthorised transfer cannot be reversed. Regulatory regimes are still developing frameworks for victim recovery, but in practice, the vast majority of funds lost through smart contract exploits or compromised deployment pipelines are never recovered. This asymmetry between the cost of a breach and the reversibility of its impact makes preventive security investment an unambiguous priority.
Pseudonymous Contributors and Open-Source Risk
Many Web3 projects include open-source contributions from pseudonymous developers whose identities cannot be verified through standard background check processes. While the open-source model provides transparency benefits, it also creates insider threat and supply chain risks that are difficult to manage through traditional personnel security controls. Code review processes must be robust enough to catch malicious contributions, and contributor access to sensitive repositories should be restricted to verified, credentialled team members.
Compressed Audit Timelines
Market pressure in crypto frequently drives compressed development and audit timelines. Projects launch to capture market windows, protocol upgrades are pushed to meet roadmap commitments, and security reviews are sometimes shortened or skipped when deadlines approach. A mature DevSecOps process reduces the risk of this pressure resulting in a security incident by ensuring that a baseline level of security checking has occurred continuously throughout development, so that the final audit is genuinely reviewing what remains rather than compensating for absent earlier-stage controls.
Pre-Commit Security Controls
Pre-commit controls are security checks that execute on a developer's local machine before a commit is accepted by Git. They are the earliest possible intervention point in the development lifecycle and are particularly valuable for preventing secrets from entering version control.
Secret Scanning with Git Hooks
The three most widely used open-source tools for pre-commit secret scanning are Gitleaks, detect-secrets, and TruffleHog. Each operates by scanning staged changes for patterns that match known secret formats: private keys, API tokens, AWS credential strings, JWT secrets, and many others.
- Gitleaks is fast, configurable, and supports custom rules via a TOML configuration file. It integrates cleanly with the pre-commit framework and is well-maintained. It can scan entire repository histories as well as staged changes, which is useful for identifying historical exposures.
- detect-secrets by Yelp uses entropy analysis alongside pattern matching to identify secrets, which can reduce false negatives at the cost of some false positives. It maintains a baseline file that records known false positives, allowing the baseline to be committed to the repository and shared across the team.
- TruffleHog performs deep entropy and pattern scanning and includes integrations with GitHub Actions and other CI systems. It is particularly effective for high-confidence detection of long-lived credential strings.
All three tools should be configured as pre-commit hooks using the pre-commit framework, which manages hook installation and ensures consistent configuration across developer machines. The configuration should be committed to the repository so that new developers have hooks installed automatically when they clone the project.
SAST Tools in the Editor
Integrated development environment plugins can surface security issues directly in the developer's editor as code is written, providing the earliest possible feedback loop. Slither has an VS Code extension. Semgrep integrates with most major IDEs via the Language Server Protocol. These integrations allow developers to see vulnerability warnings before they even commit, further shifting security left.
Branch Protection and Peer Review
Branch protection rules should require at least one reviewer approval before any merge to main or production branches. Security-focused review checklists should be embedded in pull request templates, covering items such as: are any secrets visible in the diff, do new dependencies have known vulnerabilities, are access control checks present on all privileged functions, and are there adequate test cases for the new logic.
CI/CD Pipeline Security
The CI/CD pipeline is the bridge between developer workstations and production deployments. A compromised pipeline can introduce malicious code, exfiltrate secrets, or deploy to production without appropriate authorisation. Securing the pipeline is therefore as critical as securing the code that runs through it.
"A compromised CI/CD pipeline is a direct path to production. In Web3, that means a path to deployed contracts, cloud key stores, and live infrastructure. The pipeline deserves the same threat modelling as any other critical system."
GitHub Actions and GitLab CI Hardening
For GitHub Actions, critical hardening steps include: pinning action versions to specific commit SHAs rather than mutable tags, using OIDC-based cloud authentication instead of stored credentials, restricting the permissions of the GITHUB_TOKEN to only what each workflow requires, and enabling required status checks so that workflows cannot be bypassed. Workflow files should be treated as security-sensitive code and reviewed carefully on every change, since a malicious modification to a workflow file can exfiltrate all secrets accessible to that pipeline.
For GitLab CI, similar principles apply: use protected variables for secrets, restrict which branches and tags can trigger protected pipelines, and use environment-scoped variables to prevent development pipeline jobs from accessing production secrets.
Secrets Management in Pipelines
Secrets in CI/CD systems should be stored in the platform's secrets store with the minimum permissions required for each specific job. Secrets should never appear in pipeline logs; mask all secrets in CI configurations and test log outputs regularly to ensure secrets are not leaking. Where possible, use OIDC federation to obtain short-lived cloud credentials for each pipeline run rather than storing long-lived credentials as secrets. Our companion post on cloud security for crypto firms covers the cloud-side configuration for OIDC pipeline authentication in detail.
Dependency Pinning and SBOM Generation
All dependencies in the build pipeline should be pinned to specific versions with hash verification. In JavaScript projects, the package-lock.json or yarn.lock file should be committed and checked into version control; builds should use the lockfile rather than resolving dependencies fresh on each run. For container images, base images should be referenced by digest rather than mutable tags. Software Bill of Materials (SBOM) generation should be integrated into the build process to produce a machine-readable inventory of all dependencies in each release artefact.
Container Image Scanning
Container images used in deployment should be scanned for known vulnerabilities using tools such as Trivy, Grype, or Snyk Container before being pushed to a registry or used in a deployment. Scanning should block deployment of images with critical or high-severity vulnerabilities unless an explicit exception has been documented and approved. Base images should be updated regularly and rebuilt to incorporate upstream security patches.
Dependency and Supply Chain Security
The software supply chain is one of the most significant and underappreciated security risks in Web3 development. Web3 projects frequently depend on dozens or hundreds of open-source packages, each of which represents a potential entry point for a supply chain attack.
The solana-web3.js Supply Chain Attack
The December 2024 compromise of the @solana/web3.js npm package is the most instructive supply chain incident in Web3 history to date. Attackers obtained the npm publishing credentials of a package maintainer and published malicious versions 1.95.6 and 1.95.7 that contained code designed to exfiltrate private keys from affected applications. The package had millions of weekly downloads and was a dependency in a large proportion of Solana ecosystem projects.
Projects that had pinned their dependency versions in their lockfiles to an earlier version were unaffected. Projects that used floating version ranges such as ^1.95.5, which would automatically resolve to any compatible newer version, were exposed during the window the malicious versions were live. The attack demonstrated with clarity that dependency pinning is not optional, and that active monitoring of dependency update feeds is essential for detecting malicious releases rapidly.
npm, Cargo, and Foundry Dependency Risks
Each package ecosystem has specific risks. npm is the highest-risk ecosystem for Web3 frontend and tooling projects due to its flat dependency graph and the ease of publishing new packages. Cargo (Rust) has a stronger security model due to crate immutability after publication and stronger type system guarantees. Foundry's dependency management via git submodules reduces npm-style supply chain risks but introduces risks around submodule pointer manipulation in compromised upstream repositories.
Software Composition Analysis
Software Composition Analysis (SCA) tools scan project dependencies against databases of known vulnerabilities. Snyk, Dependabot, OWASP Dependency-Check, and GitHub's built-in dependency review all provide SCA capabilities. SCA should run on every pull request to flag newly introduced vulnerabilities, and dependency update PRs should be reviewed promptly rather than accumulating. Automated tools such as Dependabot or Renovate can create pull requests for dependency updates, but these should be reviewed carefully, particularly for indirect transitive dependencies where the impact of an update is less obvious.
For a broader view of vulnerability management beyond the pipeline, see our guide on vulnerability management for Web3 firms.
Static Analysis and Automated Testing
Static analysis is the automated examination of source code for vulnerability patterns without executing the code. For Web3 development teams, SAST is a non-negotiable component of the security pipeline.
Solidity SAST Tools
Slither, developed by Trail of Bits, is the industry standard for Solidity static analysis. It detects over 100 vulnerability patterns including reentrancy, integer overflow and underflow, unchecked external call return values, dangerous delegatecall patterns, and access control weaknesses. Slither produces machine-readable output that integrates with CI pipelines and can be configured to fail builds on high-severity findings.
Aderyn, developed by Cyfrin, is a newer Rust-based Solidity analyser that offers fast execution and clean CI integration. It complements Slither rather than replacing it, with a different set of detectors that may surface issues Slither misses. Running both tools in parallel in the CI pipeline provides broader coverage at minimal additional cost.
Backend and API SAST
For Python, JavaScript, TypeScript, Go, and Rust backend code, Semgrep with appropriate rulesets provides effective static analysis. Semgrep's rule language is expressive enough to write custom rules for Web3-specific patterns, such as detecting uses of insecure random number generation in contexts that affect contract interactions, or flagging direct database queries that could be vulnerable to injection. Community rulesets covering common vulnerability patterns are available through the Semgrep Registry.
Fuzz Testing and Property-Based Testing
Unit tests verify that code behaves correctly for a set of known inputs. Fuzz testing and property-based testing verify that code behaves correctly across a broad, automatically generated range of inputs, including edge cases that a developer might not anticipate. For Solidity, Foundry's built-in fuzzer and Echidna provide property-based testing capabilities that are particularly effective at identifying integer boundary conditions and state machine violations. These should be integrated into the CI pipeline alongside unit tests, with coverage requirements that include fuzz testing runs.
Secret Management in Web3 Development
Secret management is one of the highest-stakes aspects of Web3 DevSecOps. Secrets in Web3 development include private keys for hot wallets and deployer addresses, API keys for third-party services, cloud credentials, database connection strings, and authentication tokens. Each of these, if exposed, can result in direct asset loss or account compromise.
Why Environment Variables Are Not Enough
Environment variables are a ubiquitous but deeply flawed secrets management approach. Variables set in shell profiles or .env files are easily committed to version control. They appear in process listings on shared systems. They are frequently logged by application frameworks during startup or error conditions. They accumulate on developer machines as projects come and go, creating a growing pool of stale credentials that may never be rotated.
A proper secrets management approach uses a centralised secrets store. HashiCorp Vault provides a full-featured, open-source secrets management platform that supports dynamic secrets, fine-grained access policies, and comprehensive audit logging. AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault are cloud-native alternatives with similar capabilities and native integration with their respective cloud IAM systems. Applications retrieve secrets at runtime through authenticated API calls, not from environment variables or configuration files.
Responding to a Secret Exposed in Git History
When a secret is discovered in Git history, the response must be immediate and treat the secret as fully compromised from the moment it was first committed. The steps are: rotate and revoke the secret immediately (before removing it from history), use git filter-repo to remove the secret from all commits in the repository history, force-push the rewritten history, notify all affected service providers, and audit access logs for the affected credential to determine whether it was accessed by an attacker. The widespread misconception that deleting a file containing a secret from a repository is sufficient is dangerous: the secret remains in Git history and is accessible to anyone who clones the repository.
Key Rotation Procedures
Secrets should have defined rotation schedules. Long-lived API keys should be rotated at least annually, or more frequently for high-value services. Cloud service account keys should be rotated every 90 days. Deployer wallet private keys should be rotated after any potential exposure event. Rotation procedures should be documented, tested, and where possible automated through secrets manager rotation policies. For privileged access management around these credentials, see our guide on privileged access management for crypto firms.
Deployment Security and Change Management
Deployment is the highest-risk moment in the software development lifecycle for Web3 teams. A compromised or poorly controlled deployment process can result in malicious code reaching production, unauthorised contract upgrades, or credential exposure during the deployment execution. Robust deployment security requires both technical controls and organisational process.
Deployment Approval Workflows
All production deployments should require explicit human approval before execution. This is particularly critical for smart contract deployments and upgrades, where the action is irreversible once executed on-chain. Deployment approval workflows should be enforced at the CI/CD platform level, not just through social convention. GitHub Environments with required reviewers, GitLab deployment approvals, and similar features provide platform-level enforcement that cannot be bypassed by a developer with direct repository access.
For infrastructure changes in cloud environments, approval workflows should integrate with the change management process and require sign-off from a second party before any change to production security controls, IAM policies, or key management configurations. Our post on cloud security for crypto firms covers the cloud infrastructure side of this in detail.
Multi-Sig for Contract Deployments
Smart contract deployments and upgrades in production should be executed through a multisig wallet such as Gnosis Safe rather than through a single developer's wallet. The CI/CD pipeline should generate the deployment transaction and propose it to the multisig, but the actual execution should require M-of-N signatures from key holders who can review the transaction details before signing. This ensures that a single compromised CI credential or developer account cannot unilaterally deploy malicious code to a live protocol.
Timelock Controls
For protocol contracts with upgrade or parameter change capabilities, timelock controllers add a mandatory delay between a change being proposed and it being executable. This delay provides a window during which the community, security researchers, or internal teams can review the proposed change and raise concerns before it takes effect. Standard timelock periods range from 24 hours for minor parameter changes to 72 hours or more for significant upgrades. Timelocks are a social contract enforcement mechanism, not a substitute for access controls.
Post-Deployment Verification
Every production deployment should be followed by an automated verification step that confirms the deployed artefact matches the expected build output. For smart contracts, this means verifying the deployed bytecode against the compiled output of the source code. For backend services, it means confirming the running container image digest matches the scanned and approved image. Post-deployment verification should be automated and its output logged as part of the deployment record.
For a red team and blue team perspective on testing your deployment pipeline and production defences, see our post on red team and blue team operations for crypto firms.
Security Metrics for DevSecOps Teams
What gets measured gets managed. DevSecOps programmes that lack defined security metrics cannot demonstrate improvement over time, cannot identify where the programme is failing, and cannot make the case to leadership for continued investment. Security metrics for DevSecOps teams should be specific, measurable, and tied to outcomes that matter for the organisation's risk posture.
Mean Time to Remediate (MTTR)
MTTR measures the average time between a vulnerability being identified and it being remediated. For critical vulnerabilities, MTTR should be measured in hours or days. For high-severity findings, the target should be within two weeks. Tracking MTTR over time reveals whether the team is reducing its vulnerability backlog or accumulating technical security debt. A rising MTTR trend is an early warning signal of a DevSecOps programme that is identifying issues faster than it is fixing them.
Vulnerability Introduction Rate
The vulnerability introduction rate measures how many new vulnerabilities are being introduced per unit of code committed or per sprint. A declining rate indicates that developer security training, pre-commit controls, and SAST integration are becoming more effective at preventing vulnerabilities from entering the codebase. A stable or rising rate suggests that the preventive controls are insufficient and that more investment in developer education or automated tooling is needed.
Secret Exposure Incidents
The number of secret exposure events per quarter should trend towards zero as pre-commit scanning, developer training, and secrets management practices mature. Each secret exposure event should be treated as a process failure and reviewed in a blameless post-incident analysis to identify the control that failed and how to prevent recurrence.
Dependency Vulnerability Density
Dependency vulnerability density measures the number of known vulnerabilities per thousand lines of dependency code. This metric captures the health of the dependency supply chain and the promptness with which the team addresses dependency updates. High dependency vulnerability density combined with low MTTR indicates a backlog of unaddressed dependency vulnerabilities that represents meaningful risk. For DORA-regulated firms, dependency risk management feeds directly into third-party risk requirements; see our guide on DORA compliance for crypto and Web3 firms for how supply chain security maps to regulatory obligations.
DORA Metrics and Security
The DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service) were originally designed as measures of DevOps performance. They have direct relevance to security outcomes. A high Change Failure Rate suggests that changes are reaching production without adequate testing or review, which increases the likelihood that a security issue will reach production. A low Deployment Frequency combined with large batch deployments increases the risk of a single deployment containing multiple security-relevant changes that are difficult to review thoroughly. Tracking DORA metrics alongside security metrics provides a holistic view of the engineering organisation's delivery health.
For broader data loss prevention metrics and controls that complement the DevSecOps pipeline, see our guide on data loss prevention for crypto firms.
Frequently Asked Questions
What is DevSecOps and how does it differ from DevOps?
DevSecOps is DevOps with security embedded at every stage rather than applied as a final gate before deployment. In a traditional DevOps model, security is typically a separate phase: a penetration test or code review conducted after development is complete and before a release. DevSecOps moves security left into the earliest stages of the development lifecycle, including pre-commit scanning, automated SAST in the CI pipeline, dependency auditing, and security-aware code review checklists. The goal is to identify and remediate vulnerabilities when they are cheapest to fix, rather than discovering them in production or through a security audit shortly before launch.
How do you prevent secrets from being committed to a Git repository?
The most effective approach is a combination of pre-commit hooks and CI-level scanning. Pre-commit tools such as Gitleaks, detect-secrets, and TruffleHog run locally before a commit is accepted and block any commit that contains patterns matching private keys, API tokens, or other secrets. At the CI level, secret scanning should run on every pull request to catch anything that slipped through local hooks. If a secret is committed to Git history, it must be treated as compromised immediately: rotate the credential, revoke the old one, and use git filter-repo to remove it from history before pushing.
What SAST tools are recommended for Solidity smart contract development?
Slither, developed by Trail of Bits, is the most widely used open-source static analysis tool for Solidity. It detects a broad range of vulnerability patterns including reentrancy, integer overflow, unchecked return values, and access control issues. Aderyn, developed by Cyfrin, is a newer Rust-based Solidity analyser that is fast and well-suited to CI integration. For backend and API code, Semgrep with community or custom rulesets provides effective SAST coverage across Python, JavaScript, TypeScript, Go, and Rust. None of these tools replaces a manual security audit, but they are essential for catching common vulnerability patterns continuously throughout development.
What happened in the solana-web3.js supply chain attack?
In December 2024, attackers compromised the npm publishing credentials of a maintainer of the @solana/web3.js package. They published malicious versions 1.95.6 and 1.95.7 containing code designed to exfiltrate private keys from applications using those versions. The malicious versions were live for several hours before being detected and removed. Projects that had pinned their dependencies to specific versions were unaffected; those using floating version ranges were exposed. The incident underscored the criticality of dependency pinning, lockfile integrity verification, and active monitoring of dependency update feeds.
How should multi-sig be used in smart contract deployment pipelines?
Multi-signature controls should be used for any deployment action that modifies contract state in production, including initial deployments of upgradeable contracts, proxy upgrades, ownership transfers, and parameter changes in critical protocol contracts. A common pattern is to use a Gnosis Safe multisig as the owner or admin of deployed contracts, requiring M-of-N key holders to sign any privileged transaction. The CI/CD pipeline produces a transaction proposal that is then signed and executed by key holders through the multisig interface rather than executing directly from a CI-controlled wallet.