[REVIEW] container-security: add RuntimeClass and admission policy evidence gates

[hermesbountyhunter]

Skill Being Reviewed

Skill name: container-security
Skill path: skills/cloud/container-security/

False Positive Analysis

Benign code that triggers a false positive:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      initContainers:
        - name: volume-permissions
          image: busybox:1.36@sha256:4be8f0d59d41a3a494f1c350f064a9f1c8b3b7595510e164e47f2c6d3fda25a2
          command: ["sh", "-c", "chown -R 65532:65532 /work"]
          securityContext:
            runAsUser: 0
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: work
              mountPath: /work
      containers:
        - name: app
          image: ghcr.io/example/app@sha256:1111111111111111111111111111111111111111111111111111111111111111
          securityContext:
            runAsUser: 65532
            runAsGroup: 65532
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
      volumes:
        - name: work
          emptyDir: {}

Why this is a false positive:

The skill's severity table uses "running as root" as a high-severity example and the common pitfalls correctly note that init containers must be reviewed. However, not every root-running init container has the same risk as a root application container. A short-lived init container that only changes ownership on an emptyDir, drops all capabilities, denies privilege escalation, uses RuntimeDefault seccomp, has no hostPath, and is digest-pinned is still a policy exception, but it should be scored differently from a long-running root workload with host mounts or broad capabilities. The report should require reviewers to capture container type, duration, mounts, capabilities, and compensating controls before assigning severity.

Coverage Gaps

Missed variant 1: RuntimeClass / sandboxed runtime evidence is not collected

apiVersion: apps/v1
kind: Deployment
metadata:
  name: untrusted-plugin-runner
spec:
  template:
    spec:
      runtimeClassName: gvisor
      containers:
        - name: runner
          image: ghcr.io/example/plugin-runner@sha256:2222222222222222222222222222222222222222222222222222222222222222
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

Why it should be caught:

For multi-tenant runners, plugin execution, CI workloads, or untrusted document/media processing, the isolation boundary may depend on RuntimeClass choices such as gVisor, Kata Containers, or another sandboxed runtime. The current skill checks ordinary Pod Security controls but does not ask reviewers to identify whether high-risk workloads use the default runtime versus a sandboxed runtime, nor whether the referenced RuntimeClass object exists and is approved for that namespace.

Missed variant 2: Admission controls may mutate or validate security context after manifests are reviewed

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-runtime-default-seccomp
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-runtime-default
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        pattern:
          spec:
            securityContext:
              seccompProfile:
                type: RuntimeDefault

Why it should be caught:

The skill mentions OPA/Gatekeeper in the use cases, but the main process and report template do not require evidence from Kyverno, Gatekeeper, or Kubernetes ValidatingAdmissionPolicy/MutatingAdmissionPolicy resources. That can create both false negatives (a manifest looks unsafe but is blocked/mutated before admission) and false positives (a manifest looks safe but the policy is only Audit, excludes the namespace, or has a broad exception). Reviewers should record policy engine, mode (Enforce vs Audit/dry-run), namespace selectors, exception resources, and whether policies cover init and ephemeral containers.

Edge Cases

• A runtimeClassName string in a Pod is not enough evidence by itself; the review should check for a matching RuntimeClass object and, when possible, the handler/runtime implementation used by the cluster.
• Admission policies often have namespace or service-account exceptions. A policy existing in the repo should not be counted as protection unless the workload under review is actually selected by it.
• Kubernetes' newer CEL-based admission policies can enforce controls without Gatekeeper/Kyverno CRDs, so discovery should include ValidatingAdmissionPolicy, ValidatingAdmissionPolicyBinding, MutatingAdmissionPolicy, and MutatingAdmissionPolicyBinding manifests.
• Root init containers should be treated as scoped exceptions requiring justification and compensating controls, not automatically bucketed with privileged long-running application containers.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: The existing remediation guidance is strong for non-root users, capabilities, network policies, and read-only filesystems. It would be stronger if it added an evidence matrix for runtime isolation and admission policy enforcement, and if it separated "root init container with tight constraints" from "root application container with broad privileges" in severity guidance.

Comparison to Other Tools

Tool	Catches this?	Notes
Semgrep	Partial	Semgrep can flag Kubernetes fields such as privileged containers or missing runAsNonRoot, but repository-local rules usually cannot prove whether a RuntimeClass exists in-cluster or whether admission policies are enforced for a namespace.
CodeQL	No	CodeQL is not typically used for Kubernetes admission-policy reachability or runtime-class validation.
Other: Kyverno / Gatekeeper / Kubernetes admission	Partial	These tools can enforce the desired controls at admission time, but a source review still needs to verify policy mode, selectors, exceptions, and workload coverage.

Overall Assessment

Strengths:

• Clear mapping to CIS Docker, CIS Kubernetes, NIST SP 800-190, and Pod Security Standards.
• Good coverage of common high-impact misconfigurations: privileged pods, host namespaces, missing network policies, wildcard RBAC, writable root filesystems, and plaintext secrets.
• Useful practical pitfalls around init/sidecar coverage, Helm values, default namespaces, and BuildKit-compatible remediation.

Needs improvement:

• Runtime isolation (runtimeClassName, gVisor/Kata/default runtime) is not part of the context checklist or output format.
• Admission policy evidence is mentioned generally but not collected systematically, so reviewers can miss enforcement modes, selectors, and exceptions.
• Severity guidance does not distinguish tightly scoped root init containers from long-running root application containers with broader privileges.

Priority recommendations:

1. Add RuntimeClass and runtimeClassName discovery to Step 1, plus a report field showing default/sandboxed runtime per high-risk workload.
2. Add an admission-control evidence section covering Kyverno, Gatekeeper, and Kubernetes CEL admission policy resources, including mode, selectors, and exceptions.
3. Refine severity examples so root init containers with dropped capabilities/no hostPath/no privilege escalation are treated as justified exceptions or medium-risk hardening gaps unless additional escape paths are present.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: PayPal; payment details can be provided privately after acceptance.

[JamesJi79]

Review: Issue #168 - container-security: add RuntimeClass and admission policy evidence gates

PR: #175 (branch remotes/origin/pr/175)
Commit: 756681f ("Improve container runtime admission evidence")
Author: gshaowei6
Skill: skills/cloud/container-security/SKILL.md
New file: skills/cloud/container-security/tests/runtime-admission-edge-cases.md
Bounty: $25

---

Summary of Changes

The PR adds 220 lines across 2 files (59 additions to SKILL.md, 165 in new test fixtures):

SKILL.md changes

1. New Step 6A -- "RuntimeClass and Admission Policy Evidence" with:
   • Evidence collection table (RuntimeClass selection, workload risk tier, admission engine, policy mode, selection/exceptions, container coverage)
   • 10 finding codes: CONT-RUNTIME-01 through CONT-RUNTIME-03, CONT-ADMISSION-01 through CONT-ADMISSION-05, CONT-INIT-01 and CONT-INIT-02
   • Root init container exception guidance
2. Updated Findings Classification -- High severity refined from "Running as root" to "Long-running root application containers"; Medium updated to include "lacks exception evidence" and init container justification gaps
3. Extended Output Format -- Executive summary adds RuntimeClass and admission policy enforcement coverage fields; Detailed Findings adds Container Role, RuntimeClass, and Admission Evidence fields; new "Runtime and Admission Evidence Matrix" table
4. Two new Common Pitfalls (intel: ai-security model-supply-chain community updates 2026-03-29 #8 RuntimeClass names not proof of sandboxing, intel: appsec social updates (2026-04-08) #9 Admission policy presence not enforcement)
5. Updated prerequisites to cover Kyverno, Gatekeeper, and CEL admission resources
6. Version bump 1.0.0 -> 1.0.1 with changelog

New test file

• skills/cloud/container-security/tests/runtime-admission-edge-cases.md -- 5 edge case fixtures:
  • Benign constrained root init container
  • runtimeClassName without RuntimeClass object evidence
  • Audit-only admission policy
  • Undiscovered CEL admission resources
  • Policy excluding init/ephemeral containers

---

Review Assessment

What's done well

Aspect	Assessment
Problem framing	Strong rationale for why static manifest review alone is insufficient -- RuntimeClass, admission policies/modes, selectors, exceptions, and broad exemptions all materially change risk assessment
Finding code taxonomy	Well-structured prefix scheme (CONT-RUNTIME, CONT-ADMISSION, CONT-INIT) with clear, testable conditions. Codes are memorable and easily referenced in reports
Init container nuance	Excellent treatment of root init containers -- distinguishing tightly-scoped ones (command-scoped, short-lived, pinned image, dropped caps) from genuinely dangerous ones. This is a common reviewer blind spot
CEL admission resources	Covers ValidatingAdmissionPolicy, ValidatingAdmissionPolicyBinding, MutatingAdmissionPolicy, and MutatingAdmissionPolicyBinding which are often missed in reviews
Policy mode awareness	Correctly distinguishes Enforce from Audit/dry-run/warn -- a common mistake where audit-only policies are reported as blocking controls
Test fixtures	5 well-chosen edge cases with clear expected findings and evidence-to-request guidance. Good YAML that models real-world misconfigurations
Integration with existing output	Changes flow naturally into Executive Summary, Detailed Findings, and a new matrix rather than living in a separate section
Changelog + version	Properly maintained

Issues and Recommendations

1. No severity mapping for new finding codes (Medium)

The new CONT-RUNTIME-*, CONT-ADMISSION-*, and CONT-INIT-* codes lack explicit severity assignment. The reviewer gets no guidance on whether CONT-RUNTIME-01 (runtimeClassName set but no object) is Medium, High, or Critical. The existing severity table was updated for init containers but only by example, not by mapping codes.

Recommendation: Add a severity mapping table for the new finding codes, e.g.:

| Code | Severity | Condition |
| CONT-RUNTIME-01 | High | runtimeClassName set but no matching RuntimeClass object/handler |
| CONT-RUNTIME-02 | High | High-risk workload on default runtime without sandbox justification |
| CONT-RUNTIME-03 | Medium | RuntimeClass exists but namespace/node constraints unproven |
| CONT-ADMISSION-01 | High | Policy counted as blocking but is audit/dry-run/warn-only |
| CONT-ADMISSION-02 | High | Policy selectors don't match assessed workload |
| CONT-ADMISSION-03 | Medium | Broad/stale/undocumented policy exceptions |
| CONT-ADMISSION-04 | Medium | Policy covers only app containers, misses init/sidecar/ephemeral |
| CONT-ADMISSION-05 | Medium | CEL admission resources not reviewed at all |
| CONT-INIT-01 | Medium | Root init container scored without recording evidence |
| CONT-INIT-02 | High/Critical | Root init container with hostPath, broad caps, writable root FS, or privilege escalation |

2. "Findings by Domain" table not updated (Low)

The output format's "Findings by Domain" table has static rows (Dockerfile Security, Pod Security, RBAC, Network Policies, Secrets Management, Runtime Hardening, Control Plane). The new RuntimeClass and Admission findings could logically live under "Runtime Hardening" (NIST 800-190 CM-9, CM-15), but the existing table is a template with placeholder X values, so this is a minor documentation gap.

Recommendation: Either add "RuntimeClass" and "Admission Policies" as new domain rows, or explicitly note in Step 6A that these findings are categorized under the existing "Runtime Hardening" domain.

3. Tests file path reference ambiguity (Low)

The test fixture doc references skills/cloud/container-security/SKILL.md in its preamble. This is a self-referencing relative path -- correct within the skill directory but the tests/ directory is new, so there's no existing convention to follow. No action needed, just noting the path works as-is.

4. MutatingAdmissionPolicy is alpha in most clusters (Informational)

CONT-ADMISSION-05 mentions MutatingAdmissionPolicy and MutatingAdmissionPolicyBinding. These are alpha in Kubernetes 1.32+ (feature gate MutatingAdmissionPolicy). It's correct to include them for forward-looking reviews, but the skill could note that these resources may not exist in most current clusters, so their absence is not automatically a finding.

5. Step 6A placement (Minor)

Step 6A is inserted between Step 2-6 (which reference cis-benchmarks.md) and Step 7 (Compile Report). This is a reasonable placement since it's an evidence-gathering cross-cutting concern. However, it might be more natural as a subsection within the existing "CIS Benchmark and NIST SP 800-190 Evaluation" section rather than a standalone step that breaks the numbering flow.

---

Verification

• Diff confirms 220 lines added, 4 removed -- correct scope
• No syntax errors in YAML fixtures (valid Kubernetes manifests)
• No merge conflicts expected -- the PR branch (pr/175) is based on a commit that is a direct ancestor of main
• No references to non-existent functions, tools, or files beyond what the skill already uses (Read, Grep, Glob)
• Injection hardening -- the new content treats YAML fields as data, not instructions, consistent with the existing prompt injection safety notice

---

Verdict

APPROVED with recommendations (items 1-2 above are optional improvements for clarity, not blockers)

The PR directly addresses issue #168's goals:

• Adds RuntimeClass evidence gates (CONT-RUNTIME-01 through -03)
• Adds admission policy evidence gates (CONT-ADMISSION-01 through -05)
• Adds root init container exception guidance (CONT-INIT-01 and -02)
• Provides testable edge case fixtures
• Updates output format, classification, and common pitfalls

The changes are technically correct, well-structured, and integrate cleanly with the existing skill. The new finding codes fill a genuine gap -- the skill previously assumed static manifests were sufficient for risk scoring, which misses RuntimeClass fallback and admission-policy bypass risks.