Kubernetes Operator Proposal: Optional Trivy Integration for Container Image Vulnerability Scanning

A critical visibility gap exists for Kubernetes cluster operators. While tools like kube9 assess cluster security, there is currently no mechanism to collect or surface CVE-oriented data from container images, leaving a blind spot in the security posture. This lack of vulnerability intelligence hampers operators' ability to prioritize patching and understand their true risk exposure.

The proposed solution is an optional integration with the Trivy vulnerability scanner. The integration would be designed for graceful operation: it would first detect if Trivy is available and reachable within the cluster, following a pattern established by other optional integrations like ArgoCD. If Trivy is absent or unreachable, the operator would simply skip the scanning function and continue its other responsibilities without entering error loops. When active, the system would collect container image references from core workload APIs—such as Pods, Deployments, and StatefulSets—and pass them to Trivy for analysis.

The resulting scan metadata and vulnerability findings would be persisted in a structured format within the operator's SQLite database, using dedicated tables (`image_scans`, `image_vulnerabilities`) as defined in the project's data model. This creates a centralized, queryable record of image security, directly linking vulnerabilities to the running workloads they affect.