openskills.info
Course catalog
Open Course

Smart Contract Security

Smart contract security is the practice of keeping blockchain programs correct when any account or contract can call them with adversarial inputs. It protects assets, permissions, and system rules before and after code is deployed.

itOffensive security and application security

Recommended first:smart-contract-development

Don't Panic — Smart Contract Security

A smart contract is a program that lives on a blockchain, and once it's live, nobody — not even its author — can just quietly go in and fix a mistake overnight. Traditional software gets a hotfix at 2 a.m. and a shrug the next morning. A contract usually doesn't get that unless somebody built in a way to change it in advance, and that "way to change it" turns out to be its own security problem, which is most of what this course is actually about.

Before blockchains, if a bank's ledger software had a bug, the bank paused it, patched it, and reconciled the books afterward. A public contract has no pause button unless one was written in ahead of time, and no ledger to reconcile except the one an attacker already rewrote in their favor. Immutability is the feature people signed up for. It is also why a bug here costs differently than a bug almost anywhere else in software.

One idea does most of the work: an invariant is a rule that must hold in every reachable state — "nobody can withdraw more than they put in" is a plain example. Security work here is mostly writing these rules down before writing any code, because a rule nobody stated is a rule no tool, however good, can ever check on your behalf.

The other idea is that every external call is a handoff of control, not just a function call returning a value. The contract on the other end of that call might call back into yours before your first call has finished — that's a reentrancy, and it's the bug that made "smart contract security" a phrase people needed in the first place. Order of operations, it turns out, is a security property.

Here's the part likely to surprise you if you came in expecting stories about clever code exploits: the single biggest cause of stolen funds isn't a bug in anyone's Solidity at all. It's a compromised key — someone getting hold of an account that was allowed to move funds or replace logic. A shared-signature wallet helps, but one with no time delay and no separation of roles is still one bad day from the identical outcome. The code can be flawless and the system can still fall over because of who was trusted, and how much.

None of this is provable-safe, ever. An audit checks one build at one moment in time; change the compiler settings or the deployed bytecode afterward and that evidence quietly stops describing what is actually running. What you actually get is a stack of overlapping evidence — tests, static analysis, an audit, live monitoring, a rehearsed incident response — that either agrees with itself or doesn't. Confidence, not certainty, is the product on offer.

Start with the Intro for the full trust-boundary walkthrough, the Cheatsheet when you need the vulnerability-to-control mapping fast, and Field Notes for what actually happens to teams that skip the boring parts anyway.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources