Chapter 17 — Web3, blockchain and cryptoasset security: tooling
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Assembling a toolkit"]
N2["17.2 Managing versions"]
N3["17.3 Read-only by default"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Assembling a toolkit"]
N2["17.2 Managing versions"]
N3["17.3 Read-only by default"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Assembling a toolkit]
|
v
[17.2 Managing versions]
|
v
[17.3 Read-only by default]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) assemble a safe toolkit; (2) manage tool versions; (3) keep tooling read-only where possible.
17.1 Assembling a toolkit
Lucas assembles a toolkit: the ledger client's command-line interface for reading node status, a small set of Python scripts for checks, a log viewer, a configuration scanner and a hardware wallet utility for signers. He documents each tool's purpose, source and owner. He chooses widely used, maintained tools and avoids installing unknown utilities from unverified sources. A toolkit is part of the attack surface: a compromised tool on a signer's computer could misrepresent what is being signed, so tool choice is itself a security decision.
17.2 Managing versions
Each tool has a pinned version recorded in a simple list. Updates are tested in the college lab before use at the makerspace. Lucas checks release notes for security fixes and breaking changes. He learns that the SWC registry lists weaknesses linked to outdated compilers, and the same principle applies to operational tools: old versions accumulate known problems. He schedules a quarterly tooling review. Version management sounds dull, but it prevents surprises, such as a script that suddenly fails because a tool changed its output format overnight.
17.3 Read-only by default
Most of Lucas's tools only read data. His scripts use the node's read interface and the database's read-only account. The only tools that can change the ledger are the multisig signing tools, used by staff on dedicated devices. Keeping monitoring and reporting tools read-only means a bug or misuse cannot alter balances or roles. He labels every script with whether it reads or writes. Ms Adebayo calls this one of the most effective habits in operations: separate the many tools that look from the few tools that change.
Worked example
Lucas's toolkit pins versions, is reviewed quarterly and keeps all monitoring scripts read-only, with writes limited to signing tools on dedicated devices.
Synthetic case. The toolkit is synthetic; the SWC registry is a real source.
Errors and limits
Running monitoring scripts with write access lets a bug alter balances or roles.
Exercises
- EX049 — Tool risk. Why is tool choice a security decision? Rubric: 3 = a compromised tool could misrepresent what is signed;; 2 = tool compromise;; 1 = cost;; 0 = none.
- EX050 — Tooling review. How often are tools reviewed? Rubric: 3 = quarterly;; 2 = every quarter;; 1 = never;; 0 = none.
- EX051 — Writing tools. Which tools can change the ledger? Rubric: 3 = the multisig signing tools on dedicated devices;; 2 = signing tools;; 1 = all scripts;; 0 = none.
Synthesis
A documented, versioned and mostly read-only toolkit reduces operational risk.
Continue studying — chapter 17 of 30
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →