Audits reduce risk, but they do not eliminate runtime threats because attackers often exploit operational behaviour, timing, or multi-step sequences that emerge after deployment. The article argues that many attacks unfold over multiple actions, with visible signals before the final exploit. Security teams need controls that watch the live environment, not just the code at release time.
Why audits miss the exploit path in practice
smart contract audit are strongest at finding code-level defects before deployment, but many Web3 exploits are not simple single-bug failures. Attackers often combine timing, state changes, external dependencies, and multi-step execution paths that only emerge in live conditions. That means a contract can look sound at review time and still be exploitable once real users, liquidity, market conditions, or integrations start interacting with it.
Audits also have a natural boundary: they evaluate what is visible in code, test inputs, and documented assumptions. They cannot fully prove how a contract will behave under adversarial sequencing, cross-contract interactions, or operational stress. In practice, that leaves a gap between static assurance and runtime reality, which is where many Web3 incidents begin.
One useful way to understand this gap is through live exposure rather than code quality alone. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that security failures often persist because the active environment is harder to observe than the artifact being reviewed. A similar problem appears in smart contract systems, where the exploit path is frequently visible only once transactions start flowing.
What attackers exploit after the code review is over
The common failure mode is not that the audit missed every flaw, but that the exploit depended on conditions outside the reviewed code path. Attackers may wait for a specific price movement, manipulate order of operations, trigger a reentrancy window, exploit oracle dependency drift, or chain several low-signal actions into one profitable event. Individually, those steps may look benign; together, they create the compromise.
That is why “secure at deploy time” is not the same as “safe in production.” The strongest audits still assume some stability in inputs, dependencies, and sequencing. Once those assumptions break, runtime controls become as important as code review. Live monitoring, anomaly detection, circuit breakers, guarded upgrades, and transaction-level policy enforcement help close the gap between audited intent and actual behaviour.
Attackers also benefit from the fact that exploit preparation can be subtle. They may probe a protocol, watch for weak slippage protection, test liquidity conditions, or wait for governance and liquidity changes that weaken a defence. The exploit then lands only after the environment has changed enough to make the attack profitable. This is why teams should treat “no audit findings” as one input to risk management, not as proof of exploit resistance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Runtime exploits often depend on exposed keys or secrets after deployment. |
| NHI-03 — Privilege and Access Management | Exploit impact grows when live controls or protocol roles are over-privileged. | |
| Recommendation — Rotate exposed secrets quickly and reduce blast radius for live protocol access. Enforce least privilege on privileged protocol functions and operational roles. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | The question centers on live monitoring beyond initial code review. |
| Recommendation — Continuously monitor production behaviour for anomalous transaction patterns and exploit signals. | ||
| CIS Controls v8 | 8 — Audit Log Management | Detecting multi-step exploit behaviour depends on usable runtime logging. |
| 13 — Network Monitoring and Defense | Live detection of suspicious interaction patterns is central to limiting exploit windows. | |
| Recommendation — Collect and retain logs that reveal pre-exploit sequencing and unusual contract activity. Instrument production monitoring to spot and block abnormal interaction bursts and abuse patterns. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | The answer involves exploit conditions that emerge when the system executes in production. |
| Recommendation — Map observed exploit sequencing to attacker technique patterns and tune detections accordingly. | ||
Practitioner Guidance
What to prioritise: Pair audits with runtime controls that can see and interrupt suspicious transaction sequences, especially where value can be drained through multi-step logic, dependent protocols, or time-sensitive conditions.
What to verify: Check whether the protocol has observable signals for pre-exploit behaviour, such as unusual sequencing, rapid parameter changes, abnormal liquidity movement, or repeated failed attempts before a successful drain.
Decision rule: If the attack requires only one buggy function, an audit may meaningfully reduce risk; if it requires environment-dependent sequencing, treat runtime monitoring and response as mandatory, not optional.
Common mistake: Assuming that a clean report covers the full threat model. In Web3, the dangerous part is often not the isolated bug, but the way adversaries compose otherwise ordinary actions into an exploit path.
Practitioner takeaway: The real control objective is not just finding defects before launch, it is constraining what attackers can do once the contract is live and the system is behaving like a market, not a test case.
Related resources from NHI Mgmt Group
- Why do private key breaches create more damage than many smart contract bugs?
- How do security teams know whether smart contract audits are actually reducing risk?
- Who is accountable when smart contract based advertising agreements fail to pay correctly?
- How should blockchain security teams reduce the risk of smart contract exploits before deployment?
