Security review

Determine whether an attacker gains a capability across a trust boundary. Security vocabulary, secret-shaped data, or a broken lifecycle alone do not establish a vulnerability.

Read-only review needs source access. Active verification requires explicit authorization, a safe isolated target, and bounded test inputs.

Read the work-item manifest when one exists. Freeze the exact base, head, dirty state, stated security claim, deployment assumptions, and authorized verification scope. Never broaden active testing beyond the target and authority the user supplied.

1. Define the security claim

State what the issue or change claims to prevent, the protected property, and the expected attacker. Separate the original issue from observations discovered during review.

Complete when: the claim has an exact state, property, attacker, and scope.

2. Map the trust model

Create a compact map of assets, actors, principals, trust boundaries, entry points, privileges, and security-sensitive sinks. Include browsers, proxies, subprocesses, plugins, tenants, local users, remote users, and operators only when they exist in the system.

For every principal, record authority it already has. A secret reaching a process is not automatically exposure if that process already executes with equivalent authority or can read the source through existing permissions.