---
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 **default-deny**: 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 `security-scan`, `gateguard`, and `safety-guard` enforce.

Everything below is an application of this one model to a different surface.

## 2. The surface map (posture × surface)

|  | **Defend** (prevent) | **Attack** (discover) |
|---|---|---|
| **Code** | `security-review` | `security-bounty-hunter` |
| **Agent config** (`.claude/`) | `security-scan` | — *(audit findings feed back to review)* |
| **Source tree / supply chain** | `repo-scan` | `repo-scan` (embedded-dep CVEs) |
| **Live runtime** (agent actions) | `gateguard`, `safety-guard` | — |

Pick the cell, not just the keyword. "Secure my agent project" spans the config row
(`security-scan`) and the code row (`security-review`); a full-auto run also needs the runtime
row (`safety-guard`).

## 3. Severity & exploitability conventions

Rank every finding the same way, so spokes agree:

- **In-scope, high-signal** — reachable from a real user/network boundary, input genuinely user-controlled, sink meaningful (RCE, auth bypass, SSRF→metadata, SQLi, path traversal, auto-triggered XSS, leaked secret, destructive op). Map to a CWE where possible.
- **Out-of-scope / low-signal** — local-only `pickle`/`torch.load`, `eval` in CLI-only tooling, `shell=True` on hardcoded commands, missing-header-only, generic rate-limit gripes, self-XSS, demo/test/fixture code. Drop unless the program scope says otherwise.
- **Static tooling is triage input, not a verdict.** A scanner hit is a lead; confirm the path end-to-end and the smallest safe PoC before it counts.

## 4. Shared conventions

- **Secrets** live in env / a secret manager, never in source; verify presence at startup; redact in logs and in any schema you display.
- **Validate at the boundary** — never trust the client/webview/prompt; validate on the privileged side.
- **State every grant** — a new permission, scope path, allowed host, or a disabled gate is a decision worth naming in the output.
- **Reachability before refactor** — for `repo-scan`, an outdated *vendored* dependency is only urgent if it sits on a reachable path; classify ownership first.
- **Reports are reproducible** — pin the version/commit tested, give file:line, and a minimal PoC (offensive) or a concrete fix (defensive).

## 5. Tooling matrix

| Surface | Spoke | Primary tooling | Mechanism |
|---|---|---|---|
| Code (defend) | `security-review` | manual checklist + grep/read | review-time |
| Code (attack) | `security-bounty-hunter` | `semgrep --config=auto` (triage) + manual path proof | discovery |
| Agent config | `security-scan` | `ecc-agentshield` (`scan`, `--fix`, `--format json/html`, CI action) | static + optional adversarial pass |
| Source tree | `repo-scan` | cross-stack classifier (`fast`/`standard`/`deep`/`full`) | inventory + verdicts |
| Runtime (investigate) | `gateguard` | PreToolUse hook (deny → force → allow) | fact-forcing gate |
| Runtime (contain) | `safety-guard` | PreToolUse hook (careful / freeze / guard modes) | destructive-op + write lock |

Hooks (`gateguard`, `safety-guard`) are PreToolUse-based and intercept Bash/Write/Edit/MultiEdit;
both expose an off switch and log blocked actions — keep them on for autonomous sessions.

## 6. Shared guardrails

- **Default-deny**: narrowest permission/scope/allowlist that works; per-target over global.
- **Exploitability over theory**: rank by reachable-source → meaningful-sink, not pattern count; drop local-only and out-of-scope noise.
- **Boundary is sacred**: validate all input on the trusted side; the client/webview/prompt is untrusted.
- **No silent weakening**: disabling a gate, widening a scope, or adding a host is a stated change.
- **Contain first in autonomy**: `gateguard` to force investigation, `safety-guard` to cap blast radius, before granting broad write/exec.
- **Reproducible findings**: pin version/commit, give file:line, and a minimal PoC or concrete fix.