Chapter 23 — Web3, blockchain and cryptoasset security: methods I
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Checklist-based review"]
N2["23.2 Standards as criteria"]
N3["23.3 Recording findings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Checklist-based review"]
N2["23.2 Standards as criteria"]
N3["23.3 Recording findings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Checklist-based review]
|
v
[23.2 Standards as criteria]
|
v
[23.3 Recording findings]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) apply checklist-based review; (2) use standards as review criteria; (3) record review findings consistently.
23.1 Checklist-based review
A checklist turns knowledge into a repeatable review. Sofia builds one for the voucher contract from the OWASP Smart Contract Top 10 and the SWC registry, phrased as questions: are all privileged functions restricted, are external calls made after state updates, are arithmetic limits handled, is the compiler pinned, are events emitted for every change. Each question has a yes, no or not applicable answer with evidence. Checklists do not find everything, but they ensure known issues are not forgotten, and they let different reviewers produce comparable results on the same code over time.
23.2 Standards as criteria
The EEA EthTrust Security Levels specification defines requirements a contract should meet at different levels of assurance. Sofia maps her checklist to EthTrust requirements where they correspond, so findings can be reported against a recognised standard rather than personal opinion. She notes that the specification itself states that meeting its requirements does not guarantee a contract is free of weaknesses. Using standards gives reviews a shared language and makes results easier for others to trust. She records the specification version used, because requirements change between versions and readers need to know which applied.
23.3 Recording findings
Each finding is recorded with an identifier, location, description, severity, related standard requirement, evidence and recommended fix. Severity considers both impact and likelihood. Sofia reviews the voucher contract and records two findings: one function that changes the weekly cap emits no event, so changes are hard to monitor; and the compiler version is a range rather than a fixed value. Both are rated low severity. She shares them with the developer, who fixes both within a week. Consistent records make findings easy to track, verify and report to the board in plain language.
Worked example
Sofia's checklist review finds a missing event on the cap-change function and an unpinned compiler, both low severity and fixed within a week.
Synthetic case. The review is synthetic; OWASP SC Top 10, the SWC registry and EEA EthTrust are real sources.
Errors and limits
Treating a passed checklist as proof of security ignores weaknesses the checklist does not cover.
Exercises
- EX067 — Checklist sources. Which sources shape the checklist? Rubric: 3 = OWASP SC Top 10 and the SWC registry;; 2 = OWASP;; 1 = a forum;; 0 = none.
- EX068 — Standard caveat. What does EthTrust say about meeting its requirements? Rubric: 3 = it does not guarantee freedom from weaknesses;; 2 = no guarantee;; 1 = full guarantee;; 0 = none.
- EX069 — Review findings. What two findings does Sofia record? Rubric: 3 = missing cap-change event and unpinned compiler;; 2 = missing event;; 1 = stolen funds;; 0 = none.
Synthesis
Checklists anchored in standards produce consistent, trusted review findings.
Continue studying — chapter 23 of 40
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →