security-mcp 1.1.3 → 1.3.1

package/skills/artifact-integrity-analyst/SKILL.md

@@ -66,3 +66,444 @@ and provenance. Covers §5 Supply Chain Security fully.
 - Missing signing, provenance, or SBOM controls
 - CI workflow additions to implement the missing control
 - §5 SLSA control reference per finding
+
+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. Typosquatting & Dependency Confusion (CVE-class: supply chain namespace collision)
+
+**Attack:** An attacker publishes a malicious package to a public registry (npm, PyPI) with a
+name that matches an internal private package. When the build system resolves dependencies, it
+preferentially pulls the public (malicious) version if the public version number exceeds the
+private registry's version — the dependency confusion attack (Alex Birsan, 2021, HackerOne).
+
+**Detection method:**
+```bash
+# List all package names in package.json / requirements.txt
+# Check whether each name exists in the public registry
+npm info <internal-package-name> --json 2>/dev/null | jq '.name'
+# If a result is returned for an internal-only name, this is a confirmed dependency confusion risk
+# Also check: .npmrc / pip.conf — is `--index-url` or `registry` scoped to private registry ONLY?
+grep -r "registry" .npmrc .yarnrc .yarnrc.yml pip.conf pyproject.toml 2>/dev/null
+```
+
+**Finding:** Any internal package name resolvable from the public registry without explicit
+`@scope` namespace enforcement or a registry-precedence lock constitutes a HIGH finding.
+
+---
+
+### 2. Build-Time Code Injection via Malicious CI Action (SLSA Build Integrity)
+
+**Attack:** A referenced GitHub Actions action (`uses: org/action@v2`) resolves to a mutable
+tag. If the action maintainer's account is compromised, a malicious commit can be pushed to
+the same `v2` tag, causing every downstream build to execute attacker-controlled code inside
+the trusted CI environment — identical to the SolarWinds build-time injection pattern.
+
+**Detection method:**
+```bash
+# Find all GitHub Actions workflow files
+find . -path "./.github/workflows/*.yml" -o -path "./.github/workflows/*.yaml" | \
+  xargs grep -n "uses:" | grep -v "@[0-9a-f]\{40\}"
+# Any 'uses:' line not pinned to a full 40-character SHA is a finding
+# Example of finding: uses: actions/checkout@v4  (mutable)
+# Expected: uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  (pinned)
+```
+
+**Finding:** Any `uses:` reference not pinned to a full commit SHA is HIGH.
+Reference: SLSA L2+ requires pinned, versioned action references.
+
+---
+
+### 3. Rekor Transparency Log Tampering Detection
+
+**Attack:** An adversary with access to a CI signing key signs a backdoored artifact and
+publishes the signature to Sigstore's Rekor transparency log. Because the artifact is signed,
+admission controllers approve it. The key compromise may go undetected if the log is not
+monitored for unexpected entries against a known-good policy.
+
+**Detection method:**
+```bash
+# Verify a container image's Rekor log entry matches expected workflow
+cosign verify \
+  --certificate-identity-regexp="https://github.com/<org>/<repo>/.github/workflows/release.yml" \
+  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
+  <image>@<digest>
+
+# Enumerate all Rekor entries for a given artifact hash
+rekor-cli search --sha "$(sha256sum artifact.tar.gz | cut -d' ' -f1)"
+# Unexpected entries from a non-CI identity = compromised signing key
+```
+
+**Finding:** Cosign identity mismatch between expected workflow URL and actual certificate
+subject is a CRITICAL finding. Trigger §PROJECT-ESCALATION immediately.
+
+---
+
+### 4. AI-Assisted Malicious Package Detection (Emerging Threat — 2025+)
+
+**Attack:** LLM-assisted adversaries generate syntactically legitimate but semantically
+malicious packages that evade keyword-based scanners. Packages contain delayed-execution
+payloads (e.g., triggered after 30 days or after N installs), encrypted C2 channels inside
+seemingly benign HTTP requests, or steganographic payloads in bundled assets. This technique
+was observed in the `xz-utils` backdoor (CVE-2024-3094) — a years-long social-engineering
+and code-poisoning campaign.
+
+**Detection method:**
+```bash
+# Static entropy analysis of bundled files — high entropy = potential encrypted payload
+python3 -c "
+import math, sys
+data = open(sys.argv[1],'rb').read()
+freq = {}
+for b in data: freq[b] = freq.get(b,0)+1
+entropy = -sum((c/len(data))*math.log2(c/len(data)) for c in freq.values())
+print(f'Entropy: {entropy:.3f}')
+" <file>
+# Entropy > 7.5 bits/byte on a non-compressed file is suspicious
+
+# Behavioral analysis: install in isolated sandbox, trace syscalls
+strace -e trace=network,file npm install <suspicious-package> 2>&1 | grep -E "(connect|open)"
+```
+
+**Finding:** Packages with unexplained high-entropy bundled assets, network syscalls during
+install scripts, or `postinstall` hooks that download external resources are HIGH findings.
+
+---
+
+### 5. Post-Quantum Signature Downgrade (Emerging Threat — FIPS 204/205 transition)
+
+**Attack:** As NIST finalises ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for code signing,
+systems that advertise support for hybrid classical/post-quantum signatures but fall back to
+ECDSA-only when the PQ algorithm is unavailable are vulnerable to active downgrade attacks.
+An adversary performing a MitM on artifact delivery can strip the PQ signature layer,
+leaving only the classical ECDSA signature — which will be breakable by a CRQC.
+
+**Detection method:**
+```bash
+# Check if Cosign or in-house signing supports ML-DSA or hybrid PQ schemes
+cosign version  # Look for PQ-capable release >= 2.4 (experimental)
+# Check signing policy for downgrade enforcement
+grep -r "algorithm\|key-type\|signing-algorithm" cosign.yaml policy.yaml 2>/dev/null
+# If no policy enforces PQ-only or hybrid-minimum, flag as MEDIUM (escalates to HIGH by 2027)
+```
+
+**Finding:** No post-quantum signing capability, no PQ migration roadmap, or policies that
+allow silent downgrade to classical-only signing is a MEDIUM finding today, escalating
+timeline to HIGH by 2027 per NIST PQC migration guidance.
+
+---
+
+### 6. SBOM Completeness Evasion via Indirect Dependency Omission
+
+**Attack:** SBOMs generated by shallow tools (e.g., `npm ls --depth=0`) omit transitive
+dependencies. A compromised transitive dependency (e.g., the `event-stream` npm incident,
+2018) is invisible to the SBOM consumer, who believes the SBOM is complete. The US Executive
+Order 14028 and the EU Cyber Resilience Act both require *complete* SBOMs including all
+transitive dependencies.
+
+**Detection method:**
+```bash
+# Generate full-depth SBOM and compare node count against shallow SBOM
+syft <image> -o cyclonedx-json > sbom-full.json
+jq '.components | length' sbom-full.json
+
+# Compare against any checked-in SBOM
+jq '.components | length' sbom-checked-in.json
+
+# Diff: if full SBOM has significantly more components, shallow SBOM is incomplete
+# Also verify: every component in the full SBOM has a valid PURL
+jq '[.components[] | select(.purl == null or .purl == "")] | length' sbom-full.json
+# Non-zero = components without PURL = SBOM non-compliant with CycloneDX spec
+```
+
+**Finding:** SBOM missing transitive dependencies, or components lacking valid PURLs, is a
+HIGH finding under US EO 14028 §4(e) and EU CRA Article 13.
+
+---
+
+### 7. Immutable Tag Bypass via Registry API (Container Supply Chain)
+
+**Attack:** Even when a container registry is configured with `imageTagMutability: IMMUTABLE`
+(ECR) or equivalent, some registry APIs expose administrative endpoints that allow tag
+reassignment under specific IAM conditions. An over-permissioned CI role or a compromised
+registry admin credential can silently reassign an immutable tag to a different digest without
+triggering standard audit logs, breaking the deployment assumption that the tag points to a
+known-good image.
+
+**Detection method:**
+```bash
+# ECR: verify current tag -> digest mapping and compare to build-time expected digest
+aws ecr describe-images --repository-name <repo> \
+  --image-ids imageTag=latest \
+  --query 'imageDetails[0].imageDigest' --output text
+
+# Cross-reference against the digest recorded in the deployment manifest or SBOM
+grep "sha256:" deployment.yaml | head -5
+
+# Also: check ECR repository policy for any principal with ecr:PutImage on production repos
+aws ecr get-repository-policy --repository-name <repo> | \
+  jq '.policyText | fromjson | .Statement[] | select(.Effect=="Allow") | .Action'
+```
+
+**Finding:** Any IAM principal other than the designated CI role with `ecr:PutImage` or
+`ecr:BatchDeleteImage` on a production repository is a HIGH finding. Tag digest mismatch
+between deployment manifest and live registry is a CRITICAL finding.
+
+---
+
+## §ARTIFACT_INTEGRITY_ANALYST-CHECKLIST
+
+1. **Mutable action references in CI:** Scan all `.github/workflows/*.yml` for `uses:` lines
+   not pinned to a 40-character commit SHA. Grep: `uses:.*@` then filter out 40-char hashes.
+   Finding: any mutable tag reference (`@v1`, `@main`, `@latest`).
+
+2. **SLSA level determination:** Read CI pipeline definitions; identify whether a hosted build
+   service is used (L2) and whether the build platform is hardened + isolated (L3). Grep for
+   `slsa-framework/slsa-github-generator` or equivalent. Finding: L1 or L2 for production
+   release artifacts.
+
+3. **Cosign signing step present:** Grep CI files for `cosign sign`. Verify signing occurs
+   *after* build, *before* push. Finding: no signing step, or signing occurs after push
+   (signature may not be associated with the correct digest).
+
+4. **Admission controller enforcement:** Check Kubernetes policy files for Kyverno
+   `ImageVerification` or Gatekeeper constraints. Grep: `imageVerification`, `cosign.dev`.
+   Finding: no admission policy enforcing signature verification at deploy time.
+
+5. **SBOM generation and publication:** Verify a `syft` or `cdxgen` step in CI that outputs
+   CycloneDX JSON. Verify SBOM is signed (`cosign attest --type cyclonedx`). Verify SBOM is
+   uploaded to Dependency-Track or equivalent. Finding: missing generation, missing signature,
+   or missing publication.
+
+6. **Base image digest pinning:** Grep all Dockerfiles for `FROM` lines. Any `FROM` without
+   `@sha256:` is a finding. Grep: `^FROM` then check for `@sha256:`.
+   Finding: any base image pinned only by tag.
+
+7. **Transitive SBOM completeness:** Run `syft` at full depth and compare component count to
+   any checked-in SBOM. Grep generated SBOM for components with null PURLs.
+   Finding: component count mismatch > 10% or any null PURL.
+
+8. **Registry tag mutability:** For ECR, run `aws ecr describe-repositories` and check
+   `imageTagMutability`. For GCR/GAR, check IAM for `artifactregistry.tags.update`.
+   Finding: `imageTagMutability: MUTABLE` on any production registry.
+
+9. **Provenance attestation in Rekor:** Run `cosign verify-attestation --type slsaprovenance`
+   against the production artifact. Verify the certificate subject matches the expected
+   GitHub Actions workflow URL. Finding: no attestation, or subject mismatch.
+
+10. **Dependency confusion namespace collision:** For each internal package name, query the
+    public registry. Grep `.npmrc` / `pip.conf` for scoped private-registry-only enforcement.
+    Finding: internal package name resolvable from public registry without scope enforcement.
+
+11. **Build reproducibility:** Attempt to reproduce the build from source using the recorded
+    provenance. Compare resulting artifact digest to the published digest.
+    Finding: digest mismatch = non-reproducible build = provenance cannot be trusted.
+
+12. **Over-permissioned CI IAM role:** Review the IAM role or service account used by CI.
+    Check for write permissions beyond the designated artifact repository. Grep Terraform/IaC
+    for `ecr:*`, `artifactregistry.repositories.*`, `storage.objects.*` with wildcard actions.
+    Finding: CI role with write access to registries, buckets, or repos beyond its build scope.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in the artifact integrity domain, the following sequence is
+MANDATORY before the finding is recorded:
+
+1. **Write the working PoC FIRST.** For each finding class, examples include:
+
+   - *Mutable action reference exploit:*
+     ```bash
+     # Simulate tag reassignment: verify that changing the action tag resolves different code
+     git ls-remote https://github.com/actions/checkout refs/tags/v4
+     # Record the current SHA, then show what a malicious reassignment would look like
+     # (do not execute against real repos — document the mechanism and reference real incidents)
+     ```
+
+   - *Dependency confusion exploit:*
+     ```bash
+     # Create a dummy package with a higher version number than the internal package
+     mkdir /tmp/confusion-poc && cd /tmp/confusion-poc
+     echo '{"name":"<internal-pkg-name>","version":"9999.0.0","main":"index.js"}' > package.json
+     echo 'console.log("DEPENDENCY CONFUSION EXECUTED");' > index.js
+     # Install in a test environment without registry scoping — confirm the public package wins
+     npm install <internal-pkg-name> --registry https://registry.npmjs.org
+     ```
+
+   - *Mutable tag image substitution:*
+     ```bash
+     # Record current digest for a mutable tag
+     docker pull <registry>/<image>:latest
+     docker inspect <registry>/<image>:latest --format='{{.Id}}'
+     # Demonstrate that a re-push with a different payload under the same tag is undetected
+     # by deployments that reference the tag rather than the digest
+     ```
+
+2. **Confirm the PoC reproduces the issue** in an isolated test environment. Record observed
+   impact (code execution, artifact substitution, build poisoning).
+
+3. **Write the fix** (digest pinning, scope enforcement, registry policy, etc.).
+
+4. **Verify the PoC fails against the fix.** Re-run the PoC steps and confirm the attack path
+   is closed.
+
+5. **Record in findings JSON:**
+   ```json
+   {
+     "findingId": "AIA-001",
+     "severity": "HIGH",
+     "exploitPoC": {
+       "steps": ["step 1 command", "step 2 command"],
+       "observedImpact": "description of what happened",
+       "pocVerified": true,
+       "fixVerified": true
+     }
+   }
+   ```
+
+**PoC skipping = finding severity automatically downgraded to MEDIUM.**
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+normal execution flow when ANY of the following conditions are detected:
+
+1. **Active signing key compromise:** Rekor log contains a valid signature for a production
+   artifact from a certificate identity that does not match any known CI workflow URL. This
+   indicates either a key leak or an unauthorized signing event — the entire artifact fleet
+   may be compromised.
+
+2. **Backdoored dependency already deployed to production:** A dependency in the production
+   SBOM matches a known-malicious package hash (e.g., cross-referenced against OSS-Fuzz or
+   the OSV database) and the artifact is currently running in production. Immediate incident
+   response, not a scheduled fix.
+
+3. **Non-reproducible build with provenance mismatch:** The signed provenance claims a
+   specific source commit and build configuration, but a reproducibility attempt produces a
+   different artifact digest. This indicates the build was tampered between source and
+   publish — a SolarWinds-class event.
+
+4. **Registry tag reassignment detected:** The digest currently pointed to by a production
+   tag differs from the digest recorded at deployment time in the deployment manifest or
+   GitOps repo. An image has been silently swapped in production.
+
+5. **CI pipeline exfiltrating secrets to external endpoint:** Build logs or CI network traces
+   show outbound connections to non-whitelisted external IPs or domains during the signing or
+   build step. This indicates a compromised action or poisoned build environment.
+
+6. **Transitive dependency with RCE vulnerability (CVSS >= 9.0) in production SBOM:** The
+   SBOM cross-reference against OSV/NVD returns a critical RCE CVE for a component that is
+   loaded in the production artifact's runtime execution path (not dev-only).
+
+7. **SLSA provenance for a production release is entirely absent:** A production artifact
+   that customers receive has no provenance attestation of any kind. In regulated environments
+   (FedRAMP, PCI DSS 4.0), this alone is a compliance blocker that may require a release
+   recall or emergency patch.
+
+8. **Over-permissioned CI role with production write access AND recent credential rotation
+   failure:** The CI service account has not rotated credentials in over 90 days AND has write
+   access to production registries. Combined with any other finding, this represents an
+   unacceptably wide blast radius for a single compromised CI run.
+
+---
+
+## §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.
+
+**Artifact-integrity-specific gaps:**
+
+- **Silent tag reassignment in registries**: Standard CloudTrail/Audit Logs capture `PutImage` events but do not diff tag-to-digest mappings. Need: a scheduled Lambda/Cloud Function that polls each production tag's digest and alerts on any change not initiated by a known CI run.
+- **SBOM drift between release and runtime**: The signed SBOM reflects the artifact at build time; packages installed post-deployment (e.g., via entrypoint scripts) are invisible. Need: runtime SBOM diffing using Falco or Tetragon to detect new file writes to dependency directories after container start.
+- **Compromised transparency log entry**: Rekor is append-only but its consistency proof requires active monitoring. A client that never checks the inclusion proof can be served a forged log by a MitM. Need: automated `rekor-monitor` deployment that continuously verifies the log's consistency tree.
+
+---
+
+## §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": "Mutable Action Reference", "filesReviewed": 12, "patterns": ["uses:.*@(?![0-9a-f]{40})"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["Mutable action references: searched 12 workflow files — 0 unpinned references"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "artifact-integrity-analyst",
+  "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.