Chapter 5 — Security scope and evidence
Lesson map
Lesson 05 published. Map, example, EX017.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Writing a scope"]
N2["5.2 Reproducible evidence"]
N3["5.3 Secrets found during work"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX017"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Writing a scope"]
N2["5.2 Reproducible evidence"]
N3["5.3 Secrets found during work"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX017"]
[Learning outcomes]
|
v
[5.1 Writing a scope]
|
v
[5.2 Reproducible evidence]
|
v
[5.3 Secrets found during work]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX017]
Learning outcomes
You will (1) write a scope statement for cryptographic checks; (2) collect evidence that another technician can reproduce; (3) handle secrets found during work.
5.1 Writing a scope
Before Tomás scans anything, Priya makes him write a scope. It names the systems he may test, such as the tracking portal and the file-transfer host; the checks he may run, such as handshake tests and certificate reads; the time window; and the person who approved it. Scanning a partner's server or a payment provider without their permission is out of scope even if it is technically easy. A scope protects the company, the partners and Tomás himself, because an unapproved scan can trigger alarms, break fragile devices or breach a contract.
5.2 Reproducible evidence
When Tomás finds a weak setting, a screenshot alone is poor evidence. Priya teaches him to record the exact command, the date and time with time zone, the host he ran it from, the raw output and a SHA-256 digest of any saved file. Another technician should be able to rerun the command and see the same result, or explain why it changed. Good evidence also records what was not checked, so readers do not assume more coverage than exists. This habit makes later reports, audits and change requests much faster, because nobody has to ask how a claim was obtained.
5.3 Secrets found during work
During reviews Tomás will see passwords, API tokens or private keys in places they should not be. The rule is to stop, record only the location and type of secret, never copy the value into notes or tickets, and tell the owner so the secret can be rotated. Evidence should show that a secret exists, for example by recording the file path and the first characters of a hash of the value, not the value itself. Handling secrets this way prevents the investigation from spreading the very exposure it was meant to fix.
Worked example
Tomás writes a one-page scope for portal and file-host TLS checks, records one finding with command, timestamp and output digest, and logs a leaked token by path only.
Synthetic case. Scope details, hosts and the token finding are invented.
Errors and limits
A scope does not make a risky test safe; production checks still need care. Evidence can be stale within hours as systems change.
Exercises
- EX017 — Out-of-scope target. Is scanning the payment provider's API in scope by default? Rubric: 3 = no; it needs the provider's explicit permission and contract terms;; 2 = says no;; 1 = says yes;; 0 = none.
- EX018 — Evidence fields. List four fields a reproducible finding should include. Rubric: 3 = four of command, timestamp with zone, source host, raw output, file digest, what was not checked;; 2 = three;; 1 = one;; 0 = none.
- EX019 — Token in a script. You find an API token in a shell script. What do you record? Rubric: 3 = location and type only, not the value; notify owner for rotation;; 2 = location;; 1 = copies value;; 0 = none.
- EX020 — Coverage statement. Why record what was not checked? Rubric: 3 = so readers do not assume more coverage than exists;; 2 = mentions readers;; 1 = no reason;; 0 = none.
Synthesis
Scope limits what may be tested, evidence makes findings reproducible, and secrets are reported without being copied.
Continue studying — chapter 05 of 18
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →