gateway-security

name	gateway-security
description	Security capability gateway. Cross-cutting security concerns that apply regardless of platform. Activates on any target tagged with security-sensitive characteristics. Catches vulnerabilities that CLI, Web, and API/Service platform modules do not surface — git history exposure, cryptographic weaknesses, SAST findings, secrets in source, and cross-service trust failures.

Gateway: Security

You are the cross-cutting security layer. You activate on top of (not instead of) the active platform package. Platform modules handle platform-specific threats. This gateway handles threats that apply regardless of platform: secrets in git history, weak cryptography, insecure randomness, SAST findings, and cross-boundary trust failures.

What this skill does

Concern	Covered by L3 platform	Covered by L4 gateway
Shell injection	CLI platform	—
XSS / CSRF	Web platform	—
SQL injection	API/Service platform	—
Auth bypass	API/Service platform	—
Secrets in git history	No L3 module	Yes
Weak cryptographic algorithms	No L3 module	Yes
Insecure randomness (security use)	No L3 module	Yes
SAST findings (Semgrep / Bandit / CodeQL)	No L3 module	Yes
Hardcoded secrets in source	No L3 module	Yes
Cross-service trust (blind data acceptance)	No L3 module	Yes
Encryption at rest (DB, file)	No L3 module	Yes
TLS configuration (cipher suites, cert management)	No L3 module	Yes

When to use

• Any target at L4 complexity or higher (declared by Recipe)
• Any target with tags: security, authentication, payments, PII, secrets
• Budget-gated for lower complexity: activation costs one adversarial review cycle

Activation sequence

Phase A (Specify time — knowledge injection)

1. Confirm platform package (L3) has already activated and written its receipt
2. Load references/ directory into Specify context:
   - references/threat-modeling.md (STRIDE, trust boundaries, threat format)
   - references/owasp.md (Top 10, API Top 10, ASVS baseline)
   - references/continuous-security.md (SAST, secret scanning, pentest scoping)
   - references/compliance.md (GDPR, SOC2, HIPAA, PCI-DSS — load relevant sections)
3. Run STRIDE analysis on the task
4. Produce security requirements as acceptance criteria in the spec
5. Write gateway-spec-receipt (Phase A)

Phase B (pre-Executor — verdict)

1. Load threat-model.md (cross-cutting threats)
2. Load vulnerability-patterns.md (code patterns to grep for)
3. Load controls.md (required controls not covered by L3)
4. Register audit-gates.md with Verifier (supplements platform gates — does not replace them)
5. Write gateway-verdict-receipt (Phase B: PASS / FLAG / BLOCK)

Security review follows this 3-phase sequence before producing the PASS/FLAG/BLOCK verdict:

• Phase 1 — Context Research: Identify existing security frameworks and libraries in use; examine established secure coding patterns; understand the project's security model and trust boundaries
• Phase 2 — Comparative Analysis: Compare code changes against existing secure patterns; identify deviations from established secure practices; flag code that introduces new attack surfaces
• Phase 3 — Vulnerability Assessment: Trace data flow from user inputs to sensitive operations; look for privilege boundaries crossed unsafely; identify injection points and unsafe deserialization

Apply the Hard Exclusions and Precedents from ## False-Positive Filtering before issuing any verdict.

Security verdicts (BLOCK, CRITICAL, CVE) must be written in full prose regardless of any active output-compression mode. See homowabian auto-clarity rule.

Runtime permission model (informational)

Gateway-security concerns apply at spec and verification time. The runtime permission system operates separately at execution time. Key facts relevant to security analysis:

• Mode bypassPermissions auto-approves all tool calls including destructive operations. Flag any task configuration that activates this mode as a security concern.
• Policy settings (MDM/enterprise deployment) have highest authority and cannot be overridden by any session grant, project setting, or hook.
• Hook-based permission decisions (PreToolUse → permissionDecision: "deny") are the correct mechanism for security-enforcing hooks. Informational hooks (like WabbleSpec's prompt-guard) do not make permission decisions.
• Classifier (auto mode): A transcript-aware classifier can auto-approve or auto-block tool calls. transcriptTooLong and unavailable classifier results fall back to normal prompting rather than fail-closed — document this as a residual risk in threat models for security-sensitive deployments.
• Rule source priority: policySettings > flagSettings > cliArg > command > session > localSettings > projectSettings > userSettings.

Full permission decision tree: .wabblespec/engine/shared/references/permission-flow.md.

Red/Blue/Purple cycling (activated via /security-cycle or /security-red)

Phase A: Intel — references/cycling/security-profile.md (Recon + Surface + Context)
Phase B: Red  — references/cycling/red-protocol.md (attack)
Phase C: Blue — references/cycling/blue-protocol.md (defend)
Phase D: Purple — references/cycling/cycle-protocol.md (score + decision; 9-component model)

InferenceGuard integration

InferenceGuard (L2) activates automatically when gateway-security is active. It prevents false refusals during Red-phase PoC generation and vulnerability analysis.

• Red protocol: InferenceGuard active, tier=standard, technique=leetspeak (configurable in security-profile)
• Blue protocol: InferenceGuard SUPPRESSED — task card must declare inference_guard: false
• Purple scoring: 9th component (inference quality, 5%) reads inference_guard_summary.refusal_count from Red receipt

Override tier/technique in the security profile header fields: InferenceGuard tier and InferenceGuard technique.

False-Positive Filtering

Apply these rules when assessing security findings before issuing a verdict. Both sub-sections are mandatory gates — a finding excluded by either list must not appear in the output.

Hard Exclusions (17 items)

Automatically exclude findings that describe any of the following:

1. Denial of Service (DOS) vulnerabilities, even if they allow service disruption
2. Secrets or sensitive data stored on disk (handled by other processes)
3. Rate limiting or resource exhaustion issues
4. Memory consumption or CPU exhaustion issues
5. Lack of input validation on non-security-critical fields without proven security impact
6. Input sanitization concerns for GitHub Action workflows unless clearly triggerable via untrusted input
7. A lack of hardening measures — only flag concrete vulnerabilities
8. Race conditions or timing attacks that are theoretical rather than practical issues
9. Vulnerabilities related to outdated third-party libraries
10. Memory safety issues in Rust or any other memory-safe language
11. Files that are only unit tests or only used as part of running tests
12. Log spoofing concerns — outputting un-sanitized user input to logs is not a vulnerability
13. SSRF vulnerabilities that only control the path (only a concern if controlling host or protocol)
14. Including user-controlled content in AI system prompts is not a vulnerability
15. Regex injection — injecting untrusted content into a regex is not a vulnerability
16. Regex DOS concerns
17. Insecure documentation — do not report any findings in .md files; a lack of audit logs is not a vulnerability

Precedents

These are explicit non-vulnerabilities rooted in how frameworks and runtimes actually work:

1. Logging high value secrets in plaintext IS a vulnerability. Logging URLs is assumed to be safe.
2. UUIDs can be assumed to be unguessable. If a vulnerability requires guessing a UUID, it is not valid.
3. Environment variables and CLI flags are trusted values. Any attack relying on controlling an env var is invalid.
4. Resource management issues such as memory or file descriptor leaks are not valid.
5. Tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless extremely high confidence.
6. React and Angular are generally secure against XSS. Do not report XSS unless using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar unsafe methods.
7. Most vulnerabilities in GitHub Action workflows are not exploitable in practice. Require a concrete and very specific attack path before including.
8. Lack of permission checking or authentication in client-side JS/TS code is not a vulnerability — server-side validates all inputs.
9. Only include MEDIUM findings if they are obvious and concrete issues.
10. Most vulnerabilities in ipython notebooks (.ipynb) are not exploitable in practice. Require a concrete and very specific attack path where untrusted input triggers the vulnerability.
11. Logging non-PII data is not a vulnerability. Only report logging vulnerabilities if they expose secrets, passwords, or PII.
12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice. Only report if there is a concrete and very specific attack path for untrusted input.

Defense-in-Depth Pattern for Data Access

When reviewing code that accesses databases or structured data stores, verify that three independent protection layers are present. Absence of a single layer is not automatically Critical — absence of all three is.

Layer 1 — Connection-level enforcement (primary): The database connection itself is opened in read-only mode where the driver supports it. Examples: PostgreSQL readonly=True, MySQL SET SESSION TRANSACTION READ ONLY, SQL Server db_datareader role. Hardest to bypass because it operates below application code.

Layer 2 — Allowlist query validation: Before executing any query, the code validates it matches an allowlist of permitted statement types (SELECT, SHOW, EXPLAIN, WITH). INSERT, UPDATE, DELETE, DROP, TRUNCATE are rejected. Single-statement enforcement: compound inputs containing multiple statements (; delimiter) are also rejected.

Layer 3 — Secondary controls: Even with layers 1 and 2, verify:

• Query timeout enforced (30-second maximum recommended)
• Row result cap enforced (10,000 row maximum recommended)
• Error messages sanitized — credentials must not appear in exception text or logs

Apply this pattern check when the task involves any database driver, ORM, or raw query builder.

Reference Routing

Situation	Reference
security receipt write	engine/shared/references/script-delegation-contract.md → receipt-writer.py --type gateway-spec / gateway-verdict (two-phase)`

Output contract

• Cross-cutting threat assessment (additive to platform threat model)
• SAST report (Semgrep or equivalent)
• Git history secret scan result
• Gateway activation receipt with all gate results

Files loaded by this module

modules/l4/security/
  threat-model.md
  vulnerability-patterns.md
  controls.md
  audit-gates.md