The Attack Surface

A crypto company is not a single thing to defend. It is a multidimensional object with surfaces in every direction. Smart contracts are a surface. Cloud infrastructure is a surface. The multisig signers are a surface. The frontend, the CI/CD pipeline, the wallet libraries, the npm dependencies, the people, the contractors, all of them are surfaces. Every element on that surface is a place an attacker can land.

The point of seeing it this way is operational, not metaphorical. If you cannot see it, you cannot quantify it. If you cannot quantify it, you cannot measure it. If you cannot measure it, you cannot contain it. Threat modeling is the act of making the invisible visible — drawing the shape of your own surface so you can decide which parts of it need hardening first.

Twelve threat vectors arranged around the protocol you are trying to defend, grouped into six categories — smart contract, operational, human, infrastructure, supply chain, governance. Each one is a real surface with real historical incidents behind it.

Most crypto startups are unusually porous entities for the value they hold. A five-person team running half a billion dollars of TVL with the same operational security maturity as a five-person SaaS company that processes credit card numbers. Poor information security. Poor data hygiene. Poor opsec. The value-at-risk to defense ratio is wildly imbalanced, and that imbalance is the entire problem. The smart contracts get audited four times. The signers' laptops do not.

The least-defended surface and the highest-leverage attack vector right now is the same thing: contractors. They work on multiple projects at once, which means a compromise of one is a compromise of many. Their security posture is opaque to the company hiring them — you do not know whether their laptop is patched, whether their wallet is on a fresh device, whether they are running a clipboard hijacker someone planted six months ago. They are routinely given access to the parts of the stack that matter most: deploy keys, multisig signing roles, CI access, smart contract authorship, governance proposal execution. They are not subject to the same operational controls as employees. They sign the contract, get the access, do the work, and disappear. Whatever discipline a company applies to its own staff stops at the contractor's edge.

This is not theoretical. The DPRK IT worker pattern documented by SEAL and others shows state-affiliated actors infiltrating crypto companies through legitimate-looking contractor positions and waiting for the right moment to act. The path of least resistance into a well-funded crypto company is no longer the smart contract. It is the contractor whose laptop got owned three months ago and who now has deploy keys for your factory.

The fix is adding visibility and surfacing the unstated assumptions. You cannot defend a surface you have not drawn, and you cannot rank-order what to harden first if you cannot see all of it at once. Go draw your own version of the picture. Look at every contractor relationship and ask what they could do if their machine were compromised tomorrow. Do they use a dedicated device when working on your project? Look at every signer and ask the same question. Do signers on your multisig use device isolation to limit blast radius if their daily driver got compromised? Look at the dependencies your build pulls in. Look at the DNS registrar that fronts your customer-facing domain. The companies whose names do not appear in Rekt News are the companies that drew this picture early, honestly assessed their posture, and stopped pretending the smart contract was the whole job.