Web3 Security Audit: A Step-by-Step Guide for 2026

The most repeated advice in this market is still "get the audit, then you can launch." I would not hire on that advice, and I would not ship on it. A finished PDF records what one team reviewed, on one commit, inside one written scope. It does not certify that the protocol is safe.

A study of 8,195 audit reports from 117 firms, covering 1,575 DeFi protocols launched between January 2020 and October 2023, found that about 7% of launched protocols suffered a breach or hack within six months. It also found little evidence that completing an audit lowered the chance of a later breach, according to the Coller School of Management working paper. Code defects are only part of the loss. Business logic, upgrades, oracles, admin keys, and deployment config sit beside the contracts.

Treat a web3 security audit as a program you can hand to a reviewer or a hiring manager. Write the scope, the gates, and the residual risk in artifacts someone else can check.

Audit Phases and Deliverables at a Glance

A scanner report is not an audit. Teams that run Slither, paste the warnings into a doc, and call the result done have skipped the decision the work is supposed to support.

The OWASP infrastructure security handbook describes a staged workflow: scope, architecture and manual review, automated analysis, classification, remediation, then proof that the fix closed the issue. Order matters because each gate blocks the next phase. You cannot triage what you have not scoped, and you cannot sign off on a fix you have not retested.

Phase	Output you hand over	Gate before the next phase
Scoping	Pinned commit hash, file list and dependency lock	Client signs the written scope
Threat modeling	Trust boundaries, privileged roles and economic assumptions	Protocol owner confirms the actor list
Automated analysis	Static, fuzzing and invariant test reports	Every tool hit is triaged as true, false or accepted
Manual review	Annotated code paths for privileged and value-moving functions	Every privileged function has a reviewer note
Triage	Severity-ranked findings with proof-of-concept tests	Severity agreed with the engineering lead
Remediation	One fix commit per finding, linked to its finding ID	Fix has a regression test
Retest and sign-off	Regression evidence and a residual-risk list	Unresolved High findings block deployment unless risk is accepted in writing

Interviewers often ask candidates to name the artifact each phase produces. Juniors who can execute a scoped review stand out from people who only list tools. Seniors are judged on residual risk and the release gate, not on the length of a spreadsheet.

Practical rule: If you cannot name the commit, the privileged-function list, and the written risk acceptance, you do not have a deployment decision.

Before an upgrade, write one line per phase: the artifact you will produce, and the person who must sign it.

How to Scope a Web3 Audit Before Reading Code

The scoping mistake that causes the most rework is opening the repo before the boundary is frozen. Reviewers then spend days on contracts the client never meant to include, or they miss the proxy admin script that moves funds.

The OWASP Smart Contract Security Testing Guide starts with the threat model, trust boundaries, privileged roles, upgrade paths, oracles, cross-chain messages, and economic assumptions, then maps those requirements onto the Smart Contract Security Verification Standard and the matching SCSTG tests. Do that on paper first.

1. Pin the build. Record the commit hash, branch, and compiler version. A finding against main tomorrow is not a finding against the code you reviewed.
2. Freeze dependencies. List every imported library and version. OpenZeppelin at 4.9 and 5.0 are not the same review.
3. Draw the boundary. Name every contract in scope, and name what is out: frontends, bridge relayers, deployment scripts. Out of scope is still written down, so nobody pretends it was covered.
4. Mark trust. For each contract, note which inputs it trusts and which external calls it treats as correct.
5. List privileged roles. Owners, pausers, minters, upgrade admins, fee recipients, and emergency operators, plus where each key lives and who can sign.
6. Name external data. Oracle, bridge, and cross-chain message paths, including the price source and its update delay.
7. Write the economics. Liquidation thresholds, share-price accounting, rounding direction, and any fee that changes balances.
8. Map tests. Tie each requirement to an SCSVS control, then pick static, dynamic, composition, and integration tests. No single lane is enough before an adoption gate.

For fuzzing, write stateful invariants before you generate inputs: conservation of assets, solvency, authorization boundaries, and monotonic accounting. Crash-only fuzzing will not catch a share-price bug that never reverts.

End the scope with one sign-off line the client confirms in writing: commit, in-scope files, out-of-scope systems, and the actor list. If you are practicing auditing code for security controls, this written boundary is what makes a later finding defensible.

In a ten-minute interview, ask the candidate to scope a protocol upgrade. The useful answer includes keys and deployment configuration without being prompted.

Which Automated Tools Cover Which Risks

Running three tools is not coverage. Each lane answers a different question, and a green run only means "no violation of what this lane can see."

A two-benchmark study of seven static and LLM-based tools on 143 curated contracts and 173 real-world audit-derived contracts found that broad static tools tended to over-report, and that both static and LLM approaches had stability or over-prediction problems on realistic code, as reported in the ESEM 2026 tool-evaluation paper. A separate empirical result in that work found that combining three detectors identified up to 76.78% of manually annotated vulnerabilities in under a minute on average. Faster triage is not a complete assurance.

Testing lane	Catches well	Known blind spot	Typical tool
Static analysis	Unsafe patterns, unchecked external calls and data flow	Over-reports on large codebases and misses economic logic	Slither
Fuzzing and invariant testing	Stateful sequences, unexpected reverts and boundary inputs	Only finds violations of the invariants you wrote	Echidna or Foundry invariant tests
Symbolic execution	Path-specific arithmetic and reachable states	Path explosion on large contracts	Mythril
Formal verification	Proving a stated property holds for all inputs	Only as good as the specification written	Certora Prover
Composition analysis	Vulnerable or outdated imported libraries	Says nothing about how the code wires them together	Dependency scanners
Integration tests on forks	Oracle, bridge and wallet interactions against live state	Results change if the forked block is not pinned	Foundry fork tests

Tuning that survives a retest

• Static on every commit. Record every suppression with a written reason. A silenced detector with no note becomes invisible debt.
• Invariants before fuzzing. Example: total shares times price per share must not exceed assets, and the sum of user balances must equal total supply.
• Pin the fork. Run oracle and bridge tests against one block number so a later engineer can reproduce the pass or the fail.

A tool that scores well on a benchmark can over-report, or stay silent, on your production contracts. Before you trust that silence, replay one known bug from your own history and confirm the tool flags it. Candidates who can explain why a scanner missed a specific finding are ahead of candidates who only recite a tool list. If you are building that skill, a smart contract vulnerability scanner write-up is a starting point, not a substitute for the replay test.

Manual Review Checklist for Logic, Access and Keys

The expensive miss is a privileged path nobody traced. The function compiled, the scanner was quiet, and the owner key could still drain or upgrade the system.

Spend review time where the losses sit. A systematic review of 112 studies and incident reports found that access-control and business-logic attacks accounted for about 60% of 2024 losses, about $1.44 billion of $2.36 billion across 767 on-chain incidents, in a Springer incident synthesis. A four-year study of 218 exploits, about $7.76 billion, found private-key compromise, phishing, and social engineering caused about 49.6% of cumulative losses while barely appearing in published audit findings, per the Dagstuhl exploit study. The Blockchain Security Alliance annual report counted contract vulnerabilities in 76 of 131 major 2024 attacks, 58.02%. Beosin's first-half 2023 analysis found about 49% of attacked projects had not been audited.

Finding	Figure	Audit focus
Access-control share of 2024 crypto hacks (Hacken)	75%	Roles, initializers, proxy upgrades and emergency pause
Access-control and business-logic share of 2024 losses (systematic review)	about 60%, $1.44B of $2.36B	Privileged paths and economic invariants
Contract vulnerabilities in 2024 major attacks (Blockchain Security Alliance)	58.02%, 76 of 131 attacks	Full contract code and its integrations
Private-key, phishing and social engineering share of cumulative losses (four-year study of 218 exploits)	about 49.6% of $7.76B	Key custody, signers, deployment pipeline and monitoring
Phishing scam damages in 2024 (Hacken)	about $600M	Operational and human controls beyond the code
Attacked projects that had not been audited in H1 2023 (Beosin)	about 49%	Audit scope coverage before launch

Access control

Verify every privileged operation, role-transfer path, initializer, proxy upgrade, emergency pause, fee recipient, mint and burn, and governance execution route. Confirm an initializer cannot be called twice.

Red flag: initialize is public and the implementation was never initialized before the proxy pointed at it.

Economic logic

Model oracle manipulation, flash-loan sequences, price-delay assumptions, liquidation thresholds, share-price inflation on the first deposit, and rounding direction on every division.

Red flag: the first depositor can inflate the share price with a donation, so the next depositor's assets round to zero shares.

Composability and operations

List every external protocol the code calls, and what happens if that call returns an unexpected value or reverts. Then leave the Solidity file. Who holds each admin key? Are multisig signers separated by team or custody? Can the deployment pipeline change bytecode without review? Has anyone executed the pause?

Red flag: one laptop holds the deployer key and the pause key, and the pause has never been called on a fork.

Skip these pitfalls: reviewing only the committed contract while ignoring deployment scripts, treating a clean compile as correctness, treating tool output as the full bug list, skipping upgrade and init flows, and missing multi-transaction sequences. In an interview, ask the candidate to walk one access path from key holder to state change. Writing that path is also the habit behind how to write secure code once you are past naming the bug class.

Severity Ratings and Report Template

A severity label only matters if it changes what ships. If Critical and Informational both land in the same backlog, the scale is decoration.

Severity	Typical criteria	Deployment rule
Critical	Direct loss of funds or control without special privilege	Block deployment; fix and retest
High	Loss under realistic preconditions, or misuse of a privileged role	Block unless a named owner accepts the risk in writing
Medium	Limited loss, griefing, or an unusual condition is required	Fix before launch or document with an owner and date
Low	Gas waste, weak event logging or minor deviation from the spec	Track in the backlog
Informational	Naming, clarity or drift from best practice	Optional fix

Fields in the order engineers read them

Use one entry per issue, even when two bugs share a root cause. Split them so each fix has its own regression test.

• Identity: finding ID, title, severity, affected contract, and line range.
• Preconditions: who must call, what balances or roles must exist, and which external state is assumed. Plain language turns a severity argument into a question of fact.
• Reproduction: numbered steps, then a proof-of-concept test that fails on the audited commit.
• Impact: funds at risk, or a percent of value at risk. A number beats "could be severe."
• Closeout: suggested remediation, regression evidence, and status (open, fixed, or accepted).

State the precondition so a skeptical engineer can disagree with a fact, not with your tone.

Hiring managers often open the sample report before they open the résumé. One reproducible High, with a failing test and a clear impact number, beats a long list of style notes. Keep the template stable across reports so a second reviewer can compare severity without relearning your format.

Remediation Workflow From Finding to Retest

Fixes usually fail by closing one path and opening another. The original proof of concept goes green, and a sibling function that reads the same storage now mis-accounts balances.

Hacken's 2024 Web3 Security Report found access-control vulnerabilities accounted for 75% of crypto hacks that year, while phishing scams caused about $600 million in damages. A patch to onlyOwner does not help if the signer is phished next quarter. Post-launch monitoring of privileged calls belongs in the audit program.

1. Name an owner and a date. One person per finding. Critical and High dates sit before any launch conversation.
2. Reproduce on the audited commit. Run the original proof of concept so the fix is judged against the same failure.
3. Fail the test first. Write the regression test, watch it fail, then write the fix until it passes.
4. Second set of eyes. A different engineer reviews the changed function and every function that shares its state.
5. Rerun the suite. Full automated tests plus the specific proof of concept, on the fix commit, not on a dirty working tree.
6. Hunt side effects. Any reader of the changed storage gets a manual pass, including view functions the UI trusts.
7. Record the evidence. Commit hash, test output, and date, inside the original finding entry.
8. Write residual risk. For anything left open: the risk, the named accepter, and the alert that will watch for exploitation.
9. Schedule the next pass. Re-audit after a major upgrade, and keep alerts on privileged calls after launch.

Ask a candidate how they would prove a fix closed a finding rather than moved it. The answer you want is a failing test on the old commit, a passing test on the fix commit, and a check of every other reader of that state. "We deployed and watched" is not that proof.

Turn Audit Skills Into Your Next Role

Hiring managers can check three levels from the artifacts, not from tool names on a résumé.

1. Junior reviewer. Execute a written scope and produce one reproducible finding with a proof of concept and a severity rationale tied to the deployment rule.
2. Mid-level auditor. Rank findings by exploitability and impact, then design the invariant or fuzz property that would have caught each one.
3. Senior auditor. State residual risk, set the release gate, and say which assumption about keys, signers, or the deployment pipeline would change the verdict.

A review of 23 paid smart-contract security audits produced 246 findings. Access-control issues were 10% of findings and reentrancy was 4%, yet 50% of reentrancy findings were high severity, and dynamic analysis found 75% of those reentrancy issues while static analysis found 100%, in the Trail of Bits executive summary. Breadth matters. A portfolio that is only reentrancy stories is thin.

For a hiring exercise, hand applicants a short set of findings. Ask them to rank each by exploitability and impact, and to justify a proof of concept, a manual review, or an automated test. Candidates should build two or three sample reports from public code or their own tests, each with a scope, a severity rationale, and a regression test, then apply at the level those reports support. We list 1,696 blockchain and Web3 jobs at the Senior level, so the senior packet needs the release-gate write-up, not another scanner screenshot. Roles like these show up on blockchain security jobs boards once the reports are ready to send.

---

Blockchain Jobs lists open roles across crypto, DeFi, and Web3, including security, engineering, and protocol work where a real audit packet is what gets you the interview. If you are hiring, post against people who can show scope, severity, and retest evidence, not a tool list. Visit Blockchain Jobs to browse current listings or set a daily email alert for new roles.