@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

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

@@ -0,0 +1,106 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the policy and its scope
+
+1. Confirm the policy kind: `ValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, `ImageValidatingPolicy` (stable `policies.kyverno.io/v1`), or legacy `ClusterPolicy` / `Policy`.
+2. Confirm the match scope: namespace-scoped (`Policy`) vs cluster-scoped (`ClusterPolicy` / new v1 kinds).
+3. Confirm the API version. The stable `policies.kyverno.io/v1` API is the recommended target — see the [Kyverno policy types overview](https://kyverno.io/docs/policy-types/overview/).
+4. Confirm match conditions in `spec.match` — kinds, names, namespaces, labels, annotations. Any `kinds: ['*']` with no further filter is high-blast-radius.
+
+### Step 2 — Identify the failure mode
+
+1. Locate `spec.rules[].validate.failureAction` (newer API) or `spec.validationFailureAction` (legacy).
+2. Two values exist: `Enforce` (admission denied on violation) and `Audit` (admission allowed, violation recorded in PolicyReport).
+3. **Critical finding**: any production-relevant policy with `failureAction: Audit` and no plan to migrate to `Enforce`. The policy is a logging shim, not a control.
+4. Also confirm `spec.background` — when `false`, the policy only evaluates at admission time; existing resources are not scanned.
+5. Reference: [Validate rules — failureAction semantics](https://kyverno.io/docs/policy-types/cluster-policy/validate/).
+
+### Step 3 — Challenge dangerous policy patterns
+
+Flag the following as high-severity findings:
+
+- **`failureAction: Audit` in production** — silent allow path; PolicyReports accumulate without enforcement.
+- **`background: false` + match scope that does not match admission requests** — policy never runs; effectively dead code.
+- **`match` with `kinds: ['*']` and no namespace selector** — cluster-wide blast radius; one mis-written CEL expression breaks every admission.
+- **`exclude` clause that exempts entire `kube-system` or operator namespaces** — operators bypass policy that should still apply (e.g., image signing).
+- **`failurePolicy: Ignore` on the underlying ValidatingWebhookConfiguration** — Kyverno controller failures silently allow. See the [Kubernetes admission webhook reference](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/).
+- **CEL expressions referencing `request.userInfo` without a deny default** — easy to bypass with a service account named in an exception.
+
+### Step 4 — Audit every PolicyException
+
+A PolicyException is a documented bypass. Treat every one as audit evidence requiring four facts:
+
+1. **Owner**: who created it and is on call for the exempted resources?
+2. **Reason**: why does this resource not meet the policy?
+3. **Expiry**: is there a date or condition under which this exception is removed? Kyverno does not enforce expiry — this must be a documented commitment.
+4. **Scope**: which resources, namespaces, and rules are exempted?
+
+Reference: [Kyverno PolicyExceptions](https://kyverno.io/docs/exceptions/).
+
+Stress-test exceptions:
+
+- An exception with `match.any.resources.kinds: ['*']` exempts everything — almost always too broad.
+- An exception that exempts the `default` ServiceAccount — effectively exempts every workload that hasn't bound an SA.
+- An exception that exempts a `ClusterPolicy` with `failureAction: Enforce` quietly demotes the policy to `Audit` for the matched scope.
+
+### Step 5 — Audit ImageValidatingPolicy specifically
+
+For `ImageValidatingPolicy` (and legacy `verifyImages` rules), confirm:
+
+1. **Public key or KMS key reference** is present and points to a real attestation root (Sigstore / Cosign / Notary / KMS-backed).
+2. **`mutateDigest: true`** — replaces the mutable image tag with the immutable digest at admission. Without this, the verified image can be replaced after admission.
+3. **`verifyDigest: true`** — re-checks the digest against the verified attestation chain.
+4. **`required: true`** on the verification rule — without this, missing signatures pass.
+5. **`match` covers all production registries**, not just public Docker Hub.
+6. **No `imageReferences: ['*']` with `skip: true`** — total signature bypass.
+
+Reference: [Kyverno verify-images / ImageValidatingPolicy](https://kyverno.io/docs/policy-types/cluster-policy/verify-images/).
+
+### Step 6 — Evaluate Kyverno vs native ValidatingAdmissionPolicy (CEL)
+
+Native `ValidatingAdmissionPolicy` (CEL) shipped stable in Kubernetes 1.30 ([reference](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)). Kyverno can compile its own policies into native VAP — see [Kyverno docs on VAP generation](https://kyverno.io/docs/policy-types/cluster-policy/validate/).
+
+Choose **native VAP** when:
+
+- The policy is pure validation (no mutation, no generation, no image verification, no cleanup).
+- The CEL expression alone is sufficient — no JMESPath, no API lookup, no `context.apiCall`, no foreach.
+- You want fewer moving parts in the admission path (no Kyverno controller).
+
+Stay with **Kyverno** when:
+
+- You need mutation, generation, cleanup, or image verification.
+- You need cross-resource lookups (`context.apiCall`).
+- You need PolicyReports for compliance evidence.
+- You need PolicyExceptions managed declaratively.
+
+Recommend a path explicitly. "Could be native VAP" without a recommendation is incomplete review.
+
+### Step 7 — Stress-test operational hygiene
+
+- Prefer policies authored with `policies.kyverno.io/v1` over legacy `kyverno.io/v1` — the new API is the long-term path.
+- Prefer explicit `match.any.resources.kinds` lists over wildcards.
+- Prefer policies with `background: true` so existing resources are scanned (catches drift).
+- Prefer policies that emit clear `message` text — admission rejections show this string to the user, and a vague rejection message wastes engineer time.
+- Reports Server should be installed when policy reports are needed at scale — etcd-backed PolicyReports do not scale beyond a few thousand violations. See [Kyverno installation](https://kyverno.io/docs/installation/).
+
+## Output
+
+Return:
+
+- **target**: policy kind, name, match scope, and API version,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **failure mode**: `Enforce` vs `Audit`, with judgment on whether this matches production posture,
+- **risk findings** (with severity: high / medium / low) — including PolicyException audit, image verification posture, wildcard match, and admission webhook failurePolicy,
+- **architectural recommendation**: stay with Kyverno, migrate to native VAP, or hybrid — with reason,
+- **safest next actions** with sample manifest changes,
+- **rollback plan**: how to remove or revert the policy without breaking running workloads,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend `failureAction: Audit` for a production-tier policy unless there is a written rollout plan to `Enforce` with a date.
+- Never recommend exempting `cluster-admin`, the controller's own ServiceAccount, or wildcards in PolicyExceptions.
+- Never recommend disabling image signature verification "temporarily" without a tracked re-enable date.
+- Do not print Cosign private keys, Rekor signature blobs, or registry credentials. Reference key names only.

package/skills/oci/README.md

@@ -0,0 +1,63 @@
+# 🟥 OCI Skills
+
+<p align="center">
+  <img src="../../assets/logos/cloud/oci/oracle-cloud-infrastructure.png" alt="Oracle Cloud Infrastructure logo" width="140" />
+</p>
+
+This folder contains OCI-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **37** local OCI skills:
+
+- `oci-autonomous-database-architect`
+- `oci-cloud-guard-responder`
+- `oci-compute-instance-agent-operator`
+- `oci-compute-platform-operator`
+- `oci-cost-finops-analyst`
+- `oci-database-platform-dba`
+- `oci-dbtools-sql-analyst`
+- `oci-devops-container-platform-engineer`
+- `oci-exadata-database-architect`
+- `oci-exadata-platform-architect`
+- `oci-fusion-apps-environment-operator`
+- `oci-goldengate-replication-operator`
+- `oci-identity-access-governor`
+- `oci-iot-digital-twin-engineer`
+- `oci-limits-capacity-planner`
+- `oci-live-autonomous-db-lifecycle-guard`
+- `oci-live-cost-budget-runaway-guard`
+- `oci-live-iam-policy-compartment-guard`
+- `oci-live-network-security-rule-guard`
+- `oci-live-oke-rollout-guard`
+- `oci-live-resource-manager-stack-guard`
+- `oci-live-vault-key-destruction-guard`
+- `oci-load-balancer-traffic-engineer`
+- `oci-maestro`
+- `oci-migration-cutover-architect`
+- `oci-multi-cloud-architect`
+- `oci-mysql-heatwave-ai-specialist`
+- `oci-network-architect`
+- `oci-observability-incident-responder`
+- `oci-recovery-service-operator`
+- `oci-registry-artifact-governor`
+- `oci-resource-search-inventory-analyst`
+- `oci-security-compliance-reviewer`
+- `oci-solution-architect`
+- `oci-storage-backup-steward`
+- `oci-support-incident-coordinator`
+- `oracle-oci-mcp-grounded-advisor`
+
+## Portfolio posture
+
+Role-based OCI skills for evidence-backed architecture, database operations, security, networking, FinOps, identity governance, and guarded live-environment operations.
+
+These skills are intentionally conservative:
+
+- prefer `oracle-oci-mcp-grounded-advisor` via OCI MCP server when available for live OCI state grounding
+- prefer read-only discovery before mutation
+- require explicit OCID, compartment, tenancy confirmation, approval, rollback posture, and verification for guarded live actions
+- challenge overly broad IAM policies, missing compartment isolation, public exposure, and unclear resource ownership
+- use official OCI documentation and live CLI evidence when service behavior matters
+
+Run `npm run validate` after changing cataloged OCI skills.

package/skills/oci/oci-certificates-issuer-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: oci-certificates-issuer-review
+description: Use this skill when reviewing OCI Certificates Service issuer configurations for cert-manager on OKE. Trigger on any request to audit OCI CA hierarchy, issuance rules, OKE Workload Identity vs Instance Principal auth, IAM policy scope, OCSP reachability, or certificate version management.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# OCI Certificates Issuer Review
+
+## Purpose
+
+Review Oracle Cloud Infrastructure (OCI) Certificates Service configurations used as cert-manager issuers on OKE (Oracle Kubernetes Engine). Identify CA hierarchy misconfigurations (root vs subordinate), missing issuance rules, overly broad IAM policies, Instance Principal authentication scope risks, OCSP reachability gaps, and certificate version accumulation. Output severity-labeled findings with evidence and remediation steps.
+
+## Lean operating rules
+
+- Flag any OCI issuer that references a ROOT CA directly as CRITICAL — only a SUBORDINATE CA should be used for cert-manager issuance. The ROOT CA must be offline (disabled after subordinate creation) or kept entirely out of the Certificates Service.
+- Check whether OCI issuance rules are configured on the subordinate CA: flag missing validity caps (>90d) and missing key algorithm restrictions (RSA <2048 or EC <P-256) as MEDIUM.
+- Identify the authentication method used by cert-manager to call OCI APIs: flag Instance Principal auth as HIGH — any pod on the OKE node can call the OCI Certificates API via instance metadata. Correct method is OKE Workload Identity (SA-bound, pod-level).
+- Review the OCI IAM policy for cert-manager: flag `manage certificate-authorities` (grants delete/update CA) as HIGH. Minimum required: `use certificate-authorities` with `request.permission='CREATE_CERTIFICATE_REQUEST'`.
+- Check OCSP reachability from OKE worker nodes to `ocsp.pki.oraclecloud.com`. Flag unreachable OCSP endpoint as MEDIUM (soft-fail revocation = revoked certs accepted by most TLS stacks).
+- Review certificate version count; flag high version accumulation (> 10 versions per cert) as LOW (storage cost and management overhead).
+- Label all findings as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Severity-labeled findings list (CRITICAL / HIGH / MEDIUM / LOW)
+- Evidence source for each finding
+- Specific resource name, CA OCID, or IAM policy statement that caused the finding
+- Recommended remediation with example OCI CLI command or IAM policy snippet
+- Overall OCI PKI trust posture verdict

package/skills/oci/oci-certificates-issuer-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "oci-certificates-issuer-review",
+  "name": "OCI Certificates Issuer Review",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review OCI Certificates Service issuer configurations for cert-manager on OKE, covering CA hierarchy safety, issuance rule enforcement, OKE Workload Identity vs Instance Principal authentication, IAM policy scope minimization, OCSP reachability, and certificate version lifecycle management.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/certificates/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/certificates/managing-certificate-authority.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingworkloadidentity.htm",
+    "https://github.com/oracle/oci-native-ingress-controller"
+  ],
+  "security_notes": "Instance Principal auth for cert-manager on OKE means ANY pod on the node can call the OCI Certificates API using the instance metadata endpoint — not just cert-manager. Use OKE Workload Identity to scope cert-issuance permissions to the cert-manager ServiceAccount only. IAM policy with 'manage certificate-authorities' grants delete and update CA permissions, which is excessive for cert-manager.",
+  "last_verified": "2026-05-02",
+  "path": "skills/oci/oci-certificates-issuer-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-certificates-issuer-review/references/workflow-and-output.md

@@ -0,0 +1,207 @@
+# Workflow and Output Contract
+
+## Review Workflow
+
+### Step 1 — Identify the CA and issuer configuration
+
+Retrieve the OCI cert-manager issuer resource:
+
+```bash
+kubectl get issuer -A -o yaml | grep -A20 "oci\|oracle"
+kubectl get clusterissuer -o yaml | grep -A20 "oci\|oracle"
+```
+
+Extract the CA OCID from the issuer spec. Then inspect the CA in OCI:
+
+```bash
+oci certs-mgmt certificate-authority get \
+  --certificate-authority-id <ca-ocid>
+```
+
+Key fields to check:
+- `type` — must be `SUBORDINATE` (not `ROOT`)
+- `lifecycleState` — must be `ACTIVE`
+- `issuerCertificateAuthorityId` — should reference a ROOT CA that is itself INACTIVE or not used for direct issuance
+
+### Step 2 — Validate CA type (root vs subordinate)
+
+```bash
+oci certs-mgmt certificate-authority get \
+  --certificate-authority-id <ca-ocid> \
+  --query data.config-type \
+  --raw-output
+```
+
+Expected values:
+- `SUBORDINATE_CA_ISSUED_BY_INTERNAL_CA` — correct for cert-manager usage
+- `ROOT_CA_GENERATED_INTERNALLY` — CRITICAL finding; root directly exposed to cert-manager
+
+Also check the issuer CA's status:
+```bash
+oci certs-mgmt certificate-authority get \
+  --certificate-authority-id <ca-ocid> \
+  --query data.lifecycle-state \
+  --raw-output
+```
+
+### Step 3 — Review issuance rules
+
+List issuance rules configured on the CA:
+
+```bash
+oci certs-mgmt certificate-authority get \
+  --certificate-authority-id <ca-ocid> \
+  --query "data.certificate-authority-rules"
+```
+
+Check for:
+
+```json
+{
+  "ruleType": "CERTIFICATE_AUTHORITY_MAX_VALIDITY_RULE",
+  "certificateMaxValidityDuration": "P90D"
+}
+```
+
+And key algorithm restriction:
+
+```json
+{
+  "ruleType": "CERTIFICATE_AUTHORITY_ISSUANCE_EXPIRY_RULE",
+  "leafCertificateMaxValidityDuration": "P90D",
+  "certificateAuthorityMaxValidityDuration": "P3650D"
+}
+```
+
+**Flags:**
+- No issuance rules configured (no validity cap) — MEDIUM (cert-manager can issue 10-year workload certs)
+- Max validity > 365d for leaf certificates — MEDIUM
+- No key algorithm restriction — MEDIUM (RSA-1024 issuance possible)
+
+### Step 4 — Identify authentication method
+
+Check the cert-manager configuration for OCI auth method:
+
+```bash
+# Check if OKE Workload Identity is configured
+kubectl get serviceaccount cert-manager -n cert-manager \
+  -o jsonpath='{.metadata.annotations}'
+```
+
+For OKE Workload Identity, the ServiceAccount should have OCI annotations:
+
+```yaml
+annotations:
+  oci.oraclecloud.com/role-binding: "<dynamic-group-name>"
+```
+
+For Instance Principal auth, check if the cert-manager pod uses the instance metadata endpoint:
+
+```bash
+# Check the cert-manager deployment for OCI config
+kubectl get deployment cert-manager -n cert-manager -o yaml | grep -i "oci\|instance\|workload"
+```
+
+**Auth method comparison:**
+
+| Method | Scope | Risk |
+|--------|-------|------|
+| OKE Workload Identity | ServiceAccount-bound (pod-level) | Correct — minimum scope |
+| Instance Principal | Node-level (all pods on node) | HIGH — any pod can issue certs |
+| User auth (API key) | User credentials in secret | HIGH — credential rotation required |
+
+### Step 5 — Review IAM policy
+
+Retrieve the IAM policy for cert-manager:
+
+```bash
+oci iam policy list --compartment-id <compartment-id> --all \
+  --query "data[?contains(statements[0], 'certificate-authority')]"
+```
+
+Minimum required policy statement:
+
+```
+Allow dynamic-group CertManagerDynamicGroup to use certificate-authorities
+  in compartment <compartment-name>
+  where request.permission='CREATE_CERTIFICATE_REQUEST'
+```
+
+**Flag as HIGH if the policy includes any of:**
+- `manage certificate-authorities` (grants delete, update, disable, schedule-deletion)
+- `manage certificates` without compartment scoping (affects all certs)
+- Wildcard resources or compartment `tenancy` instead of scoped compartment
+
+Additional permissions needed for cert-manager to retrieve issued certs:
+
+```
+Allow dynamic-group CertManagerDynamicGroup to read certificates
+  in compartment <compartment-name>
+```
+
+### Step 6 — Check OCSP reachability
+
+The OCI OCSP endpoint is `ocsp.pki.oraclecloud.com`. Verify reachability from OKE worker nodes:
+
+```bash
+# From within an OKE node or debug pod
+curl -sv https://ocsp.pki.oraclecloud.com/
+```
+
+For OKE clusters with no internet gateway or restrictive security group rules:
+
+```bash
+# Check security list / NSG rules for outbound HTTPS to OCI OCSP
+oci network security-list list --vcn-id <vcn-id> \
+  --query "data[].egress-security-rules[]"
+```
+
+OCI OCSP endpoints use HTTPS (443). Ensure the OKE worker node security group allows outbound TCP/443 to OCI service endpoints. Using a Service Gateway with the `OCI Services in Oracle Services Network` service covers OCI PKI endpoints.
+
+**Flags:**
+- No Service Gateway configured and no internet gateway (OCI OCSP unreachable) — MEDIUM
+- Security group blocks TCP/443 outbound to OCI service network — MEDIUM
+
+### Step 7 — Review certificate version count
+
+```bash
+oci certs-mgmt certificate list-certificate-versions \
+  --certificate-id <cert-ocid> \
+  --all \
+  --query "length(data)"
+```
+
+Each cert rotation by cert-manager creates a new version. Old versions should be cleaned up to avoid high version counts.
+
+**Flags:**
+- Certificate version count > 10 — LOW (storage cost and management overhead)
+- No automated cleanup of old versions configured — LOW
+
+---
+
+## Output Format
+
+### Finding: `<short title>`
+
+| Field | Value |
+|-------|-------|
+| Severity | CRITICAL / HIGH / MEDIUM / LOW |
+| Resource | CA OCID, IAM policy name, or cert name |
+| Evidence | documentation-based / live evidence / inference |
+| Description | What is wrong and its impact on PKI trust |
+| Remediation | OCI CLI command, IAM policy statement, or configuration change |
+
+---
+
+### Overall OCI PKI Trust Posture
+
+| Category | Status |
+|----------|--------|
+| CA hierarchy (subordinate only) | PASS / FAIL |
+| Issuance rules (validity caps) | PASS / FAIL |
+| Authentication method (Workload Identity) | PASS / FAIL |
+| IAM policy scope (minimum permissions) | PASS / FAIL |
+| OCSP reachability | PASS / FAIL |
+| Certificate version lifecycle | PASS / FAIL |
+
+**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)

package/skills/oci/oci-live-network-security-rule-guard/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: oci-live-network-security-rule-guard
+description: Guard live OCI Security List and Network Security Group (NSG) rule changes with current-state capture, open-internet and sensitive-port detection, stateful/stateless assessment, and explicit approval before ingress or egress rule mutation. Use only when an intentional network rule change targets a confirmed VCN component.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# OCI Live Network Security Rule Guard
+
+## Purpose
+
+Act as the guarded live OCI operator for oci-live-network-security-rule-guard work. Security List and NSG rule changes take effect immediately with no native rollback. A wrong ingress rule exposes databases or compute to the internet instantly; a wrong egress rule can black-hole traffic for entire subnets. Treat every rule mutation as irreversible until the previous state is explicitly captured and restoration is confirmed possible.
+
+## When to use
+
+Use this skill when:
+
+- an ingress or egress rule must be added, modified, or removed from an OCI Security List or NSG in a live VCN
+- a network access audit finds over-broad CIDR blocks (`0.0.0.0/0`) or sensitive-port exposures that must be tightened
+- a workload migration requires opening or closing ports and the blast radius must be confirmed before write
+
+## Lean operating rules
+
+- Prefer OCI CLI (`oci`) official documentation when available; fall back to Oracle Cloud docs and sanitized user evidence.
+- Do not execute any Security List or NSG rule mutation until tenancy, compartment, VCN OCID, target Security List or NSG OCID, and exact rule change are all explicit.
+- Capture the complete current rule set (`oci network security-list get` or `oci network nsg rules list`) as rollback evidence before any write.
+- Flag the following as high-severity and require explicit justification before proceeding:
+  - Any ingress rule with source `0.0.0.0/0` (open to internet)
+  - Any egress rule with destination `0.0.0.0/0` and protocol `all` without restriction
+  - Rules permitting port 22 (SSH), 3389 (RDP), 1521/1522 (Oracle DB), 3306 (MySQL), 5432 (PostgreSQL) from `0.0.0.0/0`
+  - Stateless rules on subnets hosting databases or internal APIs (no connection tracking = asymmetric traffic risk)
+  - Changes to Security Lists attached to database subnets (Autonomous DB, Exadata, DB System)
+- If the request skips current-state capture, CIDR scope confirmation, or subnet-criticality assessment, push back.
+- Never print API signing keys, auth tokens, tenancy OCIDs, or instance credentials. Summarize sanitized evidence only.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Preflight commands](references/preflight-commands.md) — OCI CLI commands to inspect current rules and capture rollback state before any mutation.
+- [Rollback playbook](references/rollback-playbook.md) — how to restore a previous Security List or NSG rule set after a bad change.
+- [Permission model](references/permission-model.md) — least-privilege IAM policy for network rule mutation and read-only audit.
+- [Official sources](references/official-sources.md) — authoritative OCI documentation links.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed tenancy, compartment, VCN, and target Security List or NSG OCID
+- current rule set capture (rollback baseline)
+- risk classification of the proposed rule (open-internet / sensitive-port / safe)
+- stateful vs stateless assessment and subnet criticality
+- approval status with explicit business justification
+- rollback command to restore prior rule state
+- post-change connectivity verification steps or refusal reason

package/skills/oci/oci-live-network-security-rule-guard/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "oci-live-network-security-rule-guard",
+  "name": "OCI Live Network Security Rule Guard",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guard live OCI Security List and NSG rule changes with current-state capture, open-internet and sensitive-port detection, stateful/stateless assessment, and explicit approval before ingress or egress mutation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/securitylists.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/manage-nsg-security-rules.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/update-securitylist.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.htm"
+  ],
+  "security_notes": "oci network security-list update is a full replace — always capture the complete current rule set before writing. Never approve 0.0.0.0/0 ingress rules on database subnets. Prefer NSGs over Security Lists for production database VNICs to minimize blast radius. Enable VCN Flow Logs before any rule change for forensic coverage.",
+  "last_verified": "2026-05-01",
+  "path": "skills/oci/oci-live-network-security-rule-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/oci/oci-live-network-security-rule-guard/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Security Lists](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/securitylists.htm) — use for Security List model, ingress/egress rule structure, stateful vs stateless semantics, and maximum rule limits.
+- [Network Security Groups](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm) — use for NSG model, VNIC-level vs subnet-level application, and NSG vs Security List trade-offs.
+- [Managing NSG Security Rules](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/manage-nsg-security-rules.htm) — use for `oci network nsg rules add`, `update`, `remove`, and `list` CLI syntax.
+- [Updating a Security List](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/update-securitylist.htm) — use for `oci network security-list update` full-replace semantics and required parameters.
+- [Network Path Analyzer](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.htm) — use for simulating end-to-end network paths through Security Lists, NSGs, route tables, and gateways before approving a rule change.
+- [VCN Flow Logs](https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/vcn-flow-logs.htm) — use when enabling forensic coverage for a subnet before or after a security rule change.
+- [OCI IAM Policy Reference — Network](https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/networkpolicyreference.htm) — use for least-privilege IAM policy statements covering `security-lists`, `network-security-groups`, and `virtual-network-family`.
+
+## Grounded insights worth carrying into the skill
+
+- `oci network security-list update` performs a **full replace** of the entire ingress or egress rule set — partial updates are not possible. Always pass the complete desired rule list including rules you want to keep.
+- OCI Security Lists are **stateful by default** (`stateless: false`). Return traffic is automatically allowed. Stateless rules require explicit return rules and are a common source of asymmetric traffic failures.
+- NSG rule IDs are required for deletion (`oci network nsg rules remove`). Capture rule IDs from `oci network nsg rules list` before any mutation.
+- A Security List is attached to a subnet, not a VNIC. One change affects every instance in that subnet simultaneously — blast radius scales with subnet size.
+- NSGs are attached to individual VNICs, giving finer-grained control but requiring per-VNIC management. Prefer NSGs for production database servers over Security Lists for reduced blast radius.
+- VCN Flow Logs must be explicitly enabled per subnet — they are not on by default. Without them, there is no record of traffic through an accidentally opened rule.
+- The `0.0.0.0/0` ingress source in OCI context still includes traffic from peered VCNs, DRG-attached networks, and FastConnect circuits if routing allows — it is never safe to assume it means "internet only."

package/skills/oci/oci-live-network-security-rule-guard/references/permission-model.md

@@ -0,0 +1,65 @@
+# Permission Model: OCI Live Network Security Rule Guard
+
+## Least-privilege IAM policy for network rule read (preflight only)
+
+```
+Allow group NetworkAuditors to read virtual-network-family in compartment <compartment>
+Allow group NetworkAuditors to read vcns in compartment <compartment>
+Allow group NetworkAuditors to read security-lists in compartment <compartment>
+Allow group NetworkAuditors to read network-security-groups in compartment <compartment>
+Allow group NetworkAuditors to read subnets in compartment <compartment>
+Allow group NetworkAuditors to read db-systems in compartment <compartment>
+Allow group NetworkAuditors to read autonomous-databases in compartment <compartment>
+```
+
+Read-only audit: use `inspect` or `read` verbs only. Never `manage` for auditors.
+
+## Least-privilege IAM policy for network rule mutation (guarded operator only)
+
+```
+Allow group NetworkOperators to manage security-lists in compartment <compartment>
+Allow group NetworkOperators to manage network-security-groups in compartment <compartment>
+Allow group NetworkOperators to read vcns in compartment <compartment>
+Allow group NetworkOperators to read subnets in compartment <compartment>
+```
+
+Do **not** grant `manage virtual-network-family` — that is broader than needed and includes VCN, route tables, internet gateways, and peering.
+
+## Risk classification by rule type
+
+| Rule | Risk | Reason |
+|---|---|---|
+| Ingress `0.0.0.0/0` any protocol | Critical | Open internet access to entire subnet |
+| Ingress `0.0.0.0/0` port 22 | Critical | SSH from internet — never acceptable in production |
+| Ingress `0.0.0.0/0` port 3389 | Critical | RDP from internet — never acceptable in production |
+| Ingress `0.0.0.0/0` port 1521/1522 | Critical | Oracle DB from internet — data exfiltration path |
+| Ingress `0.0.0.0/0` port 3306/5432 | Critical | MySQL/PostgreSQL from internet |
+| Ingress from VCN CIDR, specific port | Low | Internal only — verify VCN CIDR is not transit-routed |
+| Egress `0.0.0.0/0` all | Medium | Standard but verify no data-loss risk for DB subnets |
+| Stateless rule on DB subnet | High | No connection tracking — asymmetric TCP risk |
+
+## Stateful vs stateless
+
+- **Stateful** (default, `stateless: false`): OCI tracks connection state and automatically allows return traffic. Use for all production workloads.
+- **Stateless** (`stateless: true`): Higher performance, but return traffic requires an explicit rule in the opposite direction. A missing return rule silently drops responses. Only use when performance benchmarked at scale.
+
+## Subnet criticality classification
+
+| Subnet pattern | Classification |
+|---|---|
+| Hosts Autonomous DB, DB System, Exadata | Database — highest protection |
+| Hosts compute instances with public IP | Public compute — ingress rules must be minimal |
+| Private subnet (`prohibit-public-ip: true`) | Internal — `0.0.0.0/0` still covers all VCN-routed traffic |
+| Bastion subnet | Bastion — SSH/RDP ingress from known CIDRs only |
+
+## OCI Network Path Analyzer — preferred verification tool
+
+Before approving a connectivity change, use Path Analyzer to simulate the traffic path:
+```bash
+oci network path-analyzer-test create \
+  --compartment-id <COMPARTMENT_OCID> \
+  --protocol-parameters '{"type":"TCP","destinationPort":<PORT>}' \
+  --source-endpoint '{"type":"COMPUTE_INSTANCE","instanceId":"<INSTANCE_OCID>"}' \
+  --destination-endpoint '{"type":"IP_ADDRESS","address":"<DEST_IP>"}'
+```
+Path Analyzer respects Security Lists, NSGs, route tables, and service gateways — use it as the final approval gate for any rule change.