gates: add 23 review gates across 10 skills (batch 1+2)

skills/compliance/pci-dss-review/gates/service-provider-aoc-coverage-gate.md

@@ -0,0 +1,42 @@
+# Service Provider AOC Coverage Gate
+
+## Purpose
+Prevents false-positive PCI DSS findings when a service provider's Attestation of Compliance (AOC) does not explicitly list the customer's in-scope services, but the provider's SOC 2 Type II or PCI DSS ROC covers the relevant service infrastructure and compensating controls are in place.
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. A PCI DSS assessment flags that a service provider's AOC does not explicitly cover the cardholder data environment (CDE) services used
+2. The service provider has a SOC 2 Type II report or PCI DSS ROC that covers the relevant service infrastructure
+3. The customer has contractual assurances that the provider's CDE infrastructure is in scope of their PCI assessment
+
+### Gate Check: Provider Assessment Coverage
+
+```yaml
+check_provider_assessment_coverage:
+  - detection_patterns:
+      - "AOC|attestation.*of.*compliance|ROC|report.*on.*compliance"
+      - "SOC.*2|SOC.*3|Type.*II|service.*organization.*control"
+      - "PCI.*scope|CDE.*infrastructure|cardholder.*data.*environment"
+  - pass: "When the provider's SOC 2 Type II report or PCI ROC includes the specific service types being used (cloud hosting, payment processing, SaaS) and the report was issued within the last 12 months, downgrade to informational. Rationale: A current SOC 2 or PCI assessment covering the service type provides equivalent assurance to a service-specific AOC."
+  - fail: "When the provider has no current (<12 month) SOC 2 or PCI assessment, or the assessment explicitly excludes the service type being used, retain severity. Rationale: Without current third-party assessment coverage, the provider's CDE controls are unverified."
+```
+
+### Gate Check: Contractual Control Assurance
+
+```yaml
+check_contractual_control_assurance:
+  - detection_patterns:
+      - "service.*provider|vendor|third.?party|sub.?processor|sub.?service"
+      - "contract.*section|security.*appendix|responsibility.*matrix"
+      - "right.*to.*audit|audit.*report|security.*certification"
+  - pass: "When the customer contract includes the provider's commitment to maintain PCI DSS compliance or equivalent security framework for the service infrastructure, AND grants the customer right-to-audit or report access, downgrade severity. Rationale: Contractual compliance commitments with audit rights provide formal assurance even without an explicit AOC."
+  - fail: "When the contract does not include compliance commitments, security framework requirements, or audit rights for the service, retain severity. Rationale: Without contractual security assurances, the customer cannot verify provider CDE controls."
+```
+
+## Resolution Path
+1. Request the provider's most recent SOC 2 Type II report or PCI ROC and verify it covers the relevant service infrastructure
+2. Map the in-scope CDE services to the provider's assessed control framework
+3. If the AOC gap persists, request a service-specific AOC letter from the provider's compliance team
+4. Document the compensating controls (SOC 2 coverage + contractual assurances) in the PCI DSS responsibility matrix

skills/compliance/soc2-gap/gates/complementary-user-entity-controls-gate.md

@@ -0,0 +1,42 @@
+# Complementary User Entity Controls Evaluation Gate
+
+## Purpose
+Prevents false-positive SOC 2 gap findings when user entity controls are not formally documented in the service organization's control matrix, but compensating controls at the user entity level are addressed through contractual terms, shared responsibility matrices, and user entity responsibilities documentation.
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. A SOC 2 gap assessment flags missing complementary user entity controls (CUEC) in the service organization's control matrix
+2. The organization has a published shared responsibility matrix or user responsibilities document
+3. Customer contracts include security requirements and user entity obligations
+
+### Gate Check: Shared Responsibility Documentation
+
+```yaml
+check_shared_responsibility_documentation:
+  - detection_patterns:
+      - "complementary.*user.*entity.*control|CUEC|user.*entity.*responsib"
+      - "shared.*responsib|responsibility.*matrix|shared.*security.*model"
+      - "customer.*responsib|client.*responsib|tenant.*responsib"
+  - pass: "When the organization publishes a shared responsibility matrix that explicitly states user entity obligations for the in-scope controls (access management, encryption configuration, incident notification), downgrade to informational. Rationale: A published shared responsibility model satisfies the intent of CUEC documentation even when not in the formal control matrix."
+  - fail: "When no shared responsibility documentation exists and user entity obligations are not communicated to customers, retain severity. Rationale: Undocumented user entity responsibilities create control gaps that may lead to audit findings for both the service organization and its customers."
+```
+
+### Gate Check: Contractual Security Requirements
+
+```yaml
+check_contractual_security_requirements:
+  - detection_patterns:
+      - "SLA|service.*level.*agreement|terms.*of.*service|customer.*agreement"
+      - "security.*appendix|data.*protection.*addendum|DPA|SOW"
+      - "penetration.*test|audit.*right|security.*review|compliance.*cert"
+  - pass: "When customer contracts or data protection addenda include user entity security obligations (maintain access controls, encrypt data, report incidents), downgrade severity. Rationale: Contractually binding security obligations provide equivalent control coverage to formally documented CUECs."
+  - fail: "When contracts do not address user entity security obligations or data protection requirements, retain severity. Rationale: Without contractual security requirements, user entity controls exist only informally and are not auditable."
+```
+
+## Resolution Path
+1. Map each in-scope SOC 2 control to the corresponding user entity responsibility in the shared responsibility matrix
+2. Ensure the shared responsibility matrix is published in the customer portal and referenced in contracts
+3. Add a CUEC section to the SOC 2 control matrix that cross-references the shared responsibility documentation
+4. Review customer contracts to confirm security obligations are included and enforceable

skills/devsecops/pipeline-security/gates/artifact-attestation-subject-gate.md

@@ -0,0 +1,42 @@
+# Artifact Attestation Subject Gate
+
+## Purpose
+Prevents false-positive findings when CI/CD pipeline security reviews flag missing artifact attestation for build artifacts that are produced and consumed within a trusted supply chain with compensating integrity controls (signed git tags, branch protection, SLSA-compliant build platform).
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. A build artifact (container image, binary, package) is flagged as lacking attestation or SLSA provenance
+2. The artifact is built on a platform with branch protection, required reviews, and signed commits
+3. The artifact is consumed only within the same trusted organization or supply chain
+
+### Gate Check: Compensating Integrity Controls
+
+```yaml
+check_compensating_integrity_controls:
+  - detection_patterns:
+      - "attestation|provenance|SLSA|in.?to.?to|signed.?tag|signed.?commit"
+      - "branch.?protection|required.?review|status.?check|CODEOWNERS"
+      - "container.*sign|image.*sign|cosign|notary|sigstore|fulcio"
+  - pass: "When the build platform enforces branch protection, required PR reviews, and signed commits, AND the artifact is distributed through a trusted registry with access controls, downgrade to informational. Rationale: Platform-level integrity controls provide equivalent assurance to per-artifact attestation for internal supply chains."
+  - fail: "When the build platform lacks branch protection or the artifact is distributed through public or untrusted channels without attestation, retain severity. Rationale: Without platform integrity, missing attestation creates genuine supply chain risk."
+```
+
+### Gate Check: Attestation Implementation Feasibility
+
+```yaml
+check_attestation_feasibility:
+  - detection_patterns:
+      - "container.*build|docker.*build|kaniko|buildah|ko|jib"
+      - "gradle.*build|maven.*deploy|npm.*publish|pip.*publish"
+      - "github.*actions|gitlab.*ci|jenkins|circleci"
+  - pass: "When the build toolchain supports attestation generation (Cosign, Jib, Tekton Chains) AND the team has a documented plan to implement it within the next sprint, downgrade severity. Rationale: A documented implementation plan with toolchain support reduces urgency."
+  - fail: "When the toolchain does not support attestation, or there is no plan to implement it, retain severity. Rationale: Missing attestation in a supply chain without compensating controls is a security gap requiring remediation."
+```
+
+## Resolution Path
+1. Document the current build platform's integrity controls (branch protection, signed commits, registry access controls)
+2. Determine which attestation format (SLSA provenance, in-toto, Cosign) is feasible for the current toolchain
+3. If using GitHub Actions or GitLab CI, enable OIDC-based attestation via Sigstore or native CI/CD attestation features
+4. If the artifact is internal-only and platform integrity is strong, document the compensating controls as an exception

skills/devsecops/sast-config/gates/generated-client-code-exclusion-gate.md

@@ -0,0 +1,42 @@
+# Generated Client Code Exclusion Gate
+
+## Purpose
+Prevents false-positive SAST findings when generated client code (OpenAPI clients, gRPC stubs, GraphQL codegen, SDK wrappers) contains security issues that are outside the developer's control and cannot be remediated by modifying the generated output.
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. The flagged file is in a directory or has a header comment indicating auto-generation (OpenAPI, gRPC, GraphQL, Swagger Codegen, etc.)
+2. The finding is in generated code that mirrors an API specification rather than hand-written business logic
+3. The generation tool and source specification are under version control and can be remediated at the spec level
+
+### Gate Check: Generated File Marker
+
+```yaml
+check_generated_file_marker:
+  - detection_patterns:
+      - "auto-generated|auto.?generated|generated.?by|do.?not.?edit|DO NOT EDIT"
+      - "openapi.?generator|swagger.?codegen|grpc.*generat|protoc"
+      - "graphql.*codegen|client.*gen|sdk.*generat"
+  - pass: "When the file has a generated marker AND the generation tool and source spec are in the same repository, downgrade to informational. Rationale: Issues in generated code should be fixed at the spec/template level, not in the generated output. The real vulnerability is in the spec."
+  - fail: "When the file has a generated marker but no source spec or generation tool is version-controlled, retain severity. Rationale: Generated code without a spec is effectively orphaned code that must be maintained manually, making the finding actionable."
+```
+
+### Gate Check: Spec-Level Fix Available
+
+```yaml
+check_spec_level_fix_available:
+  - detection_patterns:
+      - "api.*spec|openapi.*yaml|openapi.*json|swagger|proto|graphql.*schema"
+      - "template.*file|mustache|handlebars|codegen.*template"
+      - "generator.*config|codegen.*config|openapitools.json"
+  - pass: "When the vulnerability can be fixed by modifying the API spec or codegen template (e.g., adding input validation patterns to the spec, updating template security headers), downgrade severity. Rationale: Spec-level fixes propagate to all generated clients, providing a systemic fix."
+  - fail: "When the vulnerability is inherent to the code generation process itself and cannot be fixed at the spec/template level, retain severity. Rationale: Findings that require post-generation patching are genuine code quality issues."
+```
+
+## Resolution Path
+1. Identify the source spec file (OpenAPI YAML, .proto, GraphQL schema, etc.) and codegen configuration
+2. Determine if the finding can be remediated by modifying the spec (e.g., adding pattern constraints, security definitions) or the codegen template
+3. If spec-level fix is possible, submit a PR to the spec/template and regenerate the client
+4. If spec-level fix is not possible, add a post-generation patch script or add the generated directory to the SAST scanner's exclusion list with a documented exception

skills/identity/iam-review/gates/api-key-unused-age-gates.md

@@ -0,0 +1,42 @@
+# API Key Unused-Age Gates
+
+## Purpose
+Prevents false-positive IAM findings when API keys that exceed the standard unused-age threshold are flagged as stale, but the keys are intentionally long-lived for specific use cases (CI/CD pipelines, legacy system integration, disaster recovery credentials) with compensating monitoring controls.
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. An API key exceeds the standard unused-age threshold (>90 days since last use)
+2. The key is documented for a specific use case that requires periodic manual use (DR credentials, break-glass keys, legacy system integration)
+3. Key usage is monitored and alerts trigger on anomalous activity
+
+### Gate Check: Documented Use Case
+
+```yaml
+check_documented_use_case:
+  - detection_patterns:
+      - "break.?glass|emergency.*access|disaster.*recovery|DR.*key"
+      - "legacy.*integration|legacy.*system|vendor.*integration|legacy.*API"
+      - "CI.*pipeline|deploy.*key|release.*key|artifact.*key"
+  - pass: "When the key has a documented business justification in the key description or metadata, AND the justification requires the key to remain active beyond the standard rotation period, downgrade to informational. Rationale: Documented exception keys with business justification meet audit requirements for controlled exceptions."
+  - fail: "When the key has no description, no metadata, or no documented justification for exceeding the unused-age threshold, retain severity. Rationale: Undocumented keys exceeding the unused-age threshold may indicate forgotten or orphaned credentials."
+```
+
+### Gate Check: Monitoring Coverage
+
+```yaml
+check_monitoring_coverage:
+  - detection_patterns:
+      - "last.*used|last.*access|last.*activity|last.*rotated"
+      - "cloud.*trail|audit.*log|access.*log|key.*usage|credential.*report"
+      - "alert|notif|anomaly|unusual.*activity|unexpected.*use"
+  - pass: "When the key's usage is logged to a SIEM or audit system with alerts configured for anomalous use (new location, new service, out-of-hours), downgrade severity. Rationale: Monitored keys with alerting provide detective control that compensates for the reduced rotational hygiene."
+  - fail: "When no usage monitoring or alerting exists for the key, retain severity. Rationale: Unmonitored keys beyond the unused-age threshold cannot detect misuse and must be rotated."
+```
+
+## Resolution Path
+1. Add a meaningful description to the key documenting its purpose, owner, and expected use frequency
+2. Set up CloudTrail/key usage logging and configure alerts for anomalous activity
+3. Schedule the key for rotation at the next major release or DR test cycle
+4. Document the exception in the IAM review report with the business justification and monitoring evidence

skills/identity/iam-review/gates/keyless-workload-identity-gate.md

@@ -0,0 +1,43 @@
+# Keyless Workload Identity Gate
+
+## Purpose
+Prevents false-positive IAM findings when cloud workloads use keyless identity (OIDC, workload identity federation, instance metadata credentials) instead of long-lived service account keys, but the keyless approach is the more secure alternative.
+
+## Detection Logic
+
+### Trigger Conditions
+Fire this gate when ALL of the following are true:
+1. A finding flags the absence of a service account key or access key for a workload
+2. The workload uses OIDC-based identity federation (Workload Identity Federation, OIDC provider, IMDS credentials)
+3. The cloud provider supports keyless authentication for the workload's runtime environment
+
+### Gate Check: OIDC Federation
+
+```yaml
+check_oidc_federation:
+  - detection_patterns:
+      - "workload.*identity|OIDC|OpenID.*Connect|identity.*federation"
+      - "IMDS|instance.*metadata|metadata.*credentials|STS.*AssumeRoleWithWebIdentity"
+      - "keyless|no.?key|key.?free|token.*exchange"
+  - pass: "When the workload authenticates via OIDC identity federation (GCP Workload Identity Federation, AWS IAM Roles Anywhere, Azure Workload Identity, GitHub Actions OIDC), downgrade to informational. Rationale: Keyless OIDC identity is more secure than long-lived keys - shorter credential lifetime, automatic rotation, no secret management burden."
+  - fail: "When the workload uses static credentials (file-based, environment variable) without any identity federation mechanism, retain severity. Rationale: Static workload credentials without keyless alternatives are a genuine credential management risk."
+```
+
+### Gate Check: Credential Lifetime
+
+```yaml
+check_credential_lifetime:
+  - detection_patterns:
+      - "access.*key|secret.*key|service.*account.*key|API.*key"
+      - "credential.*rotation|key.*rotation|secret.*rotat"
+      - "token.*expir|session.*duration|credential.*lifetime"
+  - pass: "When any static credential used has automatic rotation (<90 days) and the workload is actively migrating to keyless identity with a documented plan, downgrade severity. Rationale: Short-lived rotating credentials with a migration plan represent acceptable interim risk."
+  - fail: "When static credentials are older than 90 days without rotation and there is no keyless migration plan, retain severity. Rationale: Long-lived unrotated workload credentials are a standing vulnerability."
+```
+
+## Resolution Path
+1. Identify the workload's runtime environment (GKE, ECS, Azure, GitHub Actions, on-prem) and map available OIDC identity options
+2. If using GCP, enable Workload Identity Federation for the workload's service account
+3. If using AWS, configure IAM Roles Anywhere or ECS task IAM roles
+4. If using Azure, enable Workload Identity Federation with OIDC token exchange
+5. Document the migration timeline and set credential rotation to <30 days as interim control