@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/cilium/cilium-network-policy-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: cilium-network-policy-review
+description: Use this skill for Cilium network policy review across the three policy formats (Kubernetes NetworkPolicy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy), L7 policy via embedded Envoy, ClusterMesh cross-cluster semantics, Hubble flow observability, and CiliumEgressGatewayPolicy. Trigger when the user asks whether a network policy is too broad, whether default-deny is in place, whether L7 rules will actually be enforced, whether ClusterMesh policy semantics are correct, or whether an egress gateway IP collision is possible.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# Cilium Network Policy Review
+
+## Purpose
+
+Review Cilium policy resources against zero-trust correctness, blast radius, and the operational traps unique to eBPF-backed networking. Cilium's policy surface is broader than native Kubernetes NetworkPolicy — `CiliumNetworkPolicy` adds L7 rules, FQDN matching, ICMP control, and identity-based selectors; `CiliumClusterwideNetworkPolicy` applies cluster-wide; `CiliumEgressGatewayPolicy` controls SNAT egress IPs; and `policy-default-local-cluster` changes how policy evaluates across ClusterMesh.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies,ciliumegressgatewaypolicies -A -o yaml`, `cilium policy get`, `cilium clustermesh inspect-policy-default-local-cluster`, and Hubble flow observation) when the active client exposes it; otherwise fall back to official Cilium documentation (docs.cilium.io) and sanitized YAML.
+- Separate confirmed facts from inference. If Cilium agent state, ClusterMesh peer status, or Hubble flow data was not queried, say so.
+- Treat **removal of a default-deny `NetworkPolicy`** in a namespace as a critical finding — pods become reachable from any source/destination unless another policy provides isolation.
+- Treat `CiliumNetworkPolicy` egress with `toCIDRSet: [{cidr: 0.0.0.0/0}]` (no `except` for sensitive CIDRs) as a critical finding — unrestricted egress is a documented data exfiltration path.
+- Treat any change to `policy-default-local-cluster` in a ClusterMesh deployment as critical-blast-radius — every existing policy's cross-cluster semantics flip simultaneously.
+- Challenge `CiliumEgressGatewayPolicy` with the same `egressIP` used in two policies — silent connection breakage when both match.
+- Challenge L7 rules in `CiliumNetworkPolicy` for namespaces where Envoy proxy is not enabled — L7 fields require the proxy.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live cluster evidence, confirming Cilium version and ClusterMesh state, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks across the three policy formats and ClusterMesh, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Cilium documentation list, CRD schema, and grounded insights.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (namespace `NetworkPolicy`, namespace `CiliumNetworkPolicy`, cluster-wide `CiliumClusterwideNetworkPolicy`, `CiliumEgressGatewayPolicy`) and evidence level,
+- the default-deny posture in the affected namespace(s),
+- the L7 enforcement assessment (Envoy proxy enabled / required) and whether L7 rules will actually run,
+- the ClusterMesh assessment when applicable (`policy-default-local-cluster` semantics),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/cilium/cilium-network-policy-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "cilium-network-policy-review",
+  "name": "Cilium Network Policy Review",
+  "type": "skill",
+  "provider": "cilium",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Cilium NetworkPolicy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, CiliumEgressGatewayPolicy, and ClusterMesh policy-default-local-cluster behavior for zero-trust correctness, blast radius, L7 enforcement, and egress gateway IP correctness.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.cilium.io/en/stable/",
+    "https://docs.cilium.io/en/stable/network/kubernetes/policy/",
+    "https://docs.cilium.io/en/stable/security/policy/",
+    "https://docs.cilium.io/en/stable/network/clustermesh/",
+    "https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/",
+    "https://docs.cilium.io/en/stable/observability/hubble/",
+    "https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/"
+  ],
+  "security_notes": "Removal of default-deny NetworkPolicy collapses namespace isolation. Unrestricted egress (0.0.0.0/0) is a documented exfiltration path. ClusterMesh policy-default-local-cluster flag flip changes cross-cluster semantics for every existing policy globally. CiliumEgressGatewayPolicy IP collisions cause silent connection breakage.",
+  "last_verified": "2026-05-01",
+  "path": "skills/cilium/cilium-network-policy-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cilium/cilium-network-policy-review/references/mcp-and-evidence.md

@@ -0,0 +1,52 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when a Kubernetes MCP server, `kubectl`, the `cilium` CLI, and Hubble are available against the cluster.
+2. Fall back to the official Cilium documentation (docs.cilium.io) for policy syntax, CRD schema, and ClusterMesh semantics when live inspection is unavailable.
+3. Ask only for sanitized policy YAML, `cilium policy get` output, Hubble flow snippets, or ClusterMesh status output when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# All policy formats across the cluster
+kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies -A -o yaml
+
+# Egress gateway policies
+kubectl get ciliumegressgatewaypolicies -A -o yaml
+
+# Cilium agent state and policy enforcement
+kubectl -n kube-system get pods -l k8s-app=cilium -o name
+kubectl -n kube-system exec -it <cilium-pod> -- cilium status
+kubectl -n kube-system exec -it <cilium-pod> -- cilium policy get
+kubectl -n kube-system exec -it <cilium-pod> -- cilium endpoint list
+
+# Hubble flow observation (live traffic vs policy)
+hubble observe --from-namespace <ns> --to-namespace <ns> --verdict DROPPED
+hubble observe --to-fqdn <fqdn> --verdict DROPPED --last 1000
+
+# ClusterMesh state
+cilium clustermesh status
+cilium clustermesh inspect-policy-default-local-cluster -A -o json
+
+# Policy verification — what does Cilium think this pod is allowed to do?
+kubectl -n kube-system exec -it <cilium-pod> -- \
+  cilium policy trace --src-k8s-pod <ns>/<src-pod> --dst-k8s-pod <ns>/<dst-pod>
+```
+
+## Cilium state to confirm before review
+
+- Cilium version (`kubectl -n kube-system exec <cilium-pod> -- cilium version`) — L7 policy support, ClusterMesh features, and CRD versions evolve across releases.
+- Envoy proxy enabled — required for L7 policy fields (`toPorts.rules.http`, `toPorts.rules.kafka`, `toPorts.rules.dns`).
+- ClusterMesh enabled (`cilium clustermesh status`) — multi-cluster policies are evaluated differently when ClusterMesh is up.
+- `policy-default-local-cluster` setting (per cluster, configurable via Helm) — changes whether policies match cross-cluster identities by default.
+- IPAM mode (`cluster-pool`, `kubernetes`, `eni`, `azure`, `aws-eni`) — affects the IP pool and any egress gateway IP planning.
+- Hubble enabled — required for flow observability and policy debugging.
+- Tetragon installed (separate but Cilium-affiliated) — runtime security; relevant when reviewing combined eBPF posture.
+
+## Sanitization rules
+
+- Never request kubeconfig contents, ClusterMesh peer Secrets, or Cilium agent tokens.
+- Replace identifiable cluster IDs, peer cluster URLs, public egress IPs (when sensitive), and namespace names with placeholders unless the user provides them.
+- Do not print Cilium agent service account tokens.

package/skills/cilium/cilium-network-policy-review/references/official-sources.md

@@ -0,0 +1,30 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Cilium documentation home](https://docs.cilium.io/en/stable/) — use as the entry point for any Cilium question.
+- [Network Policy](https://docs.cilium.io/en/stable/network/kubernetes/policy/) — use for the three policy formats (`NetworkPolicy`, `CiliumNetworkPolicy`, `CiliumClusterwideNetworkPolicy`) and how Cilium distributes them.
+- [Policy language reference](https://docs.cilium.io/en/stable/security/policy/language/) — use for `endpointSelector`, `toEndpoints`, `toCIDRSet`, `toFQDNs`, `toServices`, `toEntities`, L7 HTTP/Kafka/DNS rule syntax.
+- [Policy enforcement modes](https://docs.cilium.io/en/stable/security/policy/intro/) — use for `default`, `always`, `never` enforcement modes and Cilium's identity-based model.
+- [ClusterMesh overview](https://docs.cilium.io/en/stable/network/clustermesh/) — use for multi-cluster service discovery, identity propagation, and cross-cluster policy.
+- [`cilium clustermesh inspect-policy-default-local-cluster`](https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/) — use before any flag flip; lists every policy whose scope would change.
+- [Egress Gateway](https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/) — use for `CiliumEgressGatewayPolicy` SNAT semantics, gateway node selection, and IP collision behavior.
+- [Hubble Observability](https://docs.cilium.io/en/stable/observability/hubble/) — use for flow observation, drop debugging, and policy verification.
+- [Hubble CLI reference](https://docs.cilium.io/en/stable/cmdref/hubble/) — use for `hubble observe` filters and output formats.
+- [Cilium Ingress / Gateway API](https://docs.cilium.io/en/stable/network/servicemesh/) — use when Cilium service mesh (sidecar-free) is in scope alongside policy.
+- [Cilium Service Mesh Beta / GA notes](https://docs.cilium.io/en/stable/network/servicemesh/) — use to understand when Cilium service mesh replaces Istio in the L7 enforcement path.
+- [Tetragon documentation](https://tetragon.io/docs/) — use when runtime security observability and enforcement is in scope alongside Cilium network policy.
+- [Cilium release notes](https://github.com/cilium/cilium/releases) — use for version-specific behavior changes, especially around `policy-default-local-cluster` defaults.
+
+## Grounded insights worth carrying into the skill
+
+- Cilium supports three policy formats simultaneously in one cluster: native `NetworkPolicy`, `CiliumNetworkPolicy` (CNP) for namespace-scoped L3-L7, and `CiliumClusterwideNetworkPolicy` (CCNP) for cluster-wide L3-L7.
+- `CiliumNetworkPolicy` adds capabilities native NetworkPolicy lacks: FQDN matching (`toFQDNs`), L7 HTTP/Kafka/DNS rules, identity-based selectors (Cilium endpoint identities derived from labels), `toEntities` (cluster, world, host, kube-apiserver), and ICMP rules.
+- Cilium's effective policy is the **union** of all selecting allows. There is no DENY action — restriction comes from default-deny on selected pods plus explicit allow rules that collectively define the allowed graph.
+- A pod becomes deny-by-default only when **at least one ingress policy selects it for ingress** or **at least one egress policy selects it for egress**. Pods with no selecting policy are allow-all in that direction.
+- ClusterMesh's `policy-default-local-cluster` flag changes whether identity selectors match endpoints in peer clusters. Setting it to `true` (the newer default in 1.16+) makes selectors local-only unless the policy explicitly opts into cross-cluster matching with `cluster: <name>`. Migrating an existing cluster from `false` to `true` silently breaks every policy that depended on cross-cluster matching.
+- `CiliumEgressGatewayPolicy` controls SNAT egress IPs for selected pods. The most common operational pitfall is two policies SNATing to the same `egressIP` — connection-tracking on the gateway node confuses replies, and connections drop intermittently.
+- L7 policy fields (HTTP, Kafka, DNS) require Cilium's embedded Envoy proxy. Without Envoy enabled, the L7 fields are either rejected at admission or silently dropped depending on the Cilium version. Always verify Envoy state before relying on L7.
+- `toCIDRSet: [{cidr: 0.0.0.0/0}]` with no `except` for the cloud metadata service IP (`169.254.169.254` on AWS/Azure/GCP) is the exfiltration path AWS Capital One famously suffered from. Cilium's `except` clause is the right tool to block it while still allowing general internet egress.
+- Hubble flow observation is the only reliable way to verify what Cilium's eBPF programs are actually doing — static policy review can miss conflicts between policies that share endpoint selectors but differ in port or L7 rules.
+- Tetragon (eBPF runtime security) is a separate Cilium-affiliated project, not part of Cilium itself. When a review touches runtime syscall monitoring, link to Tetragon docs explicitly rather than assuming Cilium provides it.

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,40 @@
+---
+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.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# 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.