@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/azure/azure-private-endpoint-adoption-planner/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-private-endpoint-adoption-planner
 description: Use this skill for Azure Private Link and private endpoint adoption planning, including hub-versus-spoke placement, private DNS zone linkage, route implications, centralized versus workload-local endpoint trade-offs, and safe rollout validation.
+allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: networking
 ---
 
 # Azure Private Endpoint Adoption Planner

package/skills/azure/azure-rbac-review/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-rbac-review
 description: Use this skill for Azure RBAC, Entra-backed access, role assignment, custom role, scope, subscription, management group, or least-privilege review tasks. Trigger when the user asks whether Azure access is too broad or how to grant access safely.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: security
 ---
 
 # Azure RBAC Review

package/skills/azure/azure-resilience-bcdr-review/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-resilience-bcdr-review
 description: Use this skill for Azure resilience, business continuity, and disaster recovery reviews covering RTO/RPO realism, failover and failback assumptions, shared-responsibility gaps, and recovery runbook or drill quality.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: resilience
 ---
 
 # Azure Resilience BCDR Review

package/skills/azure/azure-resource-health-incident-triage/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-resource-health-incident-triage
 description: Use this skill for Azure Resource Health, Service Health, activity-log alert, and first-pass incident triage when the question is whether Azure platform health is part of the problem.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: observability
 ---
 
 # Azure Resource Health Incident Triage

package/skills/azure/azure-role-selector/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-role-selector
 description: Use this skill when the user asks which Azure role to assign, how to grant minimum access, whether a built-in role is sufficient, or when a custom role may be required.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: compliance
 ---
 
 # Azure Role Selector

package/skills/azure/azure-security-posture-hardening/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-security-posture-hardening
 description: Use this skill for Azure security posture review, baseline hardening, managed identity adoption, Key Vault posture, private access decisions, Azure Policy guardrails, and logging or audit gap analysis. Trigger when the user asks how to harden an Azure workload or platform without defaulting to broad access or public exposure.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: security
 ---
 
 # Azure Security Posture Hardening

package/skills/azure/azure-subscription-resource-organization/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: azure-subscription-resource-organization
 description: Use this skill for Azure management-group hierarchy, subscription placement, resource-group boundary, and platform-versus-workload ownership decisions that affect governance, operations, and landing-zone scale.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: compliance
 ---
 
 # Azure Subscription Resource Organization

package/skills/backstage/backstage-scaffolder-template-review/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: backstage-scaffolder-template-review
+description: Use this skill when reviewing Backstage Scaffolder software templates. Trigger when the user asks whether a template is safe for developer self-service, whether template RBAC gates are in place, whether input parameters are validated, whether a step action has excessive blast radius, or whether template outputs expose secrets.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: delivery
+---
+
+# Backstage Scaffolder Template Review
+
+## Purpose
+
+Review Backstage Scaffolder `Template` kind resources for action blast-radius, input parameter injection risk, RBAC permission gate coverage, integration secret scope, catalog entity poisoning via `catalog:register`, and plaintext secret exposure in `output:` stanzas. Backstage Scaffolder gives developers a curated UI to trigger powerful backend actions — without RBAC gates and input validation, every authenticated developer effectively has write access to whatever the Scaffolder integration credentials can reach.
+
+## Lean operating rules
+
+- Prefer user-provided sanitized Template YAML as primary evidence; official Backstage docs are the authoritative fallback.
+- Treat any `steps:` action that provisions real cloud infrastructure (Terraform, Crossplane CRD apply, CloudFormation deploy, `kubectl apply`) with no RBAC permission gate as a CRITICAL finding.
+- Treat input parameters flowing unsanitized into `publish:github.repoUrl`, file-path actions, or shell-exec actions as a HIGH finding — path traversal and injection are realistic.
+- Treat `publish:github` with `visibility: public` as the default or without an `allowedHosts` constraint as a HIGH finding.
+- Treat `output:` stanzas exposing plaintext generated credentials, connection strings, or API keys in the Backstage UI as a HIGH finding.
+- Treat the absence of `@backstage/plugin-permission-backend` policies for infrastructure-provisioning templates as a HIGH finding — any authenticated Backstage user can trigger them.
+- Treat `catalog:register` accepting arbitrary user-supplied YAML without server-side entity schema validation as a MEDIUM finding — catalog poisoning overwrites ownership and lifecycle metadata.
+- Keep the answer scoped: report what was reviewed, the evidence level, and exactly which steps or fields triggered each finding.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Scoped target (Template `metadata.name`) and evidence level
+- Each `steps:` action type and its provisioning blast radius
+- Input parameter validation gaps (missing `maxLength`, `pattern`, `enum`)
+- RBAC permission gate verdict (present / absent / partial)
+- Integration secret scope assessment
+- `output:` stanza exposure assessment
+- Safe next actions and open questions

package/skills/backstage/backstage-scaffolder-template-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "backstage-scaffolder-template-review",
+  "name": "Backstage Scaffolder Template Review",
+  "type": "skill",
+  "provider": "backstage",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Backstage Scaffolder software templates for action blast-radius, input parameter injection, RBAC gate coverage, secret scope, catalog entity poisoning, and output exposure.",
+  "source_type": "original",
+  "official_docs": [
+    "https://backstage.io/docs/features/software-templates/",
+    "https://backstage.io/docs/features/software-templates/writing-templates",
+    "https://backstage.io/docs/features/software-templates/builtin-actions",
+    "https://backstage.io/docs/permissions/overview",
+    "https://backstage.io/docs/integrations/github/github-apps"
+  ],
+  "security_notes": "Backstage Scaffolder templates without RBAC gate and without input validation allow any developer to trigger infrastructure provisioning actions. Templates that provision cloud resources via Terraform or Crossplane CRDs effectively grant cloud-write to all Backstage users.",
+  "last_verified": "2026-05-02",
+  "path": "skills/backstage/backstage-scaffolder-template-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/backstage/backstage-scaffolder-template-review/references/workflow-and-output.md

@@ -0,0 +1,179 @@
+# Workflow and output contract
+
+Use this reference only when performing a full Backstage Scaffolder template review, producing implementation guidance, triaging a scaffolder security incident, or completing a production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Template `metadata.name`, `spec.owner`, and namespace scoping
+- Each `steps:` entry: action type, input parameters, and provisioning blast radius
+- Input `parameters:` schema: type enforcement, `maxLength`, `pattern`, `enum`, and data-flow into step inputs
+- RBAC permission gate: presence and scope of `@backstage/plugin-permission-backend` policies for this template
+- Integration secret scope: GitHub PAT, Azure DevOps token, or other credential used by `publish:*` actions
+- `catalog:register` usage: whether registered YAML is user-supplied or template-controlled
+- `output:` stanza: whether plaintext secrets or credentials are surfaced in the Backstage UI
+
+## Safe workflow
+
+1. **Frame scope**
+   - Template name and `spec.owner`:
+   - Target environment (dev / staging / production):
+   - Backstage version and active plugins:
+   - Whether `@backstage/plugin-permission-backend` is installed:
+   - Required outcome of this review:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer user-provided sanitized Template YAML as primary evidence.
+   - Confirm Backstage version and installed plugins from `app-config.yaml` or Backstage `package.json`.
+   - Label each finding as `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Map action blast radius**
+   For each `steps[].action`, ask:
+   ```
+   - What external system does this action write to?
+   - What credential does it use and what is that credential's scope?
+   - Is there an RBAC permission policy gating this template for that action?
+   - Can a user-controlled input reach this action unsanitized?
+   ```
+   Example: `publish:github` with `repoUrl: ${{ parameters.repoName }}` where `repoName` has no `pattern`
+   validation — a value like `../../../sensitive-repo` could traverse the expected org boundary.
+
+4. **Validate input parameter schema**
+   Check each parameter field:
+   ```yaml
+   parameters:
+     - title: Repository Name
+       properties:
+         repoName:
+           type: string
+           # REQUIRED: maxLength to prevent oversized inputs
+           maxLength: 63
+           # REQUIRED: pattern to block path traversal and injection
+           pattern: '^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$'
+   ```
+   Missing `maxLength` or `pattern` on fields that flow into `publish:github.repoUrl`,
+   `roadiehq:utils:fs:write`, or shell-exec actions is a HIGH finding.
+
+5. **Check RBAC permission gate**
+   A permission policy protecting a Terraform-provisioning template looks like:
+   ```typescript
+   // packages/backend/src/plugins/permission.ts
+   if (
+     isPermission(request.permission, scaffolderTemplateRules.instantiateTemplate)
+   ) {
+     if (request.credentials.principal.type === 'user') {
+       const groups = await catalogClient.getEntities({
+         filter: { kind: 'Group', 'spec.members': request.credentials.principal.userEntityRef }
+       });
+       const isPlatformEngineer = groups.items.some(g => g.metadata.name === 'platform-engineers');
+       return { result: isPlatformEngineer ? AuthorizeResult.ALLOW : AuthorizeResult.DENY };
+     }
+   }
+   ```
+   If no policy like this exists for infrastructure-provisioning templates, flag as CRITICAL.
+
+6. **Assess integration secret scope**
+   Examine the Backstage `integrations:` config that the template's `publish:*` action uses:
+   ```yaml
+   # app-config.yaml
+   integrations:
+     github:
+       - host: github.com
+         token: ${GITHUB_TOKEN}  # scope: repo (read/write all repos in org)
+   ```
+   A token with `repo` scope on all org repos means any template using `publish:github`
+   can write to any repo in the org. Prefer a scoped GitHub App with per-repo installation.
+
+7. **Review catalog:register usage**
+   ```yaml
+   steps:
+     - id: register
+       action: catalog:register
+       input:
+         repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
+         catalogInfoPath: '/catalog-info.yaml'
+   ```
+   If `catalogInfoPath` or the registered YAML content is user-controlled (not template-generated),
+   it can inject arbitrary `spec.owner`, `spec.lifecycle`, or `metadata.annotations` values
+   into the catalog — overwriting existing entities' ownership metadata. Flag as MEDIUM.
+
+8. **Inspect output stanza**
+   ```yaml
+   output:
+     links:
+       - title: Repository
+         url: ${{ steps['publish'].output.remoteUrl }}
+     # HIGH: do not surface generated credentials here
+     # - title: Database password
+     #   url: ${{ steps['create-db'].output.password }}
+   ```
+   Any `output:` value that contains a generated password, API key, connection string,
+   or bearer token is a HIGH finding — it persists in the Backstage task log in plaintext.
+
+9. **Recommend the smallest safe action**
+   - Prefer narrowing input validation before adding RBAC, as validation is deploy-free.
+   - For RBAC gaps, provide the minimum permission policy snippet.
+   - If the safest action is to quarantine the template (mark it `spec.lifecycle: deprecated`
+     and alert the platform team), say that plainly.
+
+## Validation commands
+
+```bash
+# List all templates in the catalog
+kubectl get templates -n backstage --all-namespaces
+
+# Inspect a specific template
+kubectl get template <name> -n backstage -o yaml
+
+# Check whether permission backend plugin is present
+grep -r 'plugin-permission-backend' packages/backend/package.json
+
+# List Backstage integrations config (sanitize before sharing)
+grep -A5 'integrations:' app-config.yaml
+
+# Enumerate templates with no permission policy annotation
+kubectl get templates -A -o json | jq '.items[] | select(.metadata.annotations["backstage.io/permission-policy"] == null) | .metadata.name'
+```
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Backstage Scaffolder Template Review: <template-name>
+
+## Executive verdict
+- Status: SAFE / SAFE WITH RISKS / NOT SAFE / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+
+## Scope and assumptions
+- Template name and owner:
+- Backstage version:
+- Permission backend installed:
+- Confirmed:
+- Unknown:
+- Out of scope:
+
+## Findings
+
+| Severity | Field / Step | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+
+## Action blast radius summary
+
+| Step ID | Action | Blast radius | RBAC gated? |
+|---|---|---|---|
+
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+
+## Validation
+- Commands or checks:
+- Expected result:
+
+## Residual risk
+- <risk or explicit none>
+```

package/skills/cert-manager/cert-manager-issuer-trust-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: cert-manager-issuer-trust-review
+description: Use this skill when reviewing cert-manager PKI configuration for Kubernetes clusters. Trigger when the user asks about Issuer or ClusterIssuer scope, CertificateRequestPolicy coverage, certificate SAN or duration risks, trust-manager bundle distribution, SPIFFE mesh CA integration, cert-manager webhook health, or cloud CA authentication method.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# cert-manager Issuer Trust Review
+
+## Purpose
+
+Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) authorization coverage, certificate SAN wildcard and duration risks, trust-manager CA bundle distribution blast radius, SPIFFE/service-mesh CA integration, and cloud-backed CA authentication method. cert-manager's security posture depends on whether namespace-scoped request authorization exists — without CertificateRequestPolicy, any namespace can issue a certificate for any DNS name from a shared ClusterIssuer.
+
+## Lean operating rules
+
+- Prefer live evidence (`kubectl get clusterissuer,issuer -A -o yaml`, `kubectl get certificaterequestpolicy -o yaml`, `kubectl get certificate -A -o yaml`) when the active client exposes it; otherwise fall back to official cert-manager documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If CertificateRequestPolicy deployment, certificate health, or trust-manager bundle scope was not directly queried, say so.
+- Treat no CertificateRequestPolicy deployed cluster-wide as a critical finding — any cert request in any namespace is auto-approved against any ClusterIssuer.
+- Treat a ClusterIssuer backed by a corporate private CA with no namespace restriction via CertificateRequestPolicy as a high finding — any namespace can request corp-trusted certs.
+- Treat Certificate `spec.dnsNames` containing wildcards like `*.internal.company.com` for a single microservice as a high finding — overly broad trust grants.
+- Treat `spec.duration` exceeding 90 days for workload certs as a high finding; certs with `duration: 87600h` (10 years) are critical.
+- Treat cert-manager-webhook in a degraded or failing state as a high finding — no new cert renewals can complete.
+- Treat a trust-manager Bundle with no namespace selector distributing CA bundles to all namespaces as a medium finding unless intentionally cluster-wide.
+- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+Return, at minimum:
+- the scoped target (ClusterIssuer, Issuer, Certificate, CertificateRequestPolicy, or trust-manager Bundle) and evidence level,
+- the issuer type and backing CA (self-signed, ACME, AWS PCA, Azure Key Vault, Vault, etc.) and whether it is namespace-scoped or cluster-scoped,
+- CertificateRequestPolicy presence and subject/issuer constraint coverage,
+- certificate SAN scope and duration for any reviewed Certificate resources,
+- trust-manager Bundle distribution scope,
+- the safest next actions and any assumptions or blockers.

package/skills/cert-manager/cert-manager-issuer-trust-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "cert-manager-issuer-trust-review",
+  "name": "cert-manager Issuer Trust Review",
+  "type": "skill",
+  "provider": "cert-manager",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) coverage, certificate SAN and duration risks, trust-manager bundle distribution, and cloud CA integration authentication for Kubernetes PKI posture.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cert-manager.io/docs/",
+    "https://cert-manager.io/docs/concepts/certificate/",
+    "https://cert-manager.io/docs/concepts/issuer/",
+    "https://cert-manager.io/docs/projects/approver-policy/",
+    "https://cert-manager.io/docs/projects/trust-manager/",
+    "https://cert-manager.io/docs/configuration/"
+  ],
+  "security_notes": "A ClusterIssuer backed by a corporate Private CA with no CertificateRequestPolicy means any namespace can issue certs for any DNS name trusted by the corporate CA, enabling MITM against internal mTLS services.",
+  "last_verified": "2026-05-02",
+  "path": "skills/cert-manager/cert-manager-issuer-trust-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cert-manager/cert-manager-issuer-trust-review/references/workflow-and-output.md

@@ -0,0 +1,222 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify scope and collect raw evidence
+
+1. Confirm the review target: a ClusterIssuer, a namespace-scoped Issuer, a Certificate resource, a CertificateRequestPolicy, or a trust-manager Bundle.
+2. List all issuers and their types:
+   ```bash
+   kubectl get clusterissuer -o yaml
+   kubectl get issuer -A -o yaml
+   ```
+   For each issuer, note the `spec` type: `acme`, `ca`, `selfSigned`, `vault`, `venafi`, `acmepca` (AWS), `azureKeyVault`.
+3. List all CertificateRequestPolicy resources (approver-policy CRD):
+   ```bash
+   kubectl get certificaterequestpolicy -o yaml
+   ```
+   If the CRD does not exist, approver-policy is not installed — all cert requests are auto-approved. Record this as a critical gap.
+4. List certificates with their issuers and SAN content:
+   ```bash
+   kubectl get certificate -A -o custom-columns=\
+   "NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,\
+   KIND:.spec.issuerRef.kind,DURATION:.spec.duration,DNS:.spec.dnsNames"
+   ```
+
+### Step 2 — Audit ClusterIssuer vs Issuer scope
+
+1. For every ClusterIssuer, determine what namespaces can reference it:
+   - A `ClusterIssuer` has no namespace — any Certificate in any namespace can reference it.
+   - An `Issuer` is namespace-scoped — only Certificates in the same namespace can reference it.
+2. For cloud-backed ClusterIssuers (AWS PCA, Azure Key Vault, Vault), check the authentication method:
+   ```bash
+   # AWS PCA ClusterIssuer — check for IRSA annotation
+   kubectl get clusterissuer <name> -o jsonpath='{.spec.acmepca}' 2>/dev/null
+   kubectl get serviceaccount -n cert-manager cert-manager -o jsonpath='{.metadata.annotations}'
+   ```
+   Flag as **HIGH** if the ClusterIssuer authenticates to a cloud CA using static credentials (AWS access key, Azure client secret) instead of workload identity (IRSA, Azure Workload Identity).
+3. Example of a safely scoped setup vs a risky setup:
+   ```yaml
+   # SAFE: Namespace-scoped Issuer, only one namespace can use it
+   apiVersion: cert-manager.io/v1
+   kind: Issuer
+   metadata:
+     name: internal-ca
+     namespace: payments
+   spec:
+     ca:
+       secretName: payments-ca-secret
+
+   # RISKY: ClusterIssuer for corporate CA with no request policy
+   apiVersion: cert-manager.io/v1
+   kind: ClusterIssuer
+   metadata:
+     name: corp-private-ca
+   spec:
+     acmepca:
+       arn: arn:aws:acm-pca:us-east-1:123456789:certificate-authority/abc
+   ```
+
+### Step 3 — Audit CertificateRequestPolicy coverage
+
+CertificateRequestPolicy is the RBAC layer for PKI. Without it, any Certificate resource is auto-approved.
+
+1. Verify approver-policy is installed:
+   ```bash
+   kubectl get crd certificaterequestpolicies.policy.cert-manager.io
+   ```
+   If not found, record as **CRITICAL**: all certificate requests are auto-approved.
+2. For each CertificateRequestPolicy, inspect the subject constraints:
+   ```bash
+   kubectl get certificaterequestpolicy <name> -o yaml
+   ```
+   Check:
+   - `spec.allowed.dnsNames.values` — which DNS names the policy permits
+   - `spec.allowed.dnsNames.validations` — regex constraints on allowed names
+   - `spec.allowed.subject` — allowed subject distinguished names
+   - `spec.selector.issuerRef` — which issuers this policy covers
+   - `spec.selector.namespace` — which namespaces this policy governs
+3. Example of a correctly constrained CertificateRequestPolicy:
+   ```yaml
+   apiVersion: policy.cert-manager.io/v1alpha1
+   kind: CertificateRequestPolicy
+   metadata:
+     name: payments-internal-certs
+   spec:
+     allowed:
+       dnsNames:
+         values:
+           - "*.payments.svc.cluster.local"
+         validations:
+           - rule: self.endsWith('.payments.svc.cluster.local')
+             message: "DNS name must be in payments namespace service domain"
+       subject:
+         organizations:
+           values: ["payments-team"]
+       usages:
+         - "digital signature"
+         - "key encipherment"
+         - "server auth"
+         - "client auth"
+     selector:
+       issuerRef:
+         name: corp-private-ca
+         kind: ClusterIssuer
+         group: cert-manager.io
+       namespace:
+         matchLabels:
+           team: payments
+   ```
+4. Flag as **CRITICAL** if no CertificateRequestPolicy restricts a ClusterIssuer backed by a corporate or cloud CA.
+5. Flag as **HIGH** if a CertificateRequestPolicy allows `dnsNames` with a wildcard that covers high-value internal FQDNs (e.g., `*.internal.company.com`).
+
+### Step 4 — Audit Certificate SAN and duration
+
+1. For each Certificate, review `spec.dnsNames` for excessive scope:
+   ```bash
+   kubectl get certificate -A -o yaml | grep -A 5 "dnsNames"
+   ```
+2. Flag as **HIGH** any Certificate where a single microservice's cert includes:
+   - `*.internal.company.com` (covers all internal services)
+   - `*.svc.cluster.local` (covers all cluster services)
+3. Review certificate duration and renewal:
+   ```bash
+   kubectl get certificate -A -o custom-columns=\
+   "NAME:.metadata.name,DURATION:.spec.duration,RENEW:.spec.renewBefore,READY:.status.conditions[0].status"
+   ```
+   - Flag as **HIGH** if `duration` exceeds `8760h` (1 year) for workload certs.
+   - Flag as **CRITICAL** if `duration` is `87600h` (10 years) or similar for workload certs.
+   - Flag as **MEDIUM** if `renewBefore` is not set or is less than 1/3 of `duration`.
+4. Verify certificate readiness:
+   ```bash
+   kubectl get certificate -A | grep -v "True"
+   ```
+   Any certificate not in `Ready=True` state that is approaching expiry is a **HIGH** finding.
+
+### Step 5 — Audit cert-manager webhook health
+
+A failing cert-manager webhook blocks all new certificate issuance and renewals.
+
+1. Check webhook pod health:
+   ```bash
+   kubectl get pods -n cert-manager
+   kubectl describe deployment cert-manager-webhook -n cert-manager
+   ```
+2. Check webhook configuration:
+   ```bash
+   kubectl get validatingwebhookconfiguration cert-manager-webhook -o yaml | grep -A 5 "failurePolicy"
+   ```
+   `failurePolicy: Fail` means a webhook outage blocks all cert operations. `failurePolicy: Ignore` means webhook failures are skipped — cert validation is bypassed.
+3. Check for recent CertificateRequest failures:
+   ```bash
+   kubectl get certificaterequest -A | grep -v "True"
+   kubectl describe certificaterequest -A | grep -A 5 "Reason:"
+   ```
+4. Flag as **HIGH** if the cert-manager-webhook deployment has unavailable replicas and any certificates are approaching expiry within 30 days.
+
+### Step 6 — Audit trust-manager Bundle distribution
+
+1. List trust-manager Bundles:
+   ```bash
+   kubectl get bundle -o yaml
+   kubectl get configmapbundle -o yaml 2>/dev/null
+   ```
+2. For each Bundle, check the target namespace selector:
+   ```yaml
+   # RISKY: no namespaceSelector distributes to all namespaces
+   spec:
+     target:
+       configMap:
+         key: "bundle.pem"
+       namespaceSelector: {}   # matches all namespaces
+
+   # SAFE: explicit namespace label selector
+   spec:
+     target:
+       configMap:
+         key: "bundle.pem"
+       namespaceSelector:
+         matchLabels:
+           cert-manager.io/trust-bundle: "enabled"
+   ```
+3. Flag as **MEDIUM** if a Bundle distributes a corporate or cloud CA bundle to all namespaces without a restrictive namespace selector — untrusted workloads receive the CA and can potentially use it for internal service impersonation if combined with a cert issuance gap.
+
+### Step 7 — Audit SPIFFE / service mesh CA integration
+
+1. Check if cert-manager is serving as the Istio CA via istio-csr:
+   ```bash
+   kubectl get pods -n istio-system | grep cert-manager
+   kubectl get cm istio -n istio-system -o yaml | grep caAddress
+   ```
+2. If cert-manager feeds the mesh trust domain, the ClusterIssuer it references is the root of trust for all SPIFFE SVIDs in the mesh.
+   - A compromised ClusterIssuer in this scenario allows forging any SPIFFE SVID for any mesh workload.
+   - Flag as **HIGH** if the mesh CA ClusterIssuer uses a shared corporate private CA without CertificateRequestPolicy constraints on the istio-csr service account.
+3. For Linkerd:
+   ```bash
+   kubectl get secret linkerd-identity-issuer -n linkerd -o yaml | grep -v "^  tls"
+   ```
+   Verify the issuer cert expiry is managed by cert-manager and has a `renewBefore` set.
+
+## Output
+
+Return:
+
+- **target**: ClusterIssuer/Issuer names, Certificate references, or CertificateRequestPolicy names, with evidence source,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **issuer scope**: namespace-scoped Issuer or cluster-wide ClusterIssuer, backing CA type, authentication method (workload identity vs static credentials),
+- **CertificateRequestPolicy coverage**: present/absent, constrained issuers, allowed DNS names scope, namespace selector,
+- **certificate SAN and duration audit**: wildcard SAN findings, duration exceeding recommended thresholds, renewBefore settings,
+- **webhook health**: cert-manager-webhook pod state, failurePolicy, any CertificateRequest failures,
+- **trust-manager posture**: Bundle distribution scope, namespace selector presence,
+- **mesh integration**: whether cert-manager feeds a mesh CA and the blast radius of that issuer,
+- **risk findings** (with severity: critical / high / medium / low),
+- **safest next actions** with sample YAML,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend removing CertificateRequestPolicy to unblock a blocked cert request — the correct path is to add an appropriate policy.
+- Never request or print CA private key contents, PKCS#12 bundles, Vault tokens, or AWS credentials.
+- A ClusterIssuer backed by a corporate Private CA with no CertificateRequestPolicy is equivalent to an open PKI endpoint — any namespace can issue trusted certs for any FQDN.
+- Always confirm approver-policy CRD presence before concluding that cert requests are constrained.
+- cert-manager `failurePolicy: Ignore` on the webhook means the webhook can be bypassed — verify this is not used in production cert issuance paths for sensitive CAs.

package/skills/cilium/README.md

@@ -0,0 +1,30 @@
+# 🐝 Cilium Skills
+
+<p align="center">
+  <!-- 🖼️ Add a Cilium logo to assets/logos/cnative/cilium/ and update this path -->
+  <span style="font-size:3.5em">🐝</span>
+</p>
+
+This folder contains Cilium-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Cilium skill:
+
+- `cilium-network-policy-review`
+
+## Portfolio posture
+
+Cilium skills for evidence-backed eBPF networking review covering the three policy formats (`NetworkPolicy`, `CiliumNetworkPolicy`, `CiliumClusterwideNetworkPolicy`), L7 policy via embedded Envoy, ClusterMesh cross-cluster semantics, Hubble flow observability, and `CiliumEgressGatewayPolicy` for SNAT egress.
+
+These skills are intentionally conservative:
+
+- prefer `kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies,ciliumegressgatewaypolicies -A -o yaml` for live policy state grounding before any review
+- treat **removal of a default-deny `NetworkPolicy`** as a critical finding — pods become reachable from any source/destination
+- challenge `CiliumNetworkPolicy` egress with `toCIDRSet: [0.0.0.0/0]` — unrestricted egress = data exfiltration path
+- challenge `policy-default-local-cluster` flag changes in ClusterMesh — cross-cluster policy semantics change globally for every existing policy
+- challenge `CiliumEgressGatewayPolicy` IP collisions — two policies SNATing to the same IP cause silent connection breakage
+- prefer `cilium clustermesh inspect-policy-default-local-cluster` before any flag flip — it lists every policy that would change behavior
+- use official Cilium documentation (docs.cilium.io) for policy syntax, CRD versions, ClusterMesh setup, and L7 policy semantics
+
+Run `npm run validate` after changing cataloged Cilium skills.