Security Controls and Secure Development
What to Know
Secure development for ledgers combines SDLC discipline with on-chain specifics. Requirements and threat modeling come first: define trust boundaries, privileged roles, and upgrade paths. Design controls include checks-effects-interactions ordering, reentrancy guards, pull-over-push payments, access-control modifiers, pausability, and rate limits. Input validation and safe arithmetic matter, though modern compilers include overflow checks.
Testing must cover unit tests, fuzzing, invariant testing, static analysis, and formal verification where value is high. Audits are independent reviews; they complement but do not replace testing. Deployment controls include multisignature admin keys, timelocks, staged rollouts, and reproducible builds. Monitoring covers event alerting, anomaly detection, and on-chain watchlists.
Operational controls include key management with HSMs and threshold signing, secret scanning, dependency pinning, and least-privilege CI/CD. Incident-response readiness means pausing, migrating, and communicating.
Traps
- Believing a reentrancy guard fixes all reentrancy; cross-function and cross-contract paths exist.
- Treating a timelock as prevention; it is detection and response time.
- Confusing fuzzing with formal verification; fuzzing samples, verification proves within a model.
- Assuming admin keys are safe because they are multisig; threshold and signer hygiene matter.
Rule of Thumb
Use defense in depth matched to asset value: the higher the value at risk, the more independent verification layers. Worked example: a lending contract uses checks-effects-interactions, a guard, TWAP oracles, a pause guardian, and a timelocked upgrade, each addressing a different failure.
Study Focus
Be ready to select the control that addresses a described weakness and to explain why a single control is insufficient.