security-core

name	security-core
description	Shared reference for the security cluster: the trust-boundary model (untrusted input/action → privileged sink), the defend-vs-attack × code/config/runtime surface map, severity & exploitability conventions, and the tooling matrix every security spoke shares. USE WHEN triaging a finding, judging whether something is exploitable, or deciding which control to apply — the interlocking rules behind all six spokes.
cluster	security
version	1.0.0

Security Core

Shared model for the security cluster. The review, hunting, scanning, and guard spokes all turn on the same one idea — keep it consistent here so no spoke contradicts another.

1. The decision this cluster turns on: the trust boundary

Every security question reduces to one thing: can attacker-controlled input or action reach a privileged sink, and what contains it?

Untrusted source ──reaches──> Sink (privileged effect) ──contained by──> Control (default-deny)
   user input / network /         filesystem, exec, SQL,           capability, scope, allowlist,
   webview / agent prompt         secrets, deploy, money           gate, freeze

• A finding is real only when a path connects an untrusted source to a meaningful sink. No reachable path → informational, not exploitable. This is the line security-bounty-hunter draws and the lens security-review reviews against.
• A control is sound when it is : the narrowest grant that still works, with any widening (new host, new path, new permission, a disabled gate) treated as a stated security change — never silent. This is what , , and enforce.