@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/cilium/cilium-network-policy-review/references/workflow-and-output.md

@@ -0,0 +1,130 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the policy format
+
+Cilium supports three formats with different scopes and capabilities:
+
+1. **`NetworkPolicy`** (`networking.k8s.io/v1`) — Kubernetes-native, namespace-scoped, L3/L4 only.
+2. **`CiliumNetworkPolicy`** (`cilium.io/v2`, "CNP") — namespace-scoped, L3-L7 (HTTP, Kafka, DNS), FQDN matching, ICMP, identity-based selectors via Cilium endpoint identities.
+3. **`CiliumClusterwideNetworkPolicy`** (`cilium.io/v2`, "CCNP") — cluster-wide, same capabilities as CNP, applies across all namespaces.
+
+A namespace can have multiple policies of all three formats simultaneously. The effective policy is the **union** of allows: any policy that allows traffic permits it.
+
+Reference: [Network Policy overview](https://docs.cilium.io/en/stable/network/kubernetes/policy/).
+
+### Step 2 — Verify default-deny posture in the affected namespace
+
+Cilium follows the Kubernetes NetworkPolicy semantic: pods with **at least one ingress policy selecting them** become deny-by-default for ingress; pods with **at least one egress policy selecting them** become deny-by-default for egress. Without any policy selecting a pod, all traffic is allowed.
+
+Critical findings:
+
+- Removing the only ingress `NetworkPolicy` selecting a workload — the workload becomes reachable from any pod, any namespace, any cluster (if ClusterMesh).
+- Adding a workload to a namespace that has no namespace-wide `default-deny` policy — the new workload is allow-by-default.
+
+Recommended baseline: a `default-deny-all` `NetworkPolicy` per namespace plus explicit `CiliumNetworkPolicy` resources that allow specific intra-namespace and cross-namespace flows.
+
+### Step 3 — Audit L7 rules and Envoy proxy requirement
+
+`CiliumNetworkPolicy` and `CiliumClusterwideNetworkPolicy` support L7 rules via Cilium's embedded Envoy:
+
+- `toPorts.rules.http` — method, path, host, header matching.
+- `toPorts.rules.kafka` — Kafka API key matching, topic-level allow.
+- `toPorts.rules.dns` — DNS FQDN allowlist for egress.
+
+L7 rules require the Envoy proxy to be enabled. Without Envoy, policy with L7 fields **either fails admission or is enforced only at L3/L4**, depending on Cilium version. Confirm before relying on L7.
+
+Stress-tests:
+
+- L7 HTTP rule with `path: /admin` but the policy applies to a namespace where pods talk via gRPC — the HTTP path matcher does nothing for HTTP/2 stream multiplexing.
+- L7 DNS rule with FQDN `*.example.com` — wildcard match is supported for DNS but the destination port still matters; verify port 53 UDP/TCP allowed at L4.
+
+Reference: [L7 Policy in Cilium](https://docs.cilium.io/en/stable/security/policy/language/#layer-7-examples).
+
+### Step 4 — Audit egress (the exfiltration path)
+
+Egress is the most-overlooked side of network policy. Critical findings:
+
+- `egress` rules with `toCIDRSet: [{cidr: 0.0.0.0/0}]` and no `except` for internal CIDRs (RFC 1918, link-local, cloud metadata service IPs like `169.254.169.254`) — allows pod to reach the cloud metadata service and exfiltrate cloud credentials.
+- `egress` with `toEndpoints: []` (empty selector) — the empty selector matches **everything** in Cilium semantics; this is broader than `toEndpoints` not being present at all.
+- `egress` allowing `toFQDNs.matchPattern: '*'` — wildcard DNS matching with no narrow allowlist.
+
+Recommended baseline: explicit `toEndpoints` for in-cluster, `toCIDRSet` with `except` for the cloud metadata CIDR, `toFQDNs` for known external services.
+
+### Step 5 — Audit `CiliumEgressGatewayPolicy`
+
+`CiliumEgressGatewayPolicy` assigns a SNAT egress IP for selected pods exiting the cluster — used when external systems require a stable source IP for firewall allowlisting.
+
+Stress-tests:
+
+- Two `CiliumEgressGatewayPolicy` resources with the same `egressIP` — both policies match different pods, both rewrite to the same source IP, and the response routing on the gateway node breaks for one or both. The result is intermittent connection drops.
+- `egressIP` not actually assigned to a NIC on the chosen gateway node — Cilium silently fails to apply, traffic falls back to default node SNAT.
+- `nodeSelector` matches multiple nodes — only one acts as gateway; failover is not automatic.
+- `destinationCIDRs: ['0.0.0.0/0', '::/0']` — every external connection from the selected pods is SNATed; a more narrow CIDR is usually appropriate.
+- Missing `nodeSelector` — policy applies to all nodes, which is rarely the intent.
+
+Reference: [Cilium Egress Gateway](https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/).
+
+### Step 6 — Audit ClusterMesh policy semantics
+
+When ClusterMesh is enabled, identity-based policy selectors (`namespaceSelector`, `endpointSelector`) match across cluster boundaries. Two semantics are possible:
+
+1. **`policy-default-local-cluster: false` (default in older versions)** — selectors match endpoints in any peer cluster. A `namespaceSelector: {kubernetes.io/metadata.name: prod}` matches `prod` in this cluster AND `prod` in every peer cluster.
+2. **`policy-default-local-cluster: true` (default in 1.16+)** — selectors match only the local cluster unless the policy explicitly sets `cluster: <peer-cluster>` on the selector.
+
+**A flag flip changes every existing policy's effective scope simultaneously.** Cilium ships `cilium clustermesh inspect-policy-default-local-cluster` specifically to preview which policies would be affected.
+
+Stress-tests:
+
+- ClusterMesh deployment with mixed clusters at different `policy-default-local-cluster` settings — confusing semantics; one cluster's policy may match peer endpoints while another's does not.
+- Migrating from `false` to `true` — every policy that previously matched cross-cluster identities now silently stops matching them. **This is a documented operational landmine.**
+
+Reference: [Cilium ClusterMesh](https://docs.cilium.io/en/stable/network/clustermesh/) and [`cilium clustermesh inspect-policy-default-local-cluster`](https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/).
+
+### Step 7 — Use Hubble to verify enforcement
+
+Static policy review is not enough. Use Hubble to confirm what the policy actually does:
+
+```shell
+# Watch ingress drops to a workload — should be empty if allow rules are correct
+hubble observe --to-namespace <ns> --to-pod <pod-prefix> --verdict DROPPED --last 1000
+
+# Watch egress allows from a workload — confirms the workload reaches expected destinations
+hubble observe --from-namespace <ns> --from-pod <pod-prefix> --verdict FORWARDED --last 100
+
+# DNS resolution by FQDN policy
+hubble observe --type dns --last 100
+```
+
+Reference: [Hubble Observability](https://docs.cilium.io/en/stable/observability/hubble/).
+
+### Step 8 — Stress-test operational hygiene
+
+- Prefer `CiliumNetworkPolicy` over `NetworkPolicy` when L7 is needed — converting back later is harder than starting with the richer format.
+- Prefer named `endpointSelector` labels over IP CIDRs for in-cluster traffic — IPs change, labels survive pod recreation.
+- Prefer `toFQDNs` over `toCIDRSet` for external services with stable hostnames — DNS rotation no longer breaks the policy.
+- Avoid `CiliumClusterwideNetworkPolicy` for namespace-scoped concerns — cluster-wide blast radius.
+- Test policy changes in a dev or staging cluster first — eBPF program reload happens asynchronously, and a misordered apply during rollout can briefly break traffic.
+
+## Output
+
+Return:
+
+- **target**: which policy format and which scope,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **default-deny posture** in the namespace(s),
+- **L7 enforcement assessment**: Envoy proxy enabled / required, whether L7 rules will actually run,
+- **egress posture**: cloud-metadata service blocked, CIDR scope, FQDN allowlist hygiene,
+- **ClusterMesh assessment** when applicable (cross-cluster semantics, `policy-default-local-cluster` value),
+- **risk findings** (with severity: high / medium / low),
+- **safest next actions** with sample manifest changes and `hubble observe` commands to verify,
+- **rollback plan**: how to revert the change without leaving pods unreachable,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend removing a default-deny policy without a confirmed replacement that explicitly allows required flows.
+- Never recommend `toCIDRSet: [{cidr: 0.0.0.0/0}]` without an `except` block covering the cloud metadata service IP and any other sensitive internal CIDRs.
+- Never recommend changing `policy-default-local-cluster` without first running `cilium clustermesh inspect-policy-default-local-cluster` and reviewing every affected policy.
+- Do not print Cilium ClusterMesh peer Secrets or agent service account tokens.

package/skills/falco/falco-runtime-threat-rules-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: falco-runtime-threat-rules-review
+description: Use this skill when reviewing Falco rules files, falco.yaml configuration, or runtime security posture for a Kubernetes workload. Trigger when a user provides Falco rules YAML, asks whether their Falco setup covers a specific threat, questions rule exception scope, or wants to validate that Falco alert output reaches their SIEM or incident response pipeline.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Falco Runtime Threat Rules Review
+
+## Purpose
+This skill reviews Falco runtime security rules and configuration for correctness, coverage gaps, and operational safety. Falco is a CNCF kernel-level threat detection tool; a misconfigured exception or a silently unconfigured audit webhook means real attacks produce zero alerts. The review catches macro composition errors, overly broad exceptions, missing sensitive-path rules, K8s audit webhook gaps, and alert output routing failures before attackers can exploit them.
+
+## Lean operating rules
+- Treat any rule exception that whitelists an entire process name family (`proc.name in (java, python, node, sh, bash)`) for a sensitive syscall category as HIGH — this creates a full detection blind spot for those runtimes.
+- Treat any rule exception that uses `container.name in (my-app)` without an explicit syscall scope as HIGH — it disables all Falco detection for that container.
+- Treat the absence of rules covering `/proc/*/mem` access, `/etc/shadow` reads, and `/var/run/secrets` mounts as HIGH — these are high-signal kernel-level indicators of container escape and credential theft.
+- Treat K8s audit rules present in the ruleset but no K8s audit webhook configured in the API server as HIGH — the rules exist but never fire because audit events are never delivered.
+- Treat Falco output routed only to stdout with no log aggregation or Falco sidekick configured as HIGH — alerts are silently lost unless a logging pipeline captures stdout from the Falco pod.
+- Flag rules with priority set uniformly to EMERGENCY or CRITICAL for non-critical conditions as MEDIUM — miscalibrated priorities cause alert fatigue and operators begin ignoring or disabling Falco.
+- Flag macro composition that uses negation (`not`) without referencing container context macros — bare process-name rules fire on the host as well as in containers.
+- Do not recommend disabling or commenting out default Falco rules without stating the specific workload justification and residual risk.
+- Label all findings with evidence basis: rule text provided, documentation-based, or inference from missing config.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Macro and rule composition correctness findings
+- Exception scope assessment (process name, container name, syscall scope)
+- Sensitive-path coverage gaps (/proc/*/mem, /etc/shadow, /var/run/secrets)
+- K8s audit webhook connectivity assessment
+- Alert output channel findings (sidekick, gRPC, stdout-only risk)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/falco/falco-runtime-threat-rules-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "falco-runtime-threat-rules-review",
+  "name": "Falco Runtime Threat Rules Review",
+  "type": "skill",
+  "provider": "falco",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Falco rules for macro correctness, priority calibration, exception blast radius, sensitive-path coverage, and alert output routing.",
+  "source_type": "original",
+  "official_docs": [
+    "https://falco.org/docs/rules/",
+    "https://falco.org/docs/reference/rules/supported-syscalls/",
+    "https://falco.org/docs/install-operate/third-party/falco-sidekick/",
+    "https://falco.org/docs/reference/rules/exceptions/",
+    "https://falco.org/docs/install-operate/deployment/",
+    "https://github.com/falcosecurity/rules/tree/main/rules"
+  ],
+  "security_notes": "Falco with overly broad rule exceptions creates detection blind spots. A rule exception matching an entire process family (java, python, node) or a specific container name completely disables detection for that workload — attackers can exploit known exception patterns.",
+  "last_verified": "2026-05-02",
+  "path": "skills/falco/falco-runtime-threat-rules-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/falco/falco-runtime-threat-rules-review/references/workflow-and-output.md

@@ -0,0 +1,249 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized YAML or JSON snippets (no real hostnames, no auth tokens, no kubeconfig inline):
+- Falco rules file(s) (`falco_rules.yaml`, custom rules YAML)
+- `falco.yaml` (main Falco configuration — output channels, driver type, grpc settings)
+- K8s API server audit policy (`audit-policy.yaml`) and webhook configuration (`audit-webhook-config.yaml`), if K8s audit rules are present
+- Falco sidekick configuration, if deployed
+- Optional: output of `falco --list` or `falcoctl rules list` showing loaded rules
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Macro composition audit
+
+Review every macro definition and its use in rules.
+
+Check for:
+- Macros used in negation context (`not is_container`) that do not also scope by `container.id != host`
+- Macros that reference process names without syscall scope (e.g., a macro that matches `proc.name = bash` without specifying which syscalls it applies to)
+- Inheritance chains where a child macro overrides a parent silently (Falco macro override via `override: true` or duplicate macro name)
+
+Example macro composition risk:
+```yaml
+# RISKY — this macro matches bash on host AND in containers
+# If used in a NOT clause, it exempts bash everywhere
+- macro: bash_shell
+  condition: proc.name = bash
+
+# CORRECT — scope to container context
+- macro: bash_in_container
+  condition: proc.name = bash and container.id != host
+```
+
+Flag any macro that, when used in a negation, could suppress host-level detection as MEDIUM.
+
+### Step 3 — Rule priority calibration audit
+
+Review the `priority` field on all custom rules.
+
+Falco priority ladder (highest to lowest):
+`EMERGENCY` → `ALERT` → `CRITICAL` → `ERROR` → `WARNING` → `NOTICE` → `INFORMATIONAL` → `DEBUG`
+
+Check for:
+- All custom rules set to `CRITICAL` or `EMERGENCY` regardless of actual threat severity → MEDIUM (alert fatigue)
+- Rules covering expected or semi-expected behavior (e.g., a CI/CD pipeline running `kubectl exec`) set to `CRITICAL` → MEDIUM
+- Rules covering genuine high-severity threats (container escape attempts, `/proc/*/mem` access) set to `WARNING` or lower → HIGH (under-detection)
+
+Recommended calibration:
+```yaml
+# Container escape attempt — should be CRITICAL
+- rule: Read sensitive memory path
+  desc: Detects direct /proc/PID/mem access indicative of memory scraping
+  condition: open_read and fd.name startswith /proc and fd.name contains /mem
+  output: "Sensitive memory read (proc=%proc.name pid=%proc.pid file=%fd.name)"
+  priority: CRITICAL
+  tags: [container, process, mitre_credential_access]
+
+# Expected CI noise — should be NOTICE or lower
+- rule: Kubectl exec in CI namespace
+  condition: spawned_process and proc.name = kubectl and k8s.ns.name = ci
+  output: "kubectl exec in CI (pod=%k8s.pod.name)"
+  priority: NOTICE
+```
+
+### Step 4 — Exception scope audit
+
+Review every `exceptions:` block on every rule.
+
+**4a. Process name exceptions**
+```yaml
+# HIGH — whitelists all Java processes from shell spawn detection
+- rule: Spawned shell from non-shell binary
+  exceptions:
+    - name: java_apps
+      fields: [proc.pname]
+      comps: [pmatch]
+      values:
+        - [java]
+```
+Any exception that matches a broad process family (`java`, `python`, `node`, `ruby`, `sh`, `bash`) for a sensitive syscall or spawn category completely blinds Falco to attacks running inside those runtimes.
+
+**4b. Container name exceptions**
+```yaml
+# HIGH — disables ALL Falco detection for this container
+- rule: Write below binary dir
+  exceptions:
+    - name: my_app_exception
+      fields: [container.name]
+      comps: [=]
+      values:
+        - [my-privileged-app]
+```
+Container-name exceptions applied at the rule level disable only that rule for that container. But if the same pattern is repeated across multiple rules, the cumulative effect is full detection blindness for that container.
+
+**4c. Correct narrow exception pattern**
+```yaml
+# CORRECT — scopes exception to specific image + specific writable path
+- rule: Write below binary dir
+  exceptions:
+    - name: my_app_installer
+      fields: [container.image.repository, fd.directory]
+      comps: [=, =]
+      values:
+        - [my-org/my-app, /usr/local/bin/app-plugins]
+```
+
+Flag any exception where `fields` contains only `proc.name` or `container.name` without additional syscall or path scope as HIGH.
+
+### Step 5 — Sensitive path coverage audit
+
+Verify that rules exist (custom or inherited from the default ruleset) for:
+
+| Threat | Expected rule condition |
+|--------|------------------------|
+| Container memory scraping | `fd.name startswith /proc` and `fd.name contains /mem` |
+| Shadow file access | `fd.name = /etc/shadow` or `fd.name = /etc/gshadow` |
+| K8s service account token read | `fd.name startswith /var/run/secrets/kubernetes.io` |
+| Privileged container write to host path | `container.privileged = true` and `fd.name startswith /host` |
+| Binary directory write | `fd.directory in (/bin, /usr/bin, /usr/local/bin, /sbin)` |
+
+If any of these are absent and not covered by a loaded default ruleset, flag as HIGH.
+
+Check whether `falco_rules.yaml` references `- rule: ...` with `override: replace` that silently removes a default rule for one of the above categories.
+
+### Step 6 — Kubernetes audit rules audit
+
+Detect whether K8s audit rules are present in the ruleset:
+```yaml
+# K8s audit rules require k8s_audit macro
+- rule: K8s Secret Get or List
+  condition: k8s_audit and ka.verb in (get, list, watch) and ka.target.resource = secrets
+  priority: WARNING
+```
+
+If K8s audit rules exist, check:
+- Whether `falco.yaml` has a `webserver` section configured (Falco embedded audit webhook listener)
+- Whether the K8s API server has an audit webhook pointing to Falco (`--audit-webhook-config-file`)
+- Whether the audit policy includes `resources: [secrets, configmaps]` at a minimum
+
+```yaml
+# Required in falco.yaml for K8s audit
+webserver:
+  enabled: true
+  listen_port: 8765
+  k8s_audit_endpoint: /k8s-audit
+  ssl_enabled: false
+```
+
+If K8s audit rules are present but no webhook is configured or no audit policy is provided, flag as HIGH — the rules are dead weight.
+
+### Step 7 — Alert output channel audit
+
+Review `falco.yaml` `output` section and any sidekick deployment:
+
+**7a. stdout-only output**
+```yaml
+# RISKY — alerts go to pod stdout only
+stdout_output:
+  enabled: true
+file_output:
+  enabled: false
+grpc_output:
+  enabled: false
+```
+If only stdout is enabled and no log aggregation (Fluentd, Fluent Bit, Loki) is confirmed to be scraping the Falco pod, all alerts are silently lost when the pod restarts or the log buffer rolls over. Flag as HIGH.
+
+**7b. Falco sidekick**
+Falco sidekick is the recommended integration bridge (Slack, PagerDuty, Splunk, OpsGenie, SIEM webhooks):
+```yaml
+# Correct — gRPC to sidekick
+grpc_output:
+  enabled: true
+grpc:
+  enabled: true
+  bind_address: "unix:///var/run/falco/falco.sock"
+```
+Verify sidekick is deployed as a Deployment (not a DaemonSet sidecar) and has a live output target configured.
+
+**7c. Output throttling**
+```yaml
+# Check for rate limiting that drops high-volume events
+outputs:
+  rate: 1
+  max_burst: 1000
+```
+Very low `rate` values with small `max_burst` can silently throttle alerts during an active incident. Flag `rate < 10` combined with `max_burst < 100` as MEDIUM.
+
+### Step 8 — Driver type compatibility audit
+
+Identify the configured driver (`ebpf`, `module`, `modern_ebpf`) from `falco.yaml` or deployment manifests.
+
+- `modern_ebpf` (CO-RE) requires kernel 5.8+; check whether the node kernel version is compatible
+- Managed K8s (GKE Autopilot, EKS Fargate) restricts kernel module loading; eBPF or modern_ebpf is required
+- Some syscalls are not available on all drivers — verify critical syscall coverage against `falco --list`
+
+Flag driver/kernel incompatibility as HIGH if it means syscalls used in critical rules are not captured.
+
+### Step 9 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence summary: pass / needs work / critical issues found>
+
+## Evidence level
+<live evidence | user-provided sanitized config | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+...
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never recommend adding broad process-name exceptions (`proc.name in (java, python, node)`) — this creates detection blind spots that attackers can exploit by running malicious code inside a whitelisted runtime.
+- Never recommend disabling the default Falco ruleset (`rules_file: []`) without a complete custom ruleset replacement.
+- Treat any exception that uses `container.name` as the sole discriminator across multiple rules as cumulative HIGH — the container effectively runs undetected.
+- Do not recommend stdout-only output as production-ready without confirming a log aggregation pipeline scrapes the Falco pod and forwards to a SIEM or alerting system.
+- Flag the absence of alerting on Falco's own health (`falco_events_total`, dropped events counter) — a crashing or throttled Falco pod goes unnoticed without self-monitoring.

package/skills/finops/README.md

@@ -0,0 +1,30 @@
+# 💰 FinOps Skills
+
+<p align="center">
+  <!-- 🖼️ Add a FinOps logo to assets/logos/cloud/finops/ and update this path -->
+  <span style="font-size:3.5em">💰</span>
+</p>
+
+This folder contains cross-cloud FinOps skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local FinOps skill:
+
+- `finops-cloud-price-advisor`
+
+## Portfolio posture
+
+Cross-cloud FinOps skills for live price lookup, cost estimation, provider comparison, and budget governance.
+
+These skills are intentionally conservative:
+
+- fetch prices from public unauthenticated APIs only — no billing credentials required
+- always distinguish on-demand list price from effective price (reserved instances, savings plans, committed use discounts not included by default)
+- prefer live API lookups over cached or memory-based price estimates — cloud prices change frequently
+- when comparing providers, normalize compute specs (vCPU, RAM, storage type) before comparing price
+- flag GPU and accelerated compute costs explicitly — they dominate bills and are often overlooked
+
+Providers covered: 🟧 AWS Price List API · 🟦 Azure Retail Prices API · 🟥 OCI public pricing API
+
+Run `npm run validate` after changing cataloged FinOps skills.

package/skills/fluxcd/fluxcd-kustomization-helmrelease-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: fluxcd-kustomization-helmrelease-review
+description: Use this skill when reviewing FluxCD Kustomization, HelmRelease, GitRepository, HelmRepository, or OCIRepository resources. Trigger when the user asks whether a Flux configuration is safe for production, whether SOPS encryption is required, whether prune is safe on a given workload, whether commit signature verification is enabled, or whether a Flux multi-tenant setup uses least-privilege ServiceAccounts.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# FluxCD Kustomization and HelmRelease Review
+
+## Purpose
+
+Review FluxCD `Kustomization`, `HelmRelease`, `GitRepository`, `HelmRepository`, and `OCIRepository` resources for source trust guarantees, SOPS secret encryption, prune-enabled blast radius on stateful workloads, per-Kustomization ServiceAccount scoping, HelmRelease upgrade remediation safety, and health check completeness. FluxCD's default posture gives the `kustomize-controller` cluster-admin-equivalent reach — the security surface lives in per-Kustomization ServiceAccounts, commit signature verification, SOPS encryption at rest, and prune annotation guards.
+
+## Lean operating rules
+
+- Prefer user-provided sanitized resource YAML as primary evidence; official FluxCD docs are the authoritative fallback.
+- Treat unencrypted Kubernetes `Secret` manifests committed to any Git source as a CRITICAL finding — anyone with repo read access (CI, PR participants, auditors) has those secrets.
+- Treat `GitRepository.spec.ref.semver: ">=0.0.0"` or an unbound semver range in a production source as a HIGH finding — any tag push from a compromised upstream triggers a deploy.
+- Treat the absence of `spec.verify.secretRef` (commit GPG signature verification) on production `GitRepository` sources as a HIGH finding.
+- Treat `Kustomization.spec.serviceAccountName` not set as a HIGH finding — the kustomize-controller SA applies with cluster-admin-equivalent scope for all tenants.
+- Treat `spec.prune: true` on Kustomizations covering stateful workloads (StatefulSets, PVCs, CRDs) without `kustomize.toolkit.fluxcd.io/prune: disabled` annotations as a HIGH finding.
+- Treat `HelmRelease.spec.chart.spec.version: "*"` or an unbound version range as a HIGH finding — any upstream chart publish triggers an auto-upgrade.
+- Treat `HelmRelease.spec.upgrade.remediation.retries: -1` (infinite retry) as a MEDIUM finding — a broken release blocks other reconciliation loops indefinitely.
+- Keep the answer scoped: report what was reviewed, the evidence level, and the exact field path for each finding.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Scoped target (resource kind/name/namespace) and evidence level
+- Source trust verdict (commit verification, semver pinning, SOPS encryption)
+- Kustomization ServiceAccount scope assessment
+- Prune safety verdict for any stateful workloads
+- HelmRelease version pinning and upgrade remediation assessment
+- Health check completeness verdict
+- Safe next actions and open questions

package/skills/fluxcd/fluxcd-kustomization-helmrelease-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "fluxcd-kustomization-helmrelease-review",
+  "name": "FluxCD Kustomization and HelmRelease Review",
+  "type": "skill",
+  "provider": "fluxcd",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review FluxCD Kustomization, HelmRelease, GitRepository, HelmRepository, and OCIRepository resources for source trust, SOPS encryption, prune blast-radius, ServiceAccount scope, and upgrade remediation safety.",
+  "source_type": "original",
+  "official_docs": [
+    "https://fluxcd.io/flux/components/kustomize/kustomizations/",
+    "https://fluxcd.io/flux/components/helm/helmreleases/",
+    "https://fluxcd.io/flux/components/source/gitrepositories/",
+    "https://fluxcd.io/flux/guides/repository-structure/",
+    "https://fluxcd.io/flux/security/secrets-management/",
+    "https://fluxcd.io/flux/installation/configuration/multitenancy/"
+  ],
+  "security_notes": "Plaintext Kubernetes Secret manifests committed to a FluxCD Git source are exposed to anyone with repo read access — including CI systems, PR participants, and auditors. GitRepository sources without commit signature verification allow any commit (including injected ones) to deploy to production.",
+  "last_verified": "2026-05-02",
+  "path": "skills/fluxcd/fluxcd-kustomization-helmrelease-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}