Release notes

v0.7.1

Release date: 2026-10-13

Fixes of the module update with an existing security-storage volume, of trivy-provider with a private registry CA, and of the node checks; faster recovery of the synchronous components after node and server outages.

Highlights

Changes in this release:

• Updating the module no longer stops on the size check of the security-storage PersistentVolumeClaim.
• trivy-provider works with a module registry that uses a private CA, and a broken registry Secret no longer blocks module updates.
• security-storage, trivy-provider and the operator recover faster from an unreachable node, a regenerated certificate and a trivy-server outage.
• Node configuration checks run on clusters whose API server reports its version without a patch number.

New features

This release adds:

• New alert TrivyProviderRegistrySecretUnusable (S5) fires when a Secret listed in denyVulnerableImages.registrySecrets has been missing or not a valid kubernetes.io/dockerconfigjson Secret for 5 minutes. To resolve it, create or fix the Secret, or remove it from denyVulnerableImages.registrySecrets.

Improvements

This release improves:

• The security-storage pod is deleted 30 seconds after its node becomes unreachable instead of 5 minutes. While security-storage is unavailable, the reports API does not work and namespace deletion waits in the whole cluster. With a PersistentVolumeClaim, the replacement pod starts only after the volume is detached from the node: Kubernetes forces the detach after about 6 minutes, or at once when the node gets the node.kubernetes.io/out-of-service taint.
• Vertical Pod Autoscaler no longer evicts security-storage, trivy-server and trivy-provider to change their resources. New resources apply when the pod is recreated, for example during a module update.
• After the trivy-provider certificate is regenerated, pod creation in namespaces with vulnerable image blocking is no longer denied until trivy-provider is restarted by hand.

Fixes

This release fixes:

• Fixed the module update that stopped with a validation error of the security-storage PersistentVolumeClaim in two cases: the claim requested more than securityStoragePVCRequest, for example after a manual expansion, or the claim was smaller and its StorageClass did not allow volume expansion, for example the 5Gi claim of release 0.5 on local-path. In both cases the module now keeps the size of the existing claim.
• Node configuration checks did not run when the Kubernetes API server reported its version without a patch number, for example v1.31. The operator failed to create the node-collector job, so ClusterInfraAssessmentReport reports of nodes and the node checks of compliance reports had no results. Such a version is accepted now.
• When the module registry used a private certificate authority (CA), for example the built-in registry in the Direct mode, trivy-provider failed to download the Java vulnerability database with x509: certificate signed by unknown authority and restarted in a loop, so the denyVulnerableImages webhook did not work. trivy-provider trusts the registry CA now, and insecureDbRegistry is no longer needed for this case.
• During an outage of trivy-server the operator kept creating scan jobs for up to 10 hours, and the jobs failed and used up the scan attempts of workloads. The operator now notices the outage within a minute and waits for the server.
• A Secret in denyVulnerableImages.registrySecrets that did not exist made every run of the module fail, so the module stopped receiving updates. Such a Secret, as well as a Secret that is not a valid kubernetes.io/dockerconfigjson Secret, is skipped now, and the TrivyProviderRegistrySecretUnusable alert fires. Images from the registry of a skipped Secret are denied until the Secret is created or fixed; the module picks up the Secret within 5 minutes.

Upgrade notes

Before upgrading, note the following:

• The update restarts security-storage, operator and trivy-provider. While security-storage restarts, the reports API is unavailable in the whole cluster and namespace deletions wait for it.

v0.7.0

Release date: 2026-10-08

Trivy 0.74 and trivy-operator 0.34; the runtime map no longer restarts learning on its own; fixes to node vulnerability metrics and to compliance reports.

Highlights

Changes in this release:

• Trivy is updated to v0.74.0, trivy-operator to v0.34.0, and the runtime map components to node-agent v0.3.179 and security-storage v0.0.290.
• With nodeAgent.enabled, the runtime map no longer restarts learning of every container on a node every two minutes: a workload is learned again only after its ApplicationProfile or NetworkNeighborhood is deleted.
• Node vulnerability metrics carry the node name and the node operating system, and compliance reports are built once and without waiting for the next scheduled run.

Fixes

This release fixes:

• The trivy_node_vulnerabilities metric had empty node_name, node_os_family and node_os_name labels when reports were stored in security-storage. The labels are filled now.
• With nodeAgent.enabled, the runtime map restarted learning of every container on a node every two minutes, so profiles of running workloads kept being relearned. A workload is learned again now only after its ApplicationProfile or NetworkNeighborhood is deleted, without restarting it. The new profile is marked partial, because the start of the workload is not observed.
• A compliance report recreated while the module is running, for example after a restart of the report storage, is built at once instead of at the next scheduled run.
• After a restart of the operator, a compliance report that had no result for longer than one scheduled period was built twice in a row, and its security event about failed controls was sent twice. The report is built once now.
• Vulnerability metrics could keep the result of the previous scan of a workload until its report changed again. They follow the latest report now.

Security updates

Security updates in this release:

• Fixed CVEs in module images and dependencies, and updated the base images.

Dependencies

Dependency updates:

• trivy: v0.69.3 → v0.74.0 (changelog)

• trivy-operator: v0.30.1 → v0.34.0 (changelog)

  • The operator is granted read access to PersistentVolume and PersistentVolumeClaim objects, which its configuration audit now watches.

• kubescape-node-agent: v0.3.119 → v0.3.179 (changelog)

• security-storage: v0.0.258 → v0.0.290 (changelog)

v0.6.9

Release date: 2026-10-07

Security events for security-events-manager; a choice of where scan reports are stored; configurable resources, bounded retries and an alert for node scans; the restricted pod security policy for the module namespace; fixes to the admission check of vulnerable images and to scanning images from private registries.

Highlights

Changes in this release:

• With the security-events-manager module enabled, the module sends it security events about vulnerabilities, secrets, misconfigurations and RBAC issues found by scans, about images rejected at admission, and about registry scan failures.
• Scan reports can be stored in etcd instead of security-storage: set the new securityStorageForReports parameter to false.
• Node scans that run out of memory or time can be given more resources, no longer restart in a loop, and raise an alert when a node is left without a report.
• Module Pods run under the restricted pod security policy when admission-policy-engine supports policy exceptions.
• denyVulnerableImages honours allowedSeverityLevels, and images from registries with a private CA, from insecure registries and behind the cluster proxy are scanned with useVEXFromOCI enabled.

New features

This release adds:

• The nodeScanning.resources parameter sets the CPU and memory requests and limits of the node scan jobs (scan-noderootfs pods). They were fixed at 100m/256Mi requests and 1/2Gi limits, and scanJobResources does not apply to these jobs. Each omitted field keeps its previous value, so a cluster that sets nothing scans its nodes as before, and a default request above the limit you set is lowered to that limit. A ModuleConfig with an explicit request above the limit is rejected when saved.
• Added the NodeVulnerabilityScanFailed alert (S6). It names a node that is left without a vulnerability report because its filesystem scan failed and gives the reason for the last failure, such as OOMKilled, DeadlineExceeded or OutOfmemory. It fires when three scans of the node in a row fail and stays for five minutes. To resolve it, raise nodeScanning.resources or nodeScanning.timeout, exclude the node with nodeScanning.nodeSelector, or set a new value of the rescan annotation trivy-operator.aquasecurity.github.io/node-rootfs-scan on the node. The failures are also exported as the d8_operator_trivy_node_scan_failed metric.
• Security events for the security-events-manager module. The module ships nine SecurityEventDefinition resources and the operator-trivy PodSecurityEventShipper resource in the d8-operator-trivy namespace, which are created only when security-events-manager is enabled. Events are produced when a scan saves a report: vulnerabilities in workload images, on nodes and in registry images; secrets found in workload images; misconfigurations found by configuration audit and infrastructure checks; RBAC issues; failed compliance controls; images rejected by the denyVulnerableImages policy; and registry-scanner failures to access a registry or scan an image. An event names the scanned object — the workload, the node or the image — and carries the number of findings of each severity and the name of the report. The list of events is given on the vulnerability scanning page.
• A security event about a report takes the severity of its most severe finding: CRITICAL becomes Critical, HIGH becomes High, MEDIUM becomes Medium, LOW and UNKNOWN become Low. The securityEvents.minimumSeverity parameter sets the lowest severity that produces an event and defaults to HIGH, so a report with MEDIUM and LOW findings only produces no event until the parameter is lowered. Rejected images, registry scan failures and failed compliance controls always produce an event.
• The securityStorageForReports parameter selects where scan reports are stored. The default true changes nothing: reports stay in security-storage. With false, reports are stored in etcd, and security-storage runs only when nodeAgent.enabled is set. Existing reports are not moved when the value changes: the module scans the cluster again, and the reports are incomplete until the scan finishes. Switching to false deletes the security-storage disk with the reports on it unless nodeAgent.enabled is set.
• The module records vulnerability trend series in Prometheus: trivy:workload_vulnerabilities:count with the number of unique vulnerabilities of a controller by severity, and trivy:workload_vulnerability_id:present with the vulnerability identifiers of a controller. Deckhouse Console builds the vulnerability trend charts from them. A Deployment keeps one history across revisions, and a rescan no longer shows up as fixed and then new vulnerabilities. The series and query examples are described in the “Vulnerability trend metrics” section of the scanning documentation.

Improvements

This release improves:

• The operator log line scan finished with findings names the scanned object under the resourceKind, resourceNamespace and resourceName keys, for images also under the container, image and imageDigest keys, and ends with severity, the highest severity among the findings. The kind, namespace and name keys of the line were duplicated by the scan job logger, so a JSON parser returned either the report or the workload depending on the implementation. The line is also written for ExposedSecretReport and NodeVulnerabilityReport.
• registry-scanner writes the scan finished with findings log line with the number of vulnerabilities of each severity for every saved RegistryImageVulnerabilityReport that has vulnerabilities. When a RegistryScanTarget enters a failed state or its failure changes, it writes one registry scan failed line with the reason and the message of the Ready condition, rather than one per retry. A target whose registry credentials cannot be read or whose tagFilter is invalid is also reported in the log now; such a failure was reported only in the condition of the target.
• trivy-provider writes its log in JSON instead of the console format, and writes the image rejected: vulnerabilities found line with the number of vulnerabilities of each severity for every image it reports as vulnerable. Log lines are no longer sampled, so none of them is dropped under load.
• The operator writes every log line: controller-runtime sampled its production log and kept one line in a hundred after the first hundred lines with one message in a second, so most findings lines of a configuration audit of a whole cluster were dropped. The format of the lines is unchanged.
• Disabling the module or node scanning while a node scan is running no longer prevents the scan job from completing or the d8-operator-trivy namespace from being deleted. If the module is enabled again before the namespace is deleted, it is installed once the deletion completes, and the module status shows what is holding the deletion.

Fixes

This release fixes:

• A node filesystem scan that ends without a report is no longer repeated in a loop. A failed scan job, one out of memory for example, was replaced within seconds without limit and reported only in the operator log. The scan is now repeated five minutes later and stops after three failures until the operator restarts or the rescan annotation trivy-operator.aquasecurity.github.io/node-rootfs-scan of the node gets a new value. A temporarily unavailable API server does not count as a failure, and a scan job denied by an admission webhook is retried every five minutes until the webhook admits it.
• denyVulnerableImages.allowedSeverityLevels now takes effect: an image whose vulnerabilities are all of the listed severities is admitted. The list was applied to a copy of the scan results, so any image with at least one vulnerability was denied whatever the parameter held.
• kubectl get vulnerabilityreports and the other report commands without an API group now show the current reports on clusters upgraded from version 0.5. They showed the outdated reports left from that version.
• The module no longer enters the Error state for several minutes when it is enabled for the first time.
• Scan reports are no longer unavailable for a short time to the module and to Deckhouse Console after every update or configuration change of the module.
• Compliance reports no longer show every control as passed right after the module is enabled or after security-storage restarts without a persistent disk. Such a report stayed until its next scheduled run, up to six hours later. It is now built as soon as the first scan results exist and once more ten minutes later, when the cluster scan has finished.
• With useVEXFromOCI enabled, a workload whose image is stored in a registry with a certificate of a private CA now gets its VulnerabilityReport. The VEX attestation lookup ignored the certificates from additionalRegistryCA and the registry CA of the platform, so the scan of such a workload failed with x509: certificate signed by unknown authority and created no report.
• With useVEXFromOCI enabled, images from the registries in insecureRegistries and images of a RegistryScanTarget with insecure: true are now scanned without VEX attestations. The attestations are fetched only over HTTPS with certificate verification, so a workload from an HTTP registry or a registry with an untrusted certificate got no VulnerabilityReport, and registry scanning and the denyVulnerableImages check failed on such images.
• Registry scanning and the denyVulnerableImages check now go through the cluster proxy (proxy in the cluster configuration) and can scan images from registries reachable only through it. A registry not covered by noProxy is now reached through the proxy in these checks as well.
• An entry of insecureRegistries with a scheme or a path, such as http://registry.example.com:5000, now applies to workload scanning as well. Before, only the denyVulnerableImages check honoured such an entry.
• In a cluster without internet access, the denyVulnerableImages check of an image with Java packages no longer fails three days after the module starts. The Java vulnerability database is now refreshed from the module registry with the insecureDbRegistry setting instead of being downloaded from public registries during the check.
• Images based on RED OS are scanned for vulnerabilities in their OS packages. The OS of such an image was not detected, so its VulnerabilityReport covered only application dependencies.
• The CIS Benchmark compliance report no longer applies control plane checks to worker nodes. Every node ran the checks meant for master nodes, so the report held results for worker nodes that do not apply to them.

Security updates

Security updates in this release:

• Pods of the d8-operator-trivy namespace run under the restricted pod security policy when the SecurityPolicyException API of admission-policy-engine is available in the cluster. The namespace gets the security.deckhouse.io/pod-policy: restricted and security.deckhouse.io/enable-security-policy-check: "true" labels. The node-collector, node scan (scan-noderootfs) and node-agent Pods, which need access to the host, are allowed only what they use through the SecurityPolicyException resources the module ships. A cluster without that API keeps the previous namespace labels.
• While the d8-operator-trivy namespace is being deleted, the Pods still running in it are not checked against the pod security policy.

Upgrade notes

Before upgrading, note the following:

• If denyVulnerableImages.allowedSeverityLevels is set, check its value before updating: images whose vulnerabilities are all of the listed severities will be admitted after the update. They were denied before regardless of the parameter.

Docs

Documentation changes:

• The FAQ describes where scan reports are stored and how to switch between the two storage modes.
• The “Vulnerability data sources” section of the scanning documentation describes where vulnerability data comes from and how the databases are updated, including air-gapped environments.
• The module overview lists the system requirements and the Deckhouse editions the module is available in.

v0.6.8

Release date: 2026-09-28

Security score of the cluster and of every user namespace; Grafana vulnerability and CIS dashboards removed in favour of Deckhouse Console; alerts when the Trivy vulnerability database is missing or outdated; reliable configuration audit, compliance and cluster SBOM reports; module images and dependencies updated to address CVEs.

Highlights

Changes in this release:

• The module publishes a security score: a ClusterSecurityScore resource for the cluster and a SecurityScore resource in every user namespace, so a namespace score is granted together with access to the namespace itself.
• Grafana dashboards Security / Trivy Image Vulnerability Overview and Security / CIS Kubernetes Benchmark are removed; use Deckhouse Console for vulnerability overview and CIS Benchmark results.
• ClusterAlerts warn when trivy-db is missing or older than vulnerabilityDatabaseMaxAge (default 168h); set vulnerabilityDatabaseMaxAge to "" to disable both alerts.
• Configuration audit, compliance and cluster SBOM (k8s-cluster) reports are complete again when reports are served by security-storage, and a failed scan job is repeated instead of leaving its workload without a report.
• Dependencies and base images are updated to close CVEs.

New features

This release adds:

• Security score of the cluster and of every user namespace. The cluster score lives in a ClusterSecurityScore resource named cluster, and a namespace score in a SecurityScore resource named security-score in that namespace. A namespace score is granted by the d8:use:capability:module:operator-trivy:view role together with access to the namespace, and the cluster score by the d8:manage:permission:module:operator-trivy:view role. A namespace is scored by the same formula as the cluster, without the cluster-scoped components: a namespace with no reports at all is limited to 60, and a namespace without scanning enabled always loses the whole coverage weight. A component with no reports behind it carries the notMeasured field and is excluded from the calculation instead of counting as a clean result.
• The cluster score is exported to Prometheus as deckhouse_trivy_security_score, deckhouse_trivy_security_score_component, deckhouse_trivy_security_namespace_score_average, deckhouse_trivy_security_namespaces_total and deckhouse_trivy_security_namespaces_scanned. Per-namespace scores are not exported: on a large cluster that would add a time series for every namespace.
• The RegistryScanTarget resource gained the spec.maxRepositories parameter: the number of repositories one cycle takes from the registry catalog when spec.repositories is empty, 100 by default. The catalog is read only as far as that limit, and the reports of the repositories left out are kept.
• Added TrivyVulnerabilityDatabaseOutdated (S6) when trivy-db exceeds the configured freshness window, and TrivyVulnerabilityDatabaseMissing (S6, for: 30m) when ConfigMap trivy-db-info has no usable trivy-db.updatedAt stamp.

Improvements

This release improves:

• Reports of registry-scanner name the version of the scanner that produced them. The scanner.version field of every RegistryImageVulnerabilityReport was empty, so a report could not be traced back to a Trivy release.
• Vulnerability overview and CIS Benchmark results are expected from Deckhouse Console instead of the removed Grafana dashboards.
• report-updater applies rotated registry credentials without a restart: the Docker configuration is read again on every renewal of the BDU dictionary.
• report-updater names in the log the repository whose credentials it looked for and the registries the Docker configuration lists, when it finds no credentials and falls back to anonymous access. A configuration in which the auth field of any entry cannot be decoded is treated as invalid as a whole, and the error message names that entry.

Fixes

This release fixes:

• A compliance report whose first generation fails at operator startup is logged and generated again a minute later instead of interrupting the reconcile. It waited for the next cron run, up to six hours by default, and a module update often left most reports empty for that time, because security-storage restarts together with the operator.
• security-storage now chooses between a PersistentVolumeClaim and emptyDir by apiServerStorageClass. Setting only apiServerStorageClass to false left its pod waiting on a claim that was never created, and setting only storageClass to false provisioned a disk that nothing used.
• Image scanning no longer stops when scanJob.podTemplateContainerSecurityContext is absent from the operator ConfigMap. The platform security context was applied to an empty value, so the scan jobs were never created.
• Removing the security-scanning.deckhouse.io/enabled label from the last labeled namespace now updates the list of namespaces opted in for image scanning. The list was never reset, so the operator kept such a namespace in its scanning scope until the next Deckhouse restart. The list is also ordered now, so the operator is no longer restarted by a reordering of the same namespaces.
• Image scanning no longer resumes in a namespace that has left the scanning scope. Even with the scope updated, the namespace list was enforced only on the watches of the workload controller, so deleting a report — by hand, or on lifetime expiry — rescanned its workload in any namespace. VulnerabilityReport left in such a namespace expires within one scanPeriods.workloadRescanPeriod and is no longer created again. ExposedSecretReport and SbomReport have no lifetime of their own and stay until their workload is deleted.
• trivy version in the module image reported dev instead of a version number, so the shipped Trivy release could not be determined from the scanner itself. The binary is now built with its release version.
• report-updater downloads the BDU dictionary when the registry secret stores the credentials as a username/password pair, under a key that carries a scheme or a repository path, or as a token. Such credentials were not recognized: the component accessed the registry anonymously, received 401 Unauthorized and restarted in a loop, and the module did not become ready. A password containing a colon was truncated for the same reason.
• report-updater takes the credentials of the registry that hosts the BDU image from the system-registry secret. It read deckhouse-registry, which holds the credentials of the module source registry, so the dictionary was not downloaded when the module and the platform are delivered from different registries or under different accounts.
• registry-scanner finds the credentials of a RegistryScanTarget when the key in the secret referenced by registrySecretRef carries a scheme or a repository path, and when the Docker Hub credentials are stored under the legacy key. The key had to match the registry field exactly, otherwise the target was scanned without credentials. An entry that holds a token alone is no longer rewritten either: the configuration passed to the scan received an auth field composed of an empty user name and password, which the scanner rejects as malformed.
• registry-scanner stores the report of an image in which no vulnerabilities are found. The list of vulnerabilities is a required field of RegistryImageVulnerabilityReport and an empty list was passed as null, so the report was rejected and the tag was rescanned on every cycle without a report being stored.
• registry-scanner scans every repository of a registry when spec.repositories of the RegistryScanTarget is empty. The reference has always described an empty list this way, but no repository was ever looked up: such a target finished its cycle in a fraction of a second and reported success without scanning anything. The repositories now come from the catalog API of the registry, and a registry that does not serve the catalog, or serves an empty one, puts the target into Ready=False instead of reporting a successful cycle.
• registry-scanner reports the repositories it could not read. A repository that does not exist, a certificate the scanner refuses and a credential the registry rejects were only written to the log, while the target reported Ready=True with no reports behind it. Such a cycle now sets Ready=False, names the repositories with the error of each and counts the images it could not scan.
• registry-scanner lists the tags of a registry with the credentials the module itself runs with, when the RegistryScanTarget names no secret of its own. The scan already used them, so a registry available to the module was scanned but listed anonymously, and its private repositories answered 401 Unauthorized while its public ones were scanned.
• registry-scanner no longer reconciles a broken target in a loop. A target whose cycle failed reconciled about ten times a second for as long as it stayed broken, with two writes to the API server on every pass, because the controller answered its own status writes. A cycle that fails before it scans anything now retries in five minutes, and one that scanned part of its images in an hour.
• registry-scanner starts a scan cycle as soon as the spec of a RegistryScanTarget changes. An added repository or a corrected repository path waited for the rescan period to elapse, up to a week, unless the last scan time annotation was removed by hand.
• registry-scanner answers the probes while the Java index database is being downloaded. The download ran before the probe server started, so on a slow registry the kubelet killed the container on the liveness probe and the download began again from scratch, leaving the component in CrashLoopBackOff. A failed download is now retried every 30 seconds, and until it succeeds the component reports itself as not ready and postpones the scans.
• The cluster SBOM (k8s-cluster) gets its ClusterVulnerabilityReport again. The operator handed the scan job an empty SBOM read from the metadata-only projection of security-storage, and a scan submitted while trivy-server was still loading its database after a module update failed and was not repeated. The operator now reads the full SBOM, and the scan waits up to 90 seconds for trivy-server.
• The k8s-cluster report describes the current Kubernetes version. The SBOM of a previous cluster version stayed after an upgrade and shared the sbom-k8s-cluster secret with the current one, so the report could be built for either of them. The SBOM of another version is now deleted together with its report.
• A secret that hands an SBOM to a scan job no longer blocks the scan. A secret left without an owner, for example after an operator restart, was taken for a scan in progress, and the object was never scanned again. The secret name now carries the hash of the scanned object, a leftover secret is replaced, and the module deletes sbom-* secrets that stay without an owner for more than 10 minutes.
• A scan job that fails, for example because its pod is evicted, is repeated up to three times for the same pod spec. The workload stayed without a report until its spec changed.
• Compliance reports (ClusterComplianceReport) count failed controls again. The operator built them from the metadata-only projection of the assessment reports without their checks, so every control was reported as passed.
• The KSV-0110 check (default_namespace_should_not_be_used) is loaded again. The operator skipped the Rego library it depends on and logged rego_type_error at startup.
• The metrics trivy_image_vulnerabilities and trivy_image_exposedsecrets carry the image labels again, and trivy_vulnerability_id has series again. The operator read these reports from the metadata-only projection of security-storage, which holds no image or vulnerability data.
• registry-scanner stores the report of an image whose report exceeds the 1 MiB object limit. The report is trimmed in stages: links, descriptions, CVSS vectors and then the vulnerabilities of the lowest severities; the summary counters stay complete, and the registry-scanner.deckhouse.io/trimmed annotation lists what was dropped.
• vulnerabilityDatabaseMaxAge: 0s is rejected by the configuration schema. The value was accepted and made the trivy-db freshness alert hook fail on every run.
• Configuration audit checks no longer fail to compile at random after an operator start. Concurrent reconciles corrupted the cached check bundle, and the scanner kept the failed compilation, so every ConfigAuditReport came out without checks and every ClusterComplianceReport without failed controls until the operator was restarted. The bundle is no longer shared for writing, and a failed compilation is retried.

Security updates

Security updates in this release:

• Fixed CVEs in module images and dependencies.

Upgrade notes

Before upgrading, note the following:

• A RegistryScanTarget with an empty spec.repositories starts scanning. Such a target scanned nothing before this release, and it now takes up to spec.maxRepositories repositories from the registry catalog, 100 by default, which adds their images to the load of the Trivy server. Set spec.maxRepositories on those targets before the upgrade if that load matters, or list the repositories explicitly.
• Every RegistryImageVulnerabilityReport is recreated under a new name during the first cycle after the upgrade. The name of a report now carries a hash of the repository and the tag it describes, so that two images whose paths differ only in a character the old name dropped no longer share one report. The reports of the previous names are removed by the first cycle that reads every repository of their target and scans every image of it. Reports of images the cycle does not scan — a repository that left the target, one that is unreadable, or one beyond spec.maxRepositories — are removed by the first cycle that reads every repository of their target and scans every image of it, and until then the Ready condition of that target says so.
• A RegistryScanTarget whose repositories cannot all be read turns Ready=False with the ScanFailed reason. Such a target reported Ready=True before, so a check that expects every target to be ready may start failing on a target that was already scanning only part of its repositories.

Docs

Documentation changes:

• Fixed the tagFilter example in the RegistryScanTarget reference. It was written as a double-quoted YAML string, where the regex backslash escapes are invalid, so copying the example into a manifest produced a parse error.
• The severities parameter now states its default in the ModuleConfig reference: with the parameter unset, vulnerability reports include all severity levels.
• The description of the scanning scope now distinguishes image scanning, which is limited to labeled namespaces, from configuration scanning, which covers every namespace. It also states which namespaces complianceReports.skipSystemResources excludes by default, how long the reports of a namespace live after its label is removed, and why the operator log reports the AllNamespaces install mode in both cases.

v0.6.7

Release date: 2026-08-26

Reduced security-storage memory usage during normal operation through internal storage optimizations.

Highlights

Changes in this release:

• security-storage uses less memory under load thanks to storage and caching optimizations.

Improvements

This release improves:

• Lowered the operational memory footprint of security-storage.

v0.6.6

Release date: 2026-08-14

security-storage watch requests now support sendInitialEvents=true for correct initial sync.

Highlights

Changes in this release:

• Watch requests to security-storage accept sendInitialEvents=true, so clients receive the initial object set before further events.

Fixes

This release fixes:

• Implemented missing sendInitialEvents=true support for security-storage watch requests.

v0.6.5

Release date: 2026-08-10

Negotiated YAML/JSON-only encoding for trivy.deckhouse.io resources and allowed a separate StorageClass for the security-storage PVC.

Highlights

Changes in this release:

• API negotiation for trivy.deckhouse.io resources is limited to YAML and JSON.
• The security-storage PVC StorageClass can be configured separately from the rest of the module.

v0.6.4

Release date: 2026-08-04

Updated mount points for node filesystem scanning pods for compatibility with the CSE edition of Deckhouse Kubernetes Platform (DKP).

Highlights

Changes in this release:

• Mount points for node filesystem scanning pods are updated for CSE compatibility.

v0.6.3

Release date: 2026-08-04

Enabled node root filesystem scanning in the CSE edition and adjusted the node-agent securityContext and mount points for CSE compatibility.

Highlights

Changes in this release:

• Node root filesystem scanning works in CSE clusters.
• The node-agent securityContext and mount points are aligned with CSE requirements so the agent starts and runs correctly.

v0.6.2

Release date: 2026-08-03

Added mount point declarations for scanning containers for compatibility with the CSE edition of Deckhouse Kubernetes Platform (DKP).

Highlights

Changes in this release:

• Declared mount points for scanning containers so node and workload scanning works correctly in CSE clusters.

v0.6.1

Release date: 2026-08-03

Added mount point declarations for the security-storage component and scanning containers for compatibility with the CSE edition of Deckhouse Kubernetes Platform (DKP).

Highlights

Changes in this release:

• Declared mount points for security-storage and scanning containers so the module works correctly in CSE clusters.