[REVIEW] container-security: add CronJob and rendered manifest coverage gates

[GiazaiGia]

Skill Being Reviewed

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

False Positive Analysis

Benign code that triggers a false positive:

# kustomize base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api@sha256:1111111111111111111111111111111111111111111111111111111111111111
          # Security context is intentionally injected by the production overlay.
---
# kustomize overlays/prod/patch-security-context.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api
          securityContext:
            runAsUser: 65532
            runAsGroup: 65532
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]

Why this is a false positive:

The current skill tells reviewers to inspect Dockerfiles, Kubernetes manifests, Helm charts, Kustomize overlays, and values files, but it does not require reviewers to produce or inspect the rendered/merged workload that is actually applied to the cluster. If the base manifest is reviewed in isolation, the workload appears to be missing runAsNonRoot, allowPrivilegeEscalation: false, dropped capabilities, and seccomp. In production, the Kustomize overlay applies those controls. A source review should still note that the base is incomplete, but the security finding should be based on the final rendered manifest for the environment under review.

Coverage Gaps

Missed variant 1: CronJob and Job pod templates can hide the same high-risk pod settings

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-export
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: default
          containers:
            - name: exporter
              image: ghcr.io/example/exporter:latest
              securityContext:
                privileged: true
                allowPrivilegeEscalation: true
              volumeMounts:
                - name: docker-sock
                  mountPath: /var/run/docker.sock
          volumes:
            - name: docker-sock
              hostPath:
                path: /var/run/docker.sock
          restartPolicy: OnFailure

Why it should be caught:

The main SKILL.md output format and resource examples focus on Deployment/StatefulSet-style workloads. The detailed benchmark file mentions Jobs and CronJobs later, but the main discovery/reporting flow does not force traversal of nested pod specs under spec.jobTemplate.spec.template.spec. A privileged CronJob with a Docker socket hostPath can be just as severe as a privileged Deployment because the created Job pods still run with the same runtime privileges and service account.

Missed variant 2: Helm/Kustomize rendering can introduce dangerous settings that are absent from source templates

# charts/api/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          securityContext:
{{ toYaml .Values.securityContext | indent 12 }}
---
# charts/api/values-prod.yaml
image:
  repository: ghcr.io/example/api
  tag: latest
securityContext:
  privileged: true
  allowPrivilegeEscalation: true
  capabilities:
    add: ["SYS_ADMIN"]

Why it should be caught:

A raw Helm template can look neutral or safe while the environment-specific values file renders it into a privileged workload. The current skill says Helm values may override security settings, but it does not require reviewers to run or request helm template / kustomize build, identify the selected values/overlay, and attach the rendered manifest as evidence. That leaves an important false-negative path for production-only insecure settings.

Edge Cases

• Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, ReplicationController, Job, and CronJob all place pod specs at different paths; the review should normalize these to a common workload/pod-template model before applying Pod Security checks.
• A suspended CronJob (spec.suspend: true) still deserves a finding if it will be resumed with unsafe settings, but severity may differ from an actively scheduled job.
• Helm charts often have multiple values files. The review should state which values file or release configuration was assessed instead of treating chart defaults as production truth.
• Kustomize strategic merge and JSON6902 patches can both add and remove security controls. Reviewing only the base or only the patch is insufficient evidence.
• Generated manifests should preserve enough source mapping to point maintainers back to the template/values/overlay that introduced the risky field.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Existing remediation guidance is strong for direct Kubernetes manifests, non-root users, dropped capabilities, network policies, and read-only filesystems. It should add a render/merge step for Helm and Kustomize, plus a normalized workload traversal table so remediation applies to CronJobs and Jobs as consistently as Deployments.

Comparison to Other Tools

Tool	Catches this?	Notes
Semgrep	Partial	Can match YAML paths, but rules must explicitly include spec.jobTemplate.spec.template.spec and rendered chart output to avoid misses.
CodeQL	No	CodeQL is not normally used for Kubernetes workload-template traversal or Helm/Kustomize render validation.
Other: kube-linter / kube-score / Polaris / Checkov	Partial	These tools can catch many unsafe pod fields after manifests are rendered, but they still depend on feeding the correct Helm values or Kustomize overlay.

Overall Assessment

Strengths:

• Strong framework mapping to CIS Docker, CIS Kubernetes, NIST SP 800-190, and Pod Security Standards.
• Good coverage of privileged containers, host namespaces, hostPath volumes, wildcard RBAC, network policies, secrets, and runtime hardening.
• The common pitfalls already acknowledge that init containers, sidecars, Helm values, and Kustomize overlays matter.

Needs improvement:

• The main workflow should require final rendered manifests for Helm/Kustomize when chart/overlay inputs are present.
• The output format should explicitly support Job and CronJob resources and nested pod-template paths.
• The evidence model should identify both the rendered manifest field and the source template/values/patch responsible for it.

Priority recommendations:

1. Add a render step: run or request helm template and/or kustomize build for each reviewed environment, then base security findings on the rendered manifests.
2. Add a workload traversal table for Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, ReplicationController, Job, and CronJob pod-spec paths.
3. Update the report template with Rendered source, Workload kind, Pod spec path, and Source template/values/patch fields so reviewers can give actionable evidence.

Bounty Info

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

[JamesJi79]

Review: container-security — CronJob + Rendered Manifest Coverage Gates

Issue: #204
Reviewer: Hermes Agent (automated review)
Review Date: 2026-06-03
Skill Path: skills/cloud/container-security/
Files Examined: SKILL.md, cis-benchmarks.md
Issue Body: https://api.github.com/repos/UnitOneAI/SecuritySkills/issues/204

---

1. Summary

This skill performs a container/K8s security review against CIS Docker v1.6.0, CIS K8s v1.9.0, and NIST SP 800-190. It is well-structured, has solid framework mapping, and includes useful common pitfalls. However, it has two specific gaps identified by Issue #204:

1. CronJob/Job pod-template traversal — partial awareness exists in cis-benchmarks.md but is not wired into the main SKILL.md workflow, discovery patterns, or output format.
2. Rendered manifest coverage (Helm/Kustomize) — acknowledged in a common pitfall but no formal render step, no evidence provenance, and no output format fields to capture the rendered vs. source distinction.

---

2. What the Skill Gets Right (Relevant to This Issue)

Aspect	Status	Notes
Discovery file patterns	✅	Covers **/*.yaml in k8s/, manifests/, helm/, charts/, overlays/ dirs
Common Pitfall #2 (Helm values)	✅	Warns that template values may override security settings
Common Pitfall #1 (init/sidecar)	✅	Mentions all containers in a pod must be checked
cis-benchmarks.md line 651	✅	Lists "Deployment, StatefulSet, DaemonSet, Job, CronJob" in the comprehensive evaluation section
Pod Security Standards table	✅	Clear Baseline vs. Restricted mapping
Injection hardening notice	✅	Proper safety disclaimers

---

3. Gap Analysis: CronJob / Job Pod Template Coverage

3.1 What the Issue Requires

"Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, ReplicationController, Job, and CronJob all place pod specs at different paths; the review should normalize these to a common workload/pod-template model."

3.2 Current State

• SKILL.md — The output format's "Resource" field example (line 177) only shows <Deployment/StatefulSet name>. No mention of CronJob, Job, DaemonSet, ReplicaSet, or ReplicationController in the output template.
• SKILL.md — Discovery step (Step 1) patterns do not include **/*-cronjob.yaml, **/*-job.yaml, or explicit CronJob/Job kind searches. While **/*.yaml in k8s//manifests/ directories catches them, there is no explicit guidance to look for batch/v1 resources.
• cis-benchmarks.md — Line 651 mentions "Deployment, StatefulSet, DaemonSet, Job, CronJob" in one sentence, but the detailed CIS 5.2 checks (privileged, hostPID, hostPath, etc.) only use generic spec: examples without showing the nested YAML paths for CronJob (spec.jobTemplate.spec.template.spec) or Job (spec.template.spec).
• No "normalized pod spec path" table exists anywhere in the skill.

3.3 Specific Deficiencies

1. No workload kind matrix showing where spec.template.spec lives for each resource type:

   • Pod → spec.containers[]
   • Deployment / StatefulSet / DaemonSet / ReplicaSet / ReplicationController → spec.template.spec.containers[]
   • Job → spec.template.spec.containers[]
   • CronJob → spec.jobTemplate.spec.template.spec.containers[]

2. Discovery patterns do not explicitly call out batch/v1 CronJob or batch/v1 Job as kinds to search for.

3. Output format — the Detailed Findings template only references Deployment/StatefulSet in the "Resource" line. No CronJob or Job example.

4. Findings Classification — no mention of suspended CronJobs (spec.suspend: true) as a severity-modifying factor.

3.4 Suggested Fixes

A. Add a Workload Normalization Table to SKILL.md (in Step 2 or a new helper section):

### Workload Pod-Spec Normalization

| Kind          | API Group  | Pod Spec Path                                  |
|---------------|------------|------------------------------------------------|
| Pod           | v1         | `spec.containers[]`                            |
| Deployment    | apps/v1    | `spec.template.spec.containers[]`              |
| StatefulSet   | apps/v1    | `spec.template.spec.containers[]`              |
| DaemonSet     | apps/v1    | `spec.template.spec.containers[]`              |
| ReplicaSet    | apps/v1    | `spec.template.spec.containers[]`              |
| ReplicationController | v1  | `spec.template.spec.containers[]`              |
| Job           | batch/v1   | `spec.template.spec.containers[]`              |
| CronJob       | batch/v1   | `spec.jobTemplate.spec.template.spec.containers[]` |

Pod Security Standard controls apply identically to ALL workload kinds.
For CronJobs, also check `spec.suspend` — a suspended CronJob with unsafe
settings should still be flagged (lower severity), as it may be resumed.

B. Update Output Format — Change the Resource field from:

| **Resource:** | <Deployment/StatefulSet name> |

to:

| **Workload Kind:** | Deployment / StatefulSet / DaemonSet / Job / CronJob |
| **Resource:** | <resource name> |
| **Pod Spec Path:** | spec.template.spec.containers[0] / spec.jobTemplate.spec.template.spec.containers[0] |

C. Add CronJob/Job to Discovery Step 1 — Add patterns:

**/*-cronjob*.yaml
**/*-job*.yaml

---

4. Gap Analysis: Rendered Manifest Coverage (Helm/Kustomize)

4.1 What the Issue Requires

"The main workflow should require final rendered manifests for Helm/Kustomize when chart/overlay inputs are present."
"The evidence model should identify both the rendered manifest field and the source template/values/patch responsible for it."

4.2 Current State

• Common Pitfall intel: incident-response social updates 2026-03-18 #2 (SKILL.md line 254-256) does acknowledge that Helm values may override template security settings.
• However, there is no step in the skill process that requires the reviewer to:
  1. Determine whether the target uses Helm or Kustomize.
  2. Run or request helm template / kustomize build for the target environment.
  3. Base security findings on the rendered (merged) output.
  4. Trace rendered fields back to their source (template line, values file, patch file).

4.3 Specific Deficiencies

1. No render step. The 7-step process (Step 1-7) has no mention of rendering. The reviewer is implicitly expected to read raw templates/values and mentally merge them — error-prone for complex charts with multiple values files.

2. No evidence provenance. The Detailed Findings template has File: <path> and Line(s): <line numbers>, but for rendered manifests those could point to generated YAML rather than the source template/values/patch.

3. No Kustomize awareness. Kustomize strategic merge patches and JSON6902 patches can both add and remove security controls. The skill does not guide reviewers to examine both bases/ and overlays/ together.

4. No "values selected" declaration. The report has no field for recording which values file or release configuration was assessed.

4.4 Suggested Fixes

A. Add a Render Step (new Step 2, renumber subsequent steps):

### Step 2: Render — Produce Final Manifests for Review

If the target uses Helm or Kustomize, produce the rendered manifest
before performing security checks.

**Helm:**
- Run `helm template <release> <chart> --values <values-file>`
- If multiple values files exist, state which combination was reviewed.
- For a deployed release, use `helm get manifest <release>`.

**Kustomize:**
- Run `kustomize build <overlay-directory>` to produce the final output.
- If overlays have multiple patches, verify the final merged result.

If no Helm/Kustomize is detected, skip this step.

> **Rendered manifest is the source of truth for findings.** A base template
> that appears secure but renders as privileged via values must be flagged
> as a finding against the rendered manifest, with provenance tracing back
> to the responsible template/values/patch.

B. Extend the Output Format with Provenance Fields:

| **Source Template:** | charts/api/templates/deployment.yaml:42 |
| **Source Values:**   | charts/api/values-prod.yaml:8-12        |
| **Rendered File:**   | <rendered manifest path>                 |
| **Rendered Line(s):** | <line numbers in rendered output>       |

Add a note in the output format intro:

For Helm/Kustomize deployments, always include source provenance fields
to identify WHERE the insecure setting was introduced.

C. Update Common Pitfalls — Expand Pitfall #2 (line 254-256) to reference the new render step. Add a new pitfall about Kustomize patches:

8. **Kustomize patches can both add and remove security controls.**
   A `patchesStrategicMerge` overlay may add `privileged: true` or may
   remove a previously-set `runAsNonRoot: true`. Always build the final
   overlay and inspect the merged output.

---

5. Additional Edge Cases (From Issue Body)

Edge Case	Current Handling	Recommendation
Suspended CronJob (spec.suspend: true)	Not addressed	Flag with reduced severity, note it may be resumed
Multiple Helm values files	Common Pitfall #2 mentions it	Formalize: require stating which values file was assessed
Kustomize strategic merge + JSON6902 patches	Not addressed	Add pitfall + require kustomize build
Generated manifest source mapping	Not addressed	Add provenance fields to output format

---

6. Remediation Quality Assessment

Per the issue's self-assessment:

Criterion	Status	Notes
Fix resolves the vulnerability	✅	Suggested changes directly address the gaps
Fix doesn't introduce new security issues	✅	Adding render steps and provenance fields is additive, not risky
Fix doesn't break functionality	✅	Backward-compatible; all existing checks remain

Issues found with existing remediation:

• Remediation examples are strong for direct manifests and Dockerfiles (non-root, capabilities, read-only FS, network policies).
• Missing: guidance for fixing insecure settings introduced only in rendered output (e.g., "move securityContext from values into the hardcoded template or document the override in a README").

---

7. Priority Recommendations (Ordered)

1. Add workload normalization table to SKILL.md — covers CronJob/Job/Deployment/StatefulSet/DaemonSet/ReplicaSet/ReplicationController pod-spec paths. (Low effort, high impact.)
2. Add render step (Step 2) to the process — formal requirement to run helm template / kustomize build before evaluating. (Medium effort, high impact.)
3. Extend output format with Workload Kind, Pod Spec Path, and source provenance fields (Source Template, Source Values, Rendered File). (Low effort, high impact.)
4. Update discovery patterns to explicitly include *-cronjob*.yaml and *-job*.yaml. (Trivial.)
5. Add edge-case handling for suspended CronJobs and Kustomize patch reversal. (Low effort, medium impact.)

---

8. Conclusion

The container-security skill is well-written and has strong framework coverage. Issue #204 identifies two real gaps — CronJob/Job pod traversal and rendered manifest coverage — that are partially acknowledged (cis-benchmarks.md mentions Job/CronJob, Common Pitfall #2 mentions Helm values) but not wired into the main workflow, output format, or evidence model.

The fixes are straightforward and additive: a workload normalization table, a formal render step, and extended output fields for provenance. No existing functionality needs to change.

Estimated effort to address all recommendations: 2-4 hours (documentation edits only, no code changes).
Risk of not addressing: Reviewers using this skill will miss production-only insecure settings injected by Helm values or Kustomize overlays, and will fail to inspect CronJob/Job pod templates for privileged containers, hostPath mounts, and other critical controls.

[kingtechies]

Review Assessment — RECOMMEND MERGE ($25)

False Positive Analysis: VALID

The Kustomize base+overlay example is real and insidious. A reviewer inspecting only the base deployment YAML would flag missing runAsNonRoot, allowPrivilegeEscalation, dropped capabilities, and seccomp — while the production overlay patch actually applies all those controls. The current skill doesn't require reviewers to produce or inspect the rendered/merged manifest, which means findings can be based on incomplete evidence. This isn't a theoretical concern; teams using Kustomize strategic merges or Helm values-prod.yaml overrides routinely have security controls that only appear in rendered output.

Coverage Gaps: REAL

• CronJob/Job pod templates not traversed: The main discovery/reporting flow focuses on Deployment/StatefulSet but doesn't force traversal of spec.jobTemplate.spec.template.spec. A privileged CronJob with Docker socket hostPath is equally severe. The benchmark file mentions Jobs later, but the primary workflow should normalize all workload kinds.
• Helm/Kustomize rendering bypass: A template can look neutral while values-prod.yaml renders it privileged. The skill says "Helm values may override security settings" but doesn't require helm template or kustomize build as evidence. This is a clear false-negative path.

Overall: MERGE

Practical, well-grounded review. The workload traversal table (Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, ReplicationController, Job, CronJob) and rendered-manifest evidence requirements are concrete improvements. The edge case analysis (suspended CronJobs, multi-values Helm charts, source-to-rendered traceability) shows real operational awareness. Good review.

[auruminternum]

Opened follow-up improvement PR implementing this review: #329

Preferred payment method can be provided privately after acceptance.

[GiazaiGia]

Thanks for the review and for opening the follow-up implementation PR #329. This issue remains my original review bounty submission for the CronJob/rendered-manifest coverage gaps; preferred payment details can be provided privately after maintainer acceptance.