SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 8, Exercise 2 Solution
==========================================================
Why an Audit Alone Doesn't Guarantee Full Security

PROBLEM
-------
A junior developer says: "We had our smart contracts professionally
audited, so our project is now fully secure against a major hack."
Using this chapter's own Ronin case study, explain what this statement
overlooks.

SOLUTION
--------
A professional security audit genuinely helps against exactly one real
category of risk: bugs and vulnerabilities in the smart contract code
itself - the reentrancy, integer overflow, access control, and similar
issues Chapter 7 covered. That's real, valuable protection, and worth
doing.

But this chapter's own Ronin case study shows a real, large-scale
($620 million) exploit that, per the publicly available account, wasn't
primarily caused by a flaw in deployed contract code at all - it was
caused by compromised validator infrastructure and private key access,
reportedly through social engineering targeting the humans operating
the system. No amount of scrutiny applied to the Solidity source code
itself would have caught or prevented that kind of attack, because the
vulnerability wasn't in the code being audited - it was in the
real-world security of the people and systems controlling the keys
that authorize the bridge's own transactions.

This is exactly the honest, broader lesson this chapter draws from
comparing Poly Network against Ronin: contract-code security (what an
audit actually covers) and infrastructure/operational security
(validator key management, employee security awareness, access
controls on internal systems) are genuinely separate concerns, and
being strong in one doesn't say anything about the other. A project
could have a perfectly audited, flawless smart contract and still
suffer a real, catastrophic loss through exactly the kind of attack
Ronin experienced.

ANSWER: An audit only addresses vulnerabilities in the smart contract
code itself (Chapter 7's own taxonomy) - it says nothing about
infrastructure and human factors, which this chapter's own Ronin case
study shows can be exploited just as catastrophically, entirely
independent of how secure the contract code is. "Fully secure" would
require also securing the validator infrastructure, private key
management, and the humans operating them - none of which a code audit
covers.

----
WHY THIS WORKS AS AN ANSWER

This correctly scopes what an audit actually covers, then uses the
chapter's own Ronin case study as concrete, real evidence that a
separate, equally serious attack surface exists outside that scope,
rather than treating "audited" and "fully secure" as equivalent claims.