# Security Review of a Change Reviews a change for the exposure it adds — every finding traced to a path that is actually reachable, and every suspicion reported as a suspicion. ## Deliverable One Markdown document, `security-review.md`, in the structure set out under **Output** below. It takes the boundaries drawn by **Threat Modelling** and returns a decision the release can carry. ## Required inputs - **The change set** — the diff, patch or branch under review, complete rather than summarised. - **What the change touches** — the components, data and interfaces it reaches, and which of them sit on a trust boundary. - **The code the change lands in** — enough of the surrounding system to trace a changed line to the path that reaches it. If any is absent, report it as missing and review only what the supplied material supports. A diff read without the code around it shows what changed, not what the change exposes. ## Optional inputs - The threat model, or any record of where the trust boundaries run - The authorisation design: the roles, the scopes, and where each is enforced - Logging, error-reporting and monitoring configuration - Infrastructure and configuration changes shipping alongside the code - The tests that cover the changed paths, and what they assert - The reason for the change, in the author's own words Absent optional inputs narrow what can be concluded, never what is claimed. Where reachability cannot be established from the material supplied, the finding is filed under **Needs verification**. ## Execution **1 — Establish what the change reaches.** From the diff, list the files, entry points, data stores and outbound calls it touches. For each, the path that reaches it and whether that path crosses a trust boundary. A change that touches nothing on a boundary is still reviewed, and the review says that is what it found. **2 — Follow the input.** For every value the change accepts from outside a boundary, trace it to where it is used: a query, a command, a path, a template, a redirect, a deserialiser, a response. Record where it is validated, where it is encoded for its destination, and where it is neither. **3 — Check authorisation on every path, not every route.** For each operation the change adds or alters: who may call it, where that check is made, and whether every path into the operation passes through it. The common defect is not a missing check but a second path that reaches the same operation around the check that exists. **4 — Look for secrets and credentials.** Keys, tokens, passwords, connection strings and private material in the diff, in configuration, in fixtures, in test data, and in anything the build embeds. Record each with its file, and whether it reaches a build artefact or the repository history. **5 — Read what the change writes out.** Logs, error responses, stack traces, analytics events and support tooling. Record every field that leaves the system carrying user data, credentials, internal addresses, or the details of a failure that an outsider should not receive. **6 — Account for the new surface.** What the change makes publicly reachable that was not, what permission it widens, what default it changes, and what dependency it adds. A dependency added here is named and handed to **Dependency & Supply-Chain Audit** rather than assessed in passing. **7 — Write each finding with its path and its fix.** Per finding: the file, the condition under which the path is reached, what an attacker gains at that point, the severity and the reason for it, and the specific change that closes it. A finding that cannot be traced to a reachable path goes under **Needs verification** with the step that would settle it. ## Output `security-review.md`, in this order: - **1. Change under review** — what was reviewed, from which material, by whom, and when - **2. Surface touched** — the files, entry points and data the change reaches, and which cross a boundary - **3. Findings** — per finding: file, the condition that reaches it, impact, severity and its reason, and the fix - **4. Needs verification** — suspected issues with no traced path, each with the step that would settle it - **5. Input handling** — per external value: where it enters, where it is validated, where it is encoded - **6. Authorisation** — per added or altered operation: the check, its location, and every path that reaches it - **7. Secrets and output** — credentials found, and every field the change writes to logs or errors - **8. New surface and dependencies** — what became reachable, what widened, what was added - **9. Not reviewed** — what the supplied material did not cover, and what that leaves unknown ## Validation The review is ready when all of these hold: - Every finding in section 3 names a file and the condition that reaches it - Every finding in section 3 carries a fix a developer can apply, not a principle - Every suspicion without a traced path is in section 4 rather than section 3 - Every operation the change adds appears in section 6 with its check or with `no check found` - Section 7 states that no credential was found where none was, rather than being left empty - Section 9 is either non-empty or states that the material covered the whole change Fail the run if a finding is stated as exploitable without a reachable path, or if a severity is assigned without the impact that justifies it. ## Failure handling - **No change set supplied** — stop. Report that there is nothing to review, and that reviewing the current state of a file is a different job under a different name. - **No access to the surrounding code** — review the diff alone, place every finding that depends on reachability in section 4, and state that no path was traced. - **The change is too large to review as one unit** — split it by surface, review each part, and report which parts were reviewed and which were not. Never sample a diff and present the result as coverage. - **The author's account and the code disagree** — review the code, record the stated intent beside it, and raise the difference as a finding about the change rather than about the author. - **A finding cannot be reproduced** — keep it in section 4 with what was observed and what is needed to confirm it. A suspicion recorded honestly gets investigated; one stated as fact gets argued about and then dropped.