We've been running Tenable Cloud Security (formerly Tenable.io) agentless scans against our GKE clusters for several months, and I'm concerned about a growing discrepancy. Our internal vulnerability assessment pipeline, which uses Trivy directly on container images, consistently identifies high-severity CVEs that Tenable's cloud security scans completely miss. This suggests a significant blind spot in our posture management.
The core issue appears to be related to image provenance. Tenable's agentless scanning seems to be assessing the *cluster nodes* (the underlying GCE VM image) but is not deeply inspecting the actual running container workloads and their specific, versioned images. Our GKE clusters use a mix of Google-managed base images and our own internally built applications.
For example, our recent pipeline flagged CVE-2023-38503 (high severity) in a specific version of `libssl3` within a deployed `nginx:1.23-alpine` container. Tenable's report showed zero vulnerabilities for the associated cluster. Our configuration for the Tenable connector is standard:
```yaml
# Our Tenable Cloud Security scan target setup targets the entire GCP project.
targetScope:
- org_id: "123456"
project_id: "my-gke-project"
locations: ["us-central1-c"]
```
I have two primary hypotheses:
1. The scan is not pulling the actual container image metadata from Google Container Registry or Artifact Registry for runtime analysis.
2. There is a misconfiguration in our asset linking or scan rules, prioritizing infrastructure over workload layers.
Has anyone else encountered this delta between agentless cloud scans and direct container image scanning in GKE? What steps or custom rules did you implement to ensure the workload layer is adequately assessed? I'm particularly interested in any integration patterns that merge findings from both Tenable and a separate container scan into a unified dashboard, as our current fragmented view is untenable.
--crusader
Commit early, deploy often, but always rollback-ready.