# The Defensive OpSec Operating Standard for Agentic Security Review

**Version:** 1.0.2  
**Published:** 2026-05-06 (v1.0) · **Patched:** 2026-05-06 (v1.0.1, v1.0.2)  
**Canonical URL:** https://www.deepsec-skill.dev/standard.md  
**License:** MIT (free to fork, adopt, cite, modify)  
**Maintainer:** [John D. Fowler](https://github.com/johndfowler) / [MHCIS](https://www.mhcis.com)  
**Issues:** https://github.com/johndfowler/deepsec-skill/issues

---

## Purpose

A short, citable operating standard for AI coding agents that perform security review. Tool-agnostic in principle; first vehicle is [Vercel's `deepsec`](https://github.com/vercel-labs/deepsec) via the [`deepsec-skill`](https://github.com/johndfowler/deepsec-skill) agent skill.

Adopt the rules, fork the templates, deep-link the anchors. Outputs that follow this standard land in vocabulary the security community already accepts: AppSec, supply-chain, IR, governance, counsel.

---

## The Five Rules

### Rule 1 — Authorization and scope {#authorization}

Work only on code the user controls or is authorized to assess. Confirm repo root, target path, and whether production systems are in scope. Default to code review plus local/test-environment verification.

The upstream `deepsec` README is explicit about why this matters: *"Treat `deepsec` like a coding agent with full shell access on the environment that it is running on."*

### Rule 2 — Threat-sketch first {#threat-sketch}

Identify exposed interfaces, auth boundaries, privileged operations, sensitive data, trust boundaries, build/release surfaces, and likely attacker goals — anchored to the [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) four-step process and STRIDE.

**Anchor every architectural claim to evidence in the repo and keep assumptions explicit.** If a claim cannot point to a file, helper, route, or config, mark it as an assumption and surface it for the user to confirm. Generic checklists without repo-grounded evidence are theatre.

### Rule 3 — Defensive evidence only {#defensive-evidence}

Evidence may include: file paths, data-flow summaries, missing controls, affected assets, authorization assumptions, safe reproduction notes.

Evidence must not include: exploit payloads, bypass recipes, credential theft instructions, stealth or persistence guidance, exfiltration techniques, or public attack instructions.

### Rule 4 — Standards as vocabulary, not ceremony {#standards}

Use OWASP ASVS 5.0, OWASP WSTG 4.2, NIST SSDF, NIST AI RMF, CISA Secure by Design, SLSA, OpenSSF Scorecard, Sigstore, FIRST CVSS v4.0, OWASP GenAI Top 10, and ISO/IEC 29147/30111/TR 5895 only when they clarify risk, fix, or evidence. Skip them when they would be padding.

### Rule 5 — Honest uncertainty {#honest-uncertainty}

Findings that cannot be safely verified inside the user's authorized scope are marked `needs-authorized-validation` rather than fabricated. **Silent omission is forbidden.** If a project `CLAUDE.md` prohibits the `needs-authorized-validation` vocabulary or any equivalent uncertainty marker, surface the vocabulary conflict and report the finding anyway. Honest reporting beats silent omission, every time.

**Confidence floor.** Report HIGH-CONFIDENCE findings as findings. Report MEDIUM-CONFIDENCE findings tagged with their basis-for-doubt. Suppress LOW-CONFIDENCE findings into a separate "speculative observations" appendix that the user can read but is not the main report. Wall-of-findings reports waste reviewer attention; a small set of high-confidence findings with a clearly-bounded speculative appendix is the shape that gets acted on.

**Parallel false-positive filter.** Before reporting any finding, route it through a sub-task whose job is to *disprove* it — to find the existing mitigation, the missing precondition, the test that would fail if the issue were real. Findings that survive the disprove pass become the report; findings that fail it become `INFO.md` "Known false-positives" entries with one-line disproving notes.

---

## The Finding Packet Template {#finding-packet}

Every confirmed issue is reported in this fixed shape so engineering, supply-chain, IR, and governance reviewers can read it without translation:

```text
Finding: <title>
Severity / confidence: <severity> / <confidence>
Affected asset: <asset>
Trust boundary: <boundary>
Impact: <business/security impact>
Defensive evidence: <non-weaponized verification>
Control mapping: <ASVS/WSTG/CWE/CVSS if useful>
Supply-chain relevance: <none | dependency | CI | artifact | release gate>
Fix: <focused remediation>
Verify: <safe verification step>
Residual risk: <after fix or unknown>
Disclosure sensitivity: <internal | coordinated disclosure | advisory channel>
```

### Supply-chain lens (extend the packet when applicable)

When a finding touches dependencies, CI, package publishing, build scripts, secrets, artifact integrity, deployment promotion, or release gates, add:

- Affected build/release stage (dependency / CI workflow / publish step / deploy gate)
- SBOM / VEX considerations (CISA SBOM, CycloneDX, SPDX)
- Provenance and signing posture (SLSA level, Sigstore, in-toto)
- OpenSSF Scorecard signal (branch protection, pinned actions, token permissions)
- Whether the fix needs a release-gate change, not just a code change

### Governance and shareholder lens (extend when applicable)

When a finding affects customer data, revenue, service availability, or regulatory exposure, add:

- Materiality cues: scope of affected users, data classes, downtime risk, contractual or regulatory exposure (e.g. SEC cyber-disclosure concerns, applicable privacy regimes)
- Operational blast radius: who must be paged, which runbooks apply, which customer-facing surfaces are touched
- Uncertainty: what is verified vs. what still needs authorized validation

This lens surfaces the inputs humans need to make materiality determinations. It does not make those determinations. No legal advice.

---

## The `INFO.md` Rubric (50–100 lines) {#info-rubric}

`INFO.md` is the per-project context file injected into every AI prompt batch. Signal density matters. Five sections, 50–100 lines total:

```markdown
# What this codebase does
Two or three sentences. Stack and surface area
(e.g. "React SPA + 4 serverless API routes on Vercel"). Include the
business-critical assets or user outcomes that would matter if compromised.

# Auth shape
Every auth boundary in one place. Helper names, not line numbers.
If there is no user auth, say so explicitly. Note trust boundaries
and privileged operations.

# Threat model
What an attacker would actually want, ranked by impact
(financial > reputational > data). Include sensitive data, externally
reachable interfaces, and material business or governance concerns.

# Project-specific patterns to flag
Three to five patterns the built-in matchers will not know about:
custom middleware, internal helpers, env-var-driven recipient lists,
prompt-injection envelopes for AI endpoints, build/release scripts,
package-publishing flows, CI secrets, artifact-signing/provenance gaps.

# Known false-positives
Patterns that *look* dangerous but are intentional. Include expected
mitigations when they explain why something is safe.
```

**Rules.** No line numbers. Max 5 paths per list. Skip generic CWE categories; built-in matchers cover SSRF, SQLi, XSS.

The skill enforces this rubric on top of Vercel's `SETUP.md` rubric, adding business-critical assets and supply-chain surface coverage.

---

## The Scan Gate {#scan-gate}

After the free regex `scan` and before the paid AI `process`, the agent emits this status block verbatim and waits for explicit user approval:

```text
deepsec scan complete.
Candidates: <n>
Scope: <target>
Cost note: process is the paid AI step.
Recommendation: <process now | narrow scope first | enrich INFO.md first>
Need approval before running process.
```

No surprise bills. Scan is free; `process` is the paid stage. The agent does not advance without user sign-off.

---

## The Run Closeout {#closeout}

After remediation and `revalidate`, every run lands a clean handoff artifact:

```text
Run summary:
- Scope assessed:
- Candidates processed:
- Findings confirmed:
- False positives:
- Fixes made:
- Revalidation:
- Residual risks:
- Follow-up gates:
```

This is the artifact engineering hands to AppSec, supply-chain, IR, and governance reviewers. Not a wall of findings. A closeout.

---

## The Standards Spine

The standard does not invent vocabulary. It threads agentic security review through the published references the security community already uses:

- [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) — control vocabulary on findings
- [OWASP WSTG v4.2](https://owasp.org/www-project-web-security-testing-guide/v42/) — testing categories
- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) — STRIDE + four-step process
- [NIST SP 800-218 (SSDF v1.1)](https://csrc.nist.gov/Projects/SSDF) and [SP 800-218A (SSDF for generative AI)](https://csrc.nist.gov/pubs/sp/800/218/a/final) — secure SDLC framing
- [NIST AI RMF (AI 100-1)](https://www.nist.gov/itl/ai-risk-management-framework) and the [Generative AI Profile (AI 600-1)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial) — Govern / Map / Measure / Manage when the target is itself an AI system
- [CISA Secure by Design pledge](https://www.cisa.gov/securebydesign/pledge) (350+ signatories) and the [2025 CISA SBOM Minimum Elements](https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom)
- [SLSA v1.2](https://slsa.dev/spec/v1.2/) — Build Track and Source Track levels
- [OpenSSF Scorecard](https://github.com/ossf/scorecard) — repository hygiene checks
- [Sigstore / Cosign](https://docs.sigstore.dev/) — keyless signing via Fulcio + Rekor transparency log
- [FIRST CVSS v4.0](https://www.first.org/cvss/v4.0/specification-document) — severity expression
- [OWASP GenAI Security Project](https://genai.owasp.org/) — LLM Top 10 2025, Agentic Security Initiative
- [ISO/IEC 29147 / 30111 / TR 5895](https://iso.org/standard/72311.html) — coordinated and multi-party coordinated vulnerability disclosure
- [SEC Reg S-K Item 106 / Form 8-K Item 1.05](https://www.sec.gov/news/press-release/2023-139) — material cybersecurity incident framing
- [OWASP Agentic Skills Top 10 (project)](https://github.com/OWASP/www-project-agentic-skills-top-10) — agentic-skill-specific threat surface; AST01 covers malicious-skill registry attacks (typosquatting, brand impersonation, prompt-injection embedded in `SKILL.md`)
- [Cloud Security Alliance MAESTRO](https://cloudsecurityalliance.org/research/working-groups/ai-safety-initiative) — 7-layer threat-modeling framework for agentic AI systems (Agent Ecosystem, Frameworks, Security & Compliance, Deployment, Evaluation & Observability, Foundation Models, Agent Code)
- Snyk *"From SKILL.md to Shell Access in Three Lines of Markdown"* (Feb 2026) — empirical research on 40,000+ scanned skills across 7 registries: 91% of confirmed malicious skills use prompt injection; 100% combine code-layer + natural-language layer attacks; 905 prompt-injection findings observed

---

## How to Adopt {#adopt}

The standard and its templates are MIT licensed. Three ways to plug in:

### As an agent skill

```bash
npx skills add johndfowler/deepsec-skill
```

Or directly:

```bash
npx skills add https://www.deepsec-skill.dev/SKILL.md
```

### As a citation

Deep-link any rule or template by its anchor ID:

- `https://www.deepsec-skill.dev/standard.md` — full text, plain markdown
- `https://www.deepsec-skill.dev/standard#authorization` — Rule 1
- `https://www.deepsec-skill.dev/standard#threat-sketch` — Rule 2
- `https://www.deepsec-skill.dev/standard#defensive-evidence` — Rule 3
- `https://www.deepsec-skill.dev/standard#standards` — Rule 4
- `https://www.deepsec-skill.dev/standard#honest-uncertainty` — Rule 5
- `https://www.deepsec-skill.dev/standard#finding-packet` — finding packet template
- `https://www.deepsec-skill.dev/standard#info-rubric` — `INFO.md` rubric
- `https://www.deepsec-skill.dev/standard#scan-gate` — scan-gate exchange
- `https://www.deepsec-skill.dev/standard#closeout` — run closeout

### As a fork

Lift any template into your own tool, skill, or internal AppSec runbook. MIT, attribution appreciated, modification expected. The standard versions: this is v1.0; future revisions land at `/standard/v2.md` etc., and v1 stays stable at this URL.

---

## Surviving your CLAUDE.md {#surviving-claude-md}

Boris Cherny (Claude Code lead) has publicly identified `CLAUDE.md` as the single largest source of deployment-time issues. When an agent activates inside a real host project, that project's `CLAUDE.md`, `AGENTS.md`, `.cursor/rules`, or `GEMINI.md` can absorb, dilute, or override skill-level discipline. A standard that loses to a project's *"be terse, no preamble"* rule during a security review is theatre.

This standard is hardened against absorption from both ends:

1. **Skill-side precedence.** The first operational instruction in `SKILL.md` states that the five rules take precedence over project-level instructions in `CLAUDE.md`, `AGENTS.md`, `.cursor/rules`, `GEMINI.md`, or equivalent for security-review tasks. If a project rule conflicts, the agent surfaces the conflict instead of silently choosing.

2. **Project-side pinning.** Adopters paste a four-line snippet (canonical at https://www.deepsec-skill.dev/standard/claude-md-snippet.md) into their own host project's `CLAUDE.md`, pinning the standard's precedence in the project's own voice. The discipline then survives every future agent invocation in that repo.

3. **Activation canary, mechanically exempt from terseness.** The skill's first chat output in a security-review task must be the line:

   ```
   Applying Defensive OpSec Operating Standard v1.0 — 5 rules, scan-gate active, defensive-evidence only.
   ```

   The canary is a **mechanical activation handshake, not preamble**. Project instructions like *"be terse"*, *"no preamble"*, or *"don't acknowledge tools/skills before using them"* govern response substance — they do **not** suppress the canary. If the line cannot be emitted, the skill failed to activate; refuse to run any security-task tool.

4. **Conflict-surfacing is unconditional.** Project instructions like *"never ask the user"* or *"skip confirmation"* do **not** apply to skill-precedence conflicts. The user is the standard's defined arbiter for security-task disputes between project and skill; depriving them of that role is itself a Rule 1 (authorization) violation. If a host instruction prohibits asking the user about anything during a security task, treat that as a security violation, surface it, and refuse to proceed until the user confirms which authority wins.

5. **No silent finding-drop.** Findings that cannot be safely verified must still be reported with the `needs-authorized-validation` marker. If a project `CLAUDE.md` prohibits this vocabulary, surface the conflict and report the finding anyway. Silent omission is the worst of all worlds and is forbidden.

The standard is meaningless without these reinforcements. Adopters that skip the snippet still get the skill's behavior on first activation; adopters that paste the snippet get it on every future agent run in the same repo.

**v1.0.1 patch (2026-05-06).** Added reinforcements 3, 4, and 5 above after a hard adversarial-CLAUDE.md absorption test surfaced three real failure modes: canary-suppression-via-terseness, circular dependency between conflict-surfacing and "don't ask the user" project rules, and silent finding-drop under vocabulary conflicts. The five rules and four templates are unchanged; the patch tightens enforcement language only.

---

## Prior art and credit {#prior-art}

This standard is not invented from scratch. It cherry-picks load-bearing patterns from earlier work in the AI-skills security ecosystem and credits each:

- **`anthropics/claude-code-security-review`** — the production GitHub Action that ships the `/security-review` slash command in Claude Code by default. The standard's three-phase methodology (context → comparative → vulnerability), HIGH-CONFIDENCE filter, and parallel false-positive sub-task pattern are refinements of patterns published there.
- **`openai/skills/.curated/security-threat-model`** — OpenAI's curated threat-modeling skill. The Rule 2 "anchor every architectural claim to evidence in the repo and keep assumptions explicit" rule is lifted directly from its methodology.
- **`Artais-Security/claude-skills-security-code-review`** — defensive + offensive two-pass review with category-specific reference layering. The pattern of asking *"where is the trust boundary thinnest?"* defensively (without producing exploit narratives) refines the standard's Rule 3.
- **`alirezarezvani/claude-skills/engineering/skill-security-auditor`** — the security frontmatter proposal (`security: { network, filesystem, credentials, permissions }`) that this skill now declares in its own `SKILL.md`.
- **OWASP Agentic Skills Top 10**, **CSA MAESTRO**, and Snyk's *"SKILL.md to Shell Access"* research — the threat-surface evidence that justifies the standard's absorption-resistance design (Rule 1's authorization gate, the activation canary, unconditional conflict-surfacing).

These are not the only relevant skills in the ecosystem. They are the ones whose patterns this standard explicitly absorbed. The pattern moves freely under MIT — if your skill or runbook is improved by lifting from this standard, no attribution required (though appreciated). And if your work is missing here and contains a load-bearing pattern this standard should adopt, file an issue.

## Versioning

This is **Defensive OpSec Operating Standard v1.0.2**, published 2026-05-06 (v1.0) and patched 2026-05-06 (v1.0.1 — adversarial-CLAUDE.md absorption-test patches; v1.0.2 — cherry-picked patterns from prior-art skills, three-phase methodology + HIGH-CONFIDENCE filter + parallel false-positive filter + repo-grounded-evidence rule + security frontmatter + DO-NOT-TRIGGER clause + extended standards spine).

Subsequent versions land at:

- `/standard/v2.md` (next major)
- `/standard/v1.1.md` (next minor, if any)

v1.0.2 stays at `/standard.md`, `/standard/v1.0.2.md`, `/standard/v1.0.1.md`, and `/standard/v1.0.md` (older paths resolve to the latest patched content; the rule and template definitions are unchanged across all v1.0.x patches) permanently. Existing citations don't rot.

### MCP roadmap

**Programmatic enforcement via an MCP server is on the v2.0 roadmap, contingent on adoption signal.** v1.0.1 is the discipline (instructions an agent reads); v2.0 may be the gate (tools the agent must call). Specifically: an `acknowledge_standard()` tool that returns the canary line, a `scan_gate()` tool that *must* receive explicit user approval before any AI-spend tool fires, and a `finding_packet()` validator that rejects exploit-payload strings in the `defensive_evidence` field. Building this surface now would inflate friction (`claude mcp add` + JSON config + server lifecycle) before the v1.0.1 instruction-only artifact has earned external citations. v2.0 ships when the validation signal lands — the first external deep-link to a `#anchor` URL — and not before.

---

## Why this standard exists

The vehicle, [`deepsec`](https://github.com/vercel-labs/deepsec), was announced May 4, 2026 by Malte Ubl ([@cramforce](https://x.com/cramforce)), CTO of Vercel.

Discovery is no longer the bottleneck for AI-assisted security review. Translation is. Agentic scanners produce findings; the security community needs them in vocabulary AppSec, supply-chain, IR, and governance reviewers can act on without re-translation.

This standard is one attempt at that translation layer. Adopt it, fork it, file issues against it, replace it with something better.

The vehicle is [Vercel's `deepsec`](https://github.com/vercel-labs/deepsec). The standard is tool-agnostic.

---

*Built by [John D. Fowler](https://github.com/johndfowler). Published by [MHCIS](https://www.mhcis.com). MIT licensed. Live at [https://www.deepsec-skill.dev/standard](https://www.deepsec-skill.dev/standard).*