Chapter 16 — Web3, blockchain and cryptoasset security: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Automated tools"]
N2["16.2 Combining tools and manual checks"]
N3["16.3 Interpreting output with context"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Automated tools"]
N2["16.2 Combining tools and manual checks"]
N3["16.3 Interpreting output with context"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Automated tools]
|
v
[16.2 Combining tools and manual checks]
|
v
[16.3 Interpreting output with context]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) use automated tools carefully; (2) combine tools with manual checks; (3) interpret output with context.
16.1 Automated tools
Lucas learns that automated tools help with routine checks: configuration scanners compare servers with baselines, log tools search for patterns, and contract analysers flag code patterns linked to known weaknesses. Durieux and colleagues' 2020 study of contract analysis tools found they often disagreed and each missed many issues. Lucas concludes that tools are aids, not judges. He uses them to cover ground quickly, then checks important results by hand. Ms Adebayo asks the class to record each tool's version and settings, since results depend on both and must be reproducible later.
16.2 Combining tools and manual checks
When a configuration scanner flags a node for an open port, Lucas checks manually and confirms the port is the peer port, which is expected and restricted by the firewall allow-list. He records it as a false positive with the reason. When it flags a missing time-synchronisation service, the manual check confirms it, and he fixes it. Combining tools with manual checks avoids two errors: ignoring real problems because tools are noisy, and acting on false alarms that waste time and erode trust in the tools themselves.
16.3 Interpreting output with context
Context changes meaning. An alert about a large credit transfer is concerning on a weekday afternoon but expected on the monthly day when the makerspace refunds unused workshop deposits. Lucas adds context notes to his monitoring guide, describing normal patterns by day and season. Perez and Livshits' 2021 study found that many weaknesses reported by tools in deployed contracts were never exploited, a reminder that output must be weighed in context. Interpreting with context helps technologists respond proportionately rather than treating every alert as an emergency.
Worked example
Lucas confirms a flagged peer port is an expected false positive, fixes a confirmed missing time service and documents normal monthly refund patterns.
Synthetic case. The tool results and patterns are synthetic; Durieux et al. (2020) and Perez and Livshits (2021) are real sources.
Errors and limits
Acting on every tool alert without manual confirmation wastes effort and erodes trust in tools.
Exercises
- EX046 — Tool study. What did Durieux et al. find? Rubric: 3 = tools often disagreed and each missed many issues;; 2 = disagreement;; 1 = perfect tools;; 0 = none.
- EX047 — False positive. Which flag was a false positive? Rubric: 3 = the open peer port;; 2 = peer port;; 1 = missing time service;; 0 = none.
- EX048 — Context pattern. When is a large transfer expected? Rubric: 3 = on the monthly deposit refund day;; 2 = refund day;; 1 = never;; 0 = none.
Synthesis
Tools speed up checks, manual confirmation keeps them honest and context gives meaning.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →