security-review

A specialisation of the parent engine.

Sub-case: security review

A specialisation of the parent engine. The anchor changes, and one refutation rule is inverted relative to correctness — read that section before running this sub-case alongside another.

Anchor: source → trust boundary → sink, with an attacker who controls the source.

The agreement being tested is between what a component trusts and what an attacker can supply. Where correctness asks "can this happen", security asks "can someone make this happen on purpose" — and an adversary will construct the unlikely execution deliberately.

Where the procedure lives

/security-audit-static owns the full specialised procedure — entry-point mapping, the four high-value paths, the keep/drop rule with its attacker-and-victim test, the OWASP Top 10 coverage backstop, and the high-miss checklist. Run it rather than restating it. This file exists to say what changes when security is selected as a dimension of a code review, and to supply the part of the engine that survives when the application has no web surface at all.

The universal core

Applies to a CLI, a library, a daemon, a build tool — anything without an HTTP handler in sight.

• Trust boundaries — every point where data crosses from a less-trusted origin into a

more-trusted context: arguments, environment, config files, stdin, filenames, archive members, network responses, plugin and extension surfaces, deserialised state, and model output.

• Sinks — where a value becomes an instruction rather than data: process execution, dynamic

evaluation, query construction, path resolution, template rendering, deserialisation, outbound requests, permission and role writes, and logging.

• Injection by representation confusion — a value interpreted in the syntax of the sink rather

than as an opaque datum. Encode for the sink, not at the input. This is the same disagreement as correctness lens 10 (representation and information loss), with an adversary steering it.

• Validator/consumer differentials — the check and the use disagree about what the value means:

unanchored patterns, prefix allowlists, normalisation applied on one side only, validation on one representation and execution on another.

• Fail-open paths — error, timeout, cancellation, cache-miss and boundary branches that default

to allow. Correctness lens 12 finds these; security decides what they cost.

• Secrets and sensitive data in transit to the wrong place — logs, traces, error bodies,

temporary files, crash dumps, and anything an unprivileged local user can read.

• Privilege and identity — which principal an operation runs as, whether the check and the action

name the same object, and what happens when they do not.

The inverted refutation rule

Under correctness, a defect that harms only the person who triggered it is still a defect. Under security it usually is not a finding: if the only victim is the attacker, on their own machine, account, tenant or data, and no shared system or privilege boundary is crossed, drop it.

The carve-outs where that refutation is forbidden — outbound-network sinks, shared billing or quota, data exposure, cross-tenant or cross-principal flows, and server-side execution or rendering — are listed in /security-audit-static. Use its list; do not reinvent one.

Do not let the two rules leak into each other. Running both dimensions in one review, keep the tests separate per finding: a defect dropped as a security finding may still be a correctness finding with a real consequence, and should be reported as one.

What makes a security finding

The parent skill's five requirements, with the trigger read adversarially:

1. A supported obligation — the trust assumption, and what establishes it.
2. A feasible execution — including who the attacker is and what they control.
3. A concrete contradiction — the boundary that fails to hold.
4. An observable consequence — naming the victim, who must not be only the attacker.
5. An examined counterargument — a real check at the sink, an unreachable path, an upstream

validator, or a non-dangerous sink.

Findings are code-review results, not confirmed exploits. Say so.