Chapter 15 — Web3, blockchain and cryptoasset security: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Documenting integrations"]
N2["15.2 Tracking dependencies"]
N3["15.3 Planning for changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Documenting integrations"]
N2["15.2 Tracking dependencies"]
N3["15.3 Planning for changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Documenting integrations]
|
v
[15.2 Tracking dependencies]
|
v
[15.3 Planning for changes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) document integrations with other systems; (2) track dependencies and versions; (3) plan for dependency changes.
15.1 Documenting integrations
The deposit system connects to the reservation application, the borrower database, an email service for reminders and the library's accounting software. Aiko documents each integration: what data flows, in which direction, which credentials are used and what happens if it fails. She finds the accounting export reads balances directly from a node every night, adding load at the same time as backups. She proposes moving the export an hour later. Documented integrations make the effects of changes predictable and reveal conflicts that would otherwise remain hidden.
15.2 Tracking dependencies
Aiko lists dependencies with versions: the ledger client, the operating system, Python, libraries used by the deposit service, the compiler version used for the contract and the hardware wallet firmware. For each she records the owner, how updates are announced and when it was last updated. The SWC registry includes weaknesses linked to outdated compilers, and similar risks apply to other dependencies. A dependency list turns vague worries about outdated software into specific items with owners, dates and an update plan everyone can follow.
15.3 Planning for changes
Dependencies change: a library releases a security fix, the cloud provider changes a setting, or the wallet firmware needs an update. Aiko writes a simple plan: check announcements monthly, test updates on the test ledger, apply them through change tickets one component at a time and confirm checks pass afterwards. For urgent fixes, a faster path requires the manager's approval. She also lists what to do if a dependency is withdrawn. Planning turns dependency changes into routine work rather than emergencies that disrupt borrowers.
Worked example
Aiko documents four integrations, moves the nightly accounting export after backups and tracks six dependency types with owners and update dates.
Synthetic case. The integrations and dependencies are synthetic; the SWC registry is a real source.
Errors and limits
Untracked dependencies become outdated unnoticed until a problem forces an urgent update.
Exercises
- EX057 — Load conflict. What conflict did Aiko find? Rubric: 3 = accounting export reading nodes during backups;; 2 = export timing;; 1 = vague;; 0 = none.
- EX058 — Dependency example. Name one tracked dependency. Rubric: 3 = hardware wallet firmware;; 2 = ledger client;; 1 = office chairs;; 0 = none.
- EX059 — Update path. How are routine updates applied? Rubric: 3 = tested, then one component at a time through tickets;; 2 = tested and staged;; 1 = all at once;; 0 = none.
- EX060 — Urgent fix path. What does the urgent path require? Rubric: 3 = the manager's approval;; 2 = approval;; 1 = vague;; 0 = none.
Synthesis
Documented integrations and tracked dependencies make change predictable.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →