OpenCyber AcademyLesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Automated analysis"]
N2["26.2 Combining tools and review"]
N3["26.3 Interpreting critically"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Automated analysis"]
N2["26.2 Combining tools and review"]
N3["26.3 Interpreting critically"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Automated analysis]
|
v
[26.2 Combining tools and review]
|
v
[26.3 Interpreting critically]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) use automated analysis carefully; (2) combine tools with manual review; (3) interpret tool output critically.
26.1 Automated analysis
Automated tools scan contract code for patterns associated with known weaknesses. Durieux and colleagues' 2020 study evaluated several such tools on large sets of contracts and found that they disagreed often and each missed many issues, while also reporting false positives. Tsankov and colleagues' 2018 work described security analysis that checks properties rather than patterns. Sofia learns that tools are useful but limited. She runs one widely used open-source analyser on the voucher contract in the course's test environment, under supervision, and saves its output for comparison with her manual review.
26.2 Combining tools and review
The tool reports five items. Sofia compares them with her manual checklist. Two match her earlier findings, already fixed. Two are false positives: the tool flags a pattern that is safe in context because of a role check it did not understand. One is new: a function lacks an explicit check that the amount is above zero. She confirms it manually and records it as a low-severity finding. Combining approaches catches more than either alone. She notes that the tool found something she had missed, and she had found issues the tool missed, which matches what the research suggested.
26.3 Interpreting critically
Sofia writes guidance for interpreting tool output: treat every item as a question, confirm it by reading the code, record why false positives are safe, and never treat a clean result as proof of security. She also records the tool version, because results change between versions. Perez and Livshits' 2021 study found that many reported weaknesses in deployed contracts were never actually exploited, a reminder that a finding's real risk depends on context. Interpreting critically avoids both panic about harmless reports and false confidence from clean ones, and it keeps reviews grounded in evidence.
Worked example
The analyser reports five items: two already fixed, two false positives explained by role checks, and one new missing zero-amount check confirmed manually.
Synthetic case. The analysis is synthetic; Durieux et al. (2020), Tsankov et al. (2018) and Perez and Livshits (2021) are real sources.
Errors and limits
Treating a clean tool report as proof of security ignores the many issues tools miss.
Exercises
- EX076 — Tool study finding. What did Durieux et al. find about tools?
Show marking criteria
Rubric: 3 = they disagreed and each missed many issues;; 2 = disagreement;; 1 = all perfect;; 0 = none. - EX077 — Tool output breakdown. How did the five tool items break down?
Show marking criteria
Rubric: 3 = two fixed, two false positives, one new;; 2 = 2/2/1;; 1 = all new;; 0 = none. - EX078 — Context lesson. What did Perez and Livshits remind readers?
Show marking criteria
Rubric: 3 = reported weaknesses were often never exploited;; 2 = context matters;; 1 = all exploited;; 0 = none.
Synthesis
Tools and manual review complement each other when output is interpreted critically.
Continue studying — chapter 26 of 40
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →