Full Report
Secure your Kubernetes supply chain with WizOS Helm Charts. Eliminate hidden CI/CD risks and unmaintained dependencies with hardened, signed, and CVE-scanned charts for seamless Kubernetes deployment.
Analysis Summary
# Best Practices: Securing the Kubernetes Supply Chain (Helm)
## Overview
These practices address the "trust gap" in Kubernetes deployments where third-party Helm charts introduce hidden risks. Traditional security tools (SCA and Image Scanning) often miss vulnerabilities in upstream CI/CD pipelines, unmaintained dependencies, and tampered images that bypass internal registries.
## Key Recommendations
### Immediate Actions
1. **Pin Image Digests:** Do not rely on mutable tags (e.g., `:latest` or `:1.2`). Update Helm `values.yaml` to use immutable SHA-256 digests to ensure the code reviewed is the code deployed.
2. **Audit Repository Origins:** Before running `helm install`, verify the source repository on Artifact Hub. Check if the project is archived or unmaintained.
3. **Scan Third-Party Images:** Use container scanners specifically on the images referenced in community charts, as these images often bypass internal CI/CD security checks.
### Short-term Improvements (1-3 months)
1. **Adopt Hardened Chart Sources:** Transition from community-maintained charts to verified, hardened catalogs (like WizOS Helm Charts) that offer CVE scanning and active maintenance.
2. **Implement Signature Verification:** Enable Helm chart signing and verify provenance before deployment to ensure charts haven't been tampered with during transit.
3. **CI/CD Pipeline Audit:** Review your own and upstream "PWN Request" risks—ensure pull requests from outside contributors do not automatically trigger workflows with access to secrets.
### Long-term Strategy (3+ months)
1. **Zero-Trust Dependency Management:** Establish a "Private-First" registry policy where all external Helm charts and images must be vetted, scanned, and mirrored to an internal OCI registry before production use.
2. **Automated SBOM Integration:** Generate and store a Software Bill of Materials (SBOM) for every Helm release to track deep-seated dependencies that are not visible in top-level manifests.
## Implementation Guidance
### For Small Organizations
* **Focus:** Use managed/hardened charts to outsource the maintenance burden.
* **Action:** Replace high-risk community charts with pre-scanned alternatives to minimize the manual security overhead.
### For Medium Organizations
* **Focus:** Visibility and Policy Enforcement.
* **Action:** Implement Admission Controllers (e.g., Kyverno or OPA) to block the deployment of Helm charts that reference un-scanned images or move away from internal registries.
### For Large Enterprises
* **Focus:** Supply Chain Integrity at Scale.
* **Action:** Build a centralized "Golden Chart" repository. Conduct deep forensic audits of upstream CI/CD workflows for critical infrastructure components (e.g., Ingress controllers, Service Meshes).
## Configuration Examples
**Vulnerable Configuration (Mutable Tag):**
yaml
image:
repository: open-source-tool/kube-view
tag: "latest" # Risk: Tag can be overwritten by an attacker or buggy update
**Secure Configuration (Immutable Digest):**
yaml
image:
repository: wiz.io/wizos/kube-view
tag: "1.2.3"
digest: sha256:b94d2747... # Guaranteed integrity
## Compliance Alignment
* **NIST SP 800-204D:** Strategies for software supply chain security in next-generation applications.
* **CIS Kubernetes Benchmark:** Recommendations for secure cluster configuration and image provenance.
* **SLSA (Supply-chain Levels for Software Artifacts):** Framework for ensuring the integrity of software artifacts.
## Common Pitfalls to Avoid
* **Blind Trust in "Stars":** Assuming a popular GitHub repository or Artifact Hub chart is secure. Popularity does not equal security hygiene.
* **Ignoring Abandoned Namespaces:** Using charts that pull from unmaintained or "dangling" namespaces (e.g., GitHub or DockerHub accounts that have been deleted and are open for re-registration by attackers).
* **Missing CI/CD Secrets:** Overlooking how an upstream project handles its build secrets, which could lead to "PWN Request" exploits.
## Resources
* **WizOS Hardened Images:** [h-t-t-p-s://www.wiz.io/blog/wizos-helm-charts]
* **Artifact Hub:** [h-t-t-p-s://artifacthub.io/]
* **Helm Security Documentation:** [h-t-t-p-s://helm.sh/docs/topics/provenance/]
* **SLSA Framework:** [h-t-t-p-s://slsa.dev/]