Vulnerability scanning

In a DKP cluster, vulnerability scanning is made with Trivy Operator. It automatically generates Software Bill Of Materials (SBOM) for all workloads and runs the scanner for specified objects without any manual actions required.

Supported object types for scanning

The following object types are supported:

• Container images stored in a registry.
• Node host filesystems in the cluster.

Analysis architecture

Regardless of object type, the scanning is made in three stages:

Vulnerability scanning mechanism

The vulnerability scanner is Trivy’s core component: it detects known CVEs using vulnerability databases. The operator-trivy module scans OS packages and components (binaries, libraries) and application dependencies (libraries, modules, and other deps).

The operator automatically triggers scans when new or changed workloads appear in namespaces where scanning is enabled.

Operating system packages

The scanner detects the target OS distribution and applies data from the CVE databases officially provided by Deckhouse. This improves detection accuracy and reduces false positives.

Data sources used to build the CVE databases are listed below:

• FSTEC of Russia threat database (BDU)
• AlmaLinux Errata
• Alpine SecDB
• ALTRepo Errata OVAL
• Amazon Linux Security Advisories
• Arch Linux Security Tracker
• Debian Security Tracker
• GitHub Security Advisory Database
• National Vulnerability Database (NVD)
• Oracle OVAL
• Photon Security Advisory
• Red Hat OVAL
• RED SOFT OVAL
• Rocky Linux UpdateInfo
• SUSE Security CVRF
• Ubuntu CVE Tracker
• Wolfi SecDB

Application dependencies

The scanner discovers and analyzes package manager manifests and lockfiles across more than twenty ecosystems. Per ecosystem it uses specialized vulnerability databases (primarily based on GitLab Advisory Database and GitHub Advisory Database).

Scan results and the VulnerabilityReport resource

Vulnerability scan results are stored in the cluster as the VulnerabilityReport custom resource in group aquasecurity.github.io. Each report is created in the workload namespace, named <kind>-<workload-name>-<container-name>, and lists discovered CVEs with severity, fix status, affected packages, and references.

The report is tied to the parent resource via ownerReferences: when the image changes or the workload is removed, the stale VulnerabilityReport is garbage-collected and recreated if needed. This implements periodic rescanning of workloads.

SBOM generation and processing

Generated SBOM is stored in the cluster as the SbomReport CRD in group aquasecurity.github.io. Each report is created in the workload namespace and includes:

• container image metadata (repository, tag, digest);
• component inventory in CycloneDX format: OS packages and app dependencies with PURLs, licenses, and supplier information;
• a dependency graph between components;
• summaries of component and dependency counts.

The operator watches cluster resources. When a workload is created or updated, a scan job runs and produces both SbomReport and VulnerabilityReport. Both follow the <kind>-<workload-name>-<container-name> naming scheme and use ownerReferences — when the workload is deleted, reports are removed by Kubernetes garbage collection.

SbomReport and VulnerabilityReport complement each other: VulnerabilityReport lists CVEs, while SbomReport captures the full software inventory.

Blocking vulnerable containers

The module enforces policy on running containers that use vulnerable images at Kubernetes admission time. It combines OPA Gatekeeper (the admission-policy-engine module) and Trivy: Trivy acts as a data provider for Gatekeeper with up-to-date scan results, and a Rego policy admits or denies the resource based on that data.

The constraint applies when Pod, Deployment, StatefulSet, and DaemonSet resources are created or updated in namespaces labeled security.deckhouse.io/trivy-provider: "".

Configuration

Blocking is controlled by the denyVulnerableImages module setting:

Configuration example

denyVulnerableImages:
  enabled: true
  allowedSeverityLevels:
    - UNKNOWN
    - LOW
    - MEDIUM

In this example, images with HIGH or CRITICAL vulnerabilities are blocked. Images with only UNKNOWN, LOW, or MEDIUM findings are allowed.

Compliance reports

The module deploys ClusterComplianceReport resources for selected compliance frameworks. Each report is regenerated every 6 hours and maps controls of a framework to the underlying configuration and workload checks performed by Trivy.

The set of deployed reports is controlled by the complianceReports.enabled parameter.

Configuration example

complianceReports:
  enabled:
    - CIS
    - NSA
    - FSTEC-21
    - FZ-187

In this example only four reports are deployed. To inspect a report, use:

d8 k get clustercompliancereports
d8 k describe clustercompliancereport fstec-21

What compliance reports cover

By default compliance reports focus on your workloads — what the cluster owner can actually fix. The module automatically excludes from compliance:

• resources owned by Deckhouse and its modules;
• Kubernetes system components (built-in RBAC, control plane defaults, etc.).

The control plane itself is still checked against the relevant infrastructure controls (for example, CIS Kubernetes Benchmark section 1.x for kube-apiserver, etcd, kube-scheduler settings) — only generic workload-level findings about platform pods are filtered out.

Vulnerability scanning is independent of these filters and keeps reporting CVEs and secrets for every scanned image, including platform ones.

To exclude an additional namespace from compliance — for example, an experimental or short-lived environment — label the namespace:

d8 k label namespace my-namespace security.deckhouse.io/skip-compliance=true

Database management

The module automatically downloads, maintains, and caches the required databases during scans. Data is kept current through periodic automatic updates.

In air-gapped environments you can mirror database images and use them offline with the d8 CLI utility (via the d8 mirror command).