Chapter 8 — Programming II
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Functions and structure"]
N2["8.2 Testing"]
N3["8.3 Regular expressions"]
N4["8.4 Safety in tools"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Functions and structure"]
N2["8.2 Testing"]
N3["8.3 Regular expressions"]
N4["8.4 Safety in tools"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Functions and structure]
|
v
[8.2 Testing]
|
v
[8.3 Regular expressions]
|
v
[8.4 Safety in tools]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) structure larger scripts; (2) test functions; (3) process text records safely.
8.1 Functions and structure
As scripts grow, Priya splits them into functions that each do one job: reading input, parsing a line, classifying a record and printing a summary. Small functions are easier to test and reuse. A function that parses a log line, for example, can be tested on a handful of examples, including malformed ones, before it is trusted on a full file. She names functions after what they do, such as parse_line or in_subnet, so the main part of the script reads almost like a description of the analysis.
8.2 Testing
A test runs a function on known input and checks the output. Priya writes tests for the subnet check: an address inside the range, one just outside, the network address itself and an invalid address. Edge cases like these catch most mistakes. Python's built-in unittest module or simple assert statements are enough for course labs. Tests are kept with the script, so anyone changing it can rerun them and see whether behaviour changed, which is the same principle as regression testing of firewall rules later in the course.
8.3 Regular expressions
Logs and configuration files are text, and regular expressions describe patterns in text, such as a priority number in angle brackets at the start of a syslog line. They are powerful but easy to get wrong: a pattern that is too loose matches lines it should not, and one that is too strict rejects valid lines. Priya anchors patterns to the start of the line where possible, tests them against examples of both valid and invalid input, and keeps them simple enough to read. Complex patterns are split into named parts.
8.4 Safety in tools
Security scripts often handle untrusted data, such as logs containing text supplied by users or attackers. Priya never passes such text to a shell or evaluates it as code, and she treats unexpected values as data to be reported, not instructions. She avoids writing to files outside the working directory and does not need network access for any lab. These habits keep analysis tools from becoming a weakness themselves, which matters because tools run with the analyst's permissions and can do harm if misled by crafted input.
Worked example
Priya's tested in_subnet function passes four cases: inside, just outside, network address and an invalid string that raises a clear error.
Synthetic case. All test data are synthetic.
Errors and limits
Regular expressions tested only on valid input often accept malformed lines silently.
Exercises
- EX022 — Edge case choice. List three edge cases for testing a subnet membership function. Rubric: 3 = inside, just outside, network address or invalid;; 2 = two;; 1 = one;; 0 = none.
- EX023 — Regex anchoring. Why anchor a log-parsing pattern to the start of a line? Rubric: 3 = prevents matching text embedded elsewhere;; 2 = accuracy;; 1 = speed;; 0 = none.
- EX024 — Untrusted text rule. What must never be done with text read from logs? Rubric: 3 = pass to shell or evaluate as code;; 2 = run it;; 1 = print it;; 0 = none.
Synthesis
Functions, tests and careful text handling make analysis scripts trustworthy.
Continue studying — chapter 08 of 40
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →