Security scanning with Trivy and Kubescape — vulnerabilities and misconfigurations

Security scanning is the fourth family in the Kubernetes CI pipeline. kubeconform checks the schema; Conftest and Kyverno check organisational policy; Trivy and Kubescape check the categories of misconfiguration and vulnerability the other three do not. Trivy scans image references for known CVEs and scans the repository for misconfigurations and vulnerable dependencies; Kubescape scans against published frameworks (CIS Kubernetes Benchmark, NSA hardening guide, MITRE ATT&CK). The two compose because they cover different rule sets and because the rule authors are different.

What Trivy catches

Trivy is the canonical all-in-one scanner for Kubernetes CI. The tool has three modes relevant to a Kubernetes manifest repository:

trivy config manifests.yaml
trivy fs --security-checks vuln,config .
trivy image ${REGISTRY}/${REPO}:${TAG}

trivy config reads a manifest file (or a directory) and reports misconfigurations against Trivy’s built-in rule set. The rule set covers Kubernetes, Dockerfile, Terraform, Helm, and other IaC formats. The Kubernetes rules overlap with kubeconform (schema) and Conftest (policy) on common findings and diverge on the rest:

• Security context. Pods running as root, pods mounting host paths, pods with privileged containers.
• Resource governance. No CPU/memory limits, no requests, no PodDisruptionBudget.
• Network policy. Namespaces without a default-deny NetworkPolicy.
• Image provenance. Image references without digest, references to unapproved registries.
• Workload identity. ServiceAccounts without automounting disabled where not needed.

trivy fs --security-checks vuln,config . walks the repository for both misconfigurations (the config check) and known-vulnerable dependencies (the vuln check). The --security-checks vuln,config flag enables both; the default is vuln only.

trivy image ${IMAGE_REF} scans a container image for known CVEs in the OS packages and language dependencies. The check requires pulling the image or having access to a registry that supports scanning. The output is a list of CVEs with severity, package, and fixed version.

What Kubescape catches

Kubescape is the canonical framework-driven scanner. The tool reads rendered manifests and applies rule sets aligned with published security frameworks:

kubescape scan manifests.yaml

The default rule set is the CIS Kubernetes Benchmark, the NSA Kubernetes Hardening Guide, and the MITRE ATT&CK matrix for containers. The frameworks encode the security posture a compliance team recognises; the Kubescape output maps each finding to the framework control it violates.

The categories of finding Kubescape produces that Trivy does not:

• CIS control violations. Control 1.1.1 (ensure the API server pod specification file has permissions 644 or stricter), control 1.2.1 (ensure the --anonymous-auth flag is set to false), and hundreds of similar controls.
• NSA hardening violations. The NSA guide’s specific recommendations on Pod Security Standards, network policies, and workload identity.
• MITRE ATT&CK techniques. Mapping of misconfigurations to the attack techniques they enable.

The framework-driven output is what makes Kubescape useful for compliance reporting. A finding with the CIS control ID is attachable to a compliance ticket; a Trivy finding with a CVE ID is attachable to a vulnerability ticket. The two tools serve different consumers.

Vulnerability scanning versus misconfiguration scanning

The two families of finding are categorically different:

A vulnerability finding tells the team to update an image. A misconfiguration finding tells the team to change a manifest. The remediation paths differ; the reviewers differ; the urgency differs.

flowchart LR
    A["Manifests"] --> B["kubeconform\n(schema)"]
    A --> C["conftest\n(policy)"]
    A --> D["trivy config\n(misconfig)"]
    A --> E["kubescape\n(framework)"]
    A --> F["trivy fs\n(vuln + config)"]
    B --> G["CI pipeline"]
    C --> G
    D --> G
    E --> G
    F --> G

Compose with kubeconform and policy

The four tools compose into the canonical Kubernetes CI pipeline:

1. kubeconform validates the schema (Part LII-02).
2. Conftest / Kyverno validates organisational policy (Part LII-04).
3. Trivy config / Kubescape scans for misconfigurations against upstream rule sets.
4. Trivy fs / Trivy image scans for vulnerabilities in dependencies and image references.

The four checks are not redundant. A manifest can pass kubeconform (schema-correct) and Conftest (policy-correct) and still fail Trivy config (missing PodDisruptionBudget) and Kubescape (violates CIS control 5.7.1). Each tool covers a different rule set; each tool catches what the others miss.

Production discipline

1. Run trivy config and kubescape scan in the same pipeline. The two scanners overlap on common findings and diverge on the rest; both are required for full coverage.
2. Pin scanner versions. A scanner that updates its rule set on every CI run is a scanner that produces different results on the same source. Pin the version in the CI image.
3. Separate vulnerability and misconfiguration exit codes. A vuln finding and a config finding have different remediation paths; failing the pipeline on either is fine, but reporting them separately makes the failure reviewable.
4. Document suppressions. Every .trivyignore entry and every --skip-framework flag has a recorded rationale; quarterly review of the suppression list is the production discipline.

Cross-course references

• Kubernetes for Production Sysadmins - Part XXXIII (Admission) covers OPA Gatekeeper and Kyverno, which check some of the same rules at admission time that Trivy and Kubescape check at CI time.
• Containers for Production Sysadmins - Parts XII-XV cover image scanning with Trivy and the runtime signals the CI scans cannot replace.
• This course, Part LII-04 (Policy) - the policy layer Conftest and Kyverno provide; this lesson covers the scanner layer that sits alongside it.

Quiz