Chapter 9 — Programming II
Lesson map
Lesson 09 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Structuring tools"]
N2["9.2 Testing with known cases"]
N3["9.3 Handling secrets"]
N4["9.4 Dependencies and supply"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Structuring tools"]
N2["9.2 Testing with known cases"]
N3["9.3 Handling secrets"]
N4["9.4 Dependencies and supply"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]
[Learning outcomes]
|
v
[9.1 Structuring tools]
|
v
[9.2 Testing with known cases]
|
v
[9.3 Handling secrets]
|
v
[9.4 Dependencies and supply]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) structure larger security tools; (2) test code with known cases; (3) handle secrets safely in programs.
9.1 Structuring tools
Lindiwe's scripts grow, so she organises them into functions with clear inputs and outputs: one reads accounts, one applies rules and one writes reports. Each function does one job and can be tested alone. Prof. Hale explains that structure matters more in security tools than elsewhere, because a hidden bug may report that everything is compliant when it is not, and nobody will notice until an incident proves otherwise. She also writes a short description at the top of each function explaining what it checks.
9.2 Testing with known cases
Lindiwe writes tests using small synthetic inputs where she knows the correct answer: an account with no multi-factor authentication and admin rights must be flagged; a normal account must not. She runs the tests after every change using the standard unittest module. When a later change breaks the admin check, a test fails immediately. She learns that tests are the evidence that a security check does what its name claims. By the end of the term her test file holds twenty cases, each named after the rule it checks.
9.3 Handling secrets
One tool must call Saltmarsh's directory using a service account password. Lindiwe's first version stored the password in the script, which was then shared in a chat channel. She rewrites the tool to read credentials from an environment variable set by the scheduler, and asks for the exposed password to be changed. Prof. Hale notes that secrets in code end up in backups, repositories and messages, far beyond their intended audience. The directory team rotates the password within an hour of her report.
9.4 Dependencies and supply
Lindiwe considers adding a third-party library to parse a log format. She checks who maintains it, when it was last updated and whether it has known vulnerabilities. She decides to write a small parser herself because the format is simple and the library is unmaintained. She learns that every dependency extends the code an organisation trusts, and that keeping security tools small reduces that exposure. Her parser is eighty lines long and covered by its own tests. Prof. Hale asks her to record the reasons for this choice in a short decision record.
Worked example
Lindiwe structures her tool into testable functions, adds unit tests with known cases, moves a leaked password to an environment variable and avoids an unmaintained dependency.
Synthetic case. Code is synthetic.
Errors and limits
A password committed to code must be treated as exposed and changed.
Exercises
- EX025 — Test module. Which module runs her tests? Rubric: 3 = unittest;; 2 = partly correct;; 1 = other;; 0 = none.
- EX026 — Secret storage. Where does the tool read credentials from? Rubric: 3 = an environment variable set by the scheduler;; 2 = partly correct;; 1 = code;; 0 = none.
- EX027 — Parser choice. Why write her own parser? Rubric: 3 = simple format, unmaintained library;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 09 (chapter 09 of 50)
← Chapter 08 · Course chapter index · Chapter 10 →
Continue to the next authored lesson.