Your Contract Is Audited. What About Everything Around It?
Protocols spend heavily auditing their smart contracts and comparatively little on everything around them. It's an understandable instinct — the contract holds the funds. But an audited contract sitting behind an unaudited stack is a strong front door on a building with the windows open.
The gap exists for a structural reason. Traditional security firms usually don't read Solidity, and contract auditors usually stop at the contract boundary. Very little assessment covers the seam between them, which is where a growing share of real losses occur.
Where the seam actually is
The frontend. Users don't interact with your contract, they interact with your website. Compromise the DNS, the hosting, or a dependency in the build, and you can swap the contract address the interface points at. The contract is untouched and perfect, and users are approving transactions to an attacker. This has happened repeatedly and rarely involves any on-chain flaw.
Keys and signers. Admin keys, deployer wallets, multisig signers and oracle updater keys all live in ordinary infrastructure — a laptop, a CI secret store, a cloud key manager. On-chain access control is only as strong as the operational security around the private keys that satisfy it. Key management is a Web2 problem with Web3 consequences.
Backend and API surface. Most protocols run substantial off-chain systems: indexers, relayers, price feeds, allowlist services, admin dashboards. These are conventional applications with conventional vulnerabilities, and they frequently hold privileged positions relative to the contracts.
The build pipeline. If an attacker can influence what gets deployed, auditing the source is beside the point. Supply chain compromise reaches the contract without ever attacking it — which is precisely why OWASP elevated supply chain failures in its 2025 revision.
The pattern worth internalising
Attackers don't respect your architecture diagram. They take the cheapest available path to the funds, and that path frequently runs entirely off-chain.
A threat model that stops at the contract boundary isn't a threat model. It's a scope decision, and it should be a deliberate one rather than an accident of who you hired.
How Block Lock approaches it
We work on both sides of that boundary — smart contract auditing and Web2 offensive security — because the interesting failures live where they meet.
Smart contract audits — manual review for reentrancy, access control, oracle manipulation, arithmetic and upgrade-path risk.
Web application and infrastructure testing — authorised penetration testing of the frontend, APIs and supporting services.
Key and operational review — how privileged keys are stored, used, rotated and recovered.
Supply chain and deployment review — what could alter what you ship.
The deliverable is a written report: what was reachable, how, what it would cost you, and what to fix in what order.
Comments