The module lifecycle stage: Generally available version
The module has requirements for installation
The operator-trivy module of Deckhouse Platform (DP) stores scan results and scan settings in custom resources of two API groups:
trivy.deckhouse.io/v1alpha1: scan reports. Their structure follows the reports of the Trivy Operator project by Aqua Security. By default these resources are not CRDs: the module serves them through an aggregated API backed by thesecurity-storagecomponent. If thesecurityStorageForReportsparameter isfalse, the reports are stored inetcdas custom resources of theaquasecurity.github.iogroup with the same structure.deckhouse.io/v1alpha1: RegistryScanTarget, RegistryImageVulnerabilityReport, SecurityScore and ClusterSecurityScore. These resources are CRDs installed by the module.
Reading reports
Take the following into account when you request reports of the trivy.deckhouse.io group:
- Always specify the resource together with its group, for example
vulnerabilityreports.trivy.deckhouse.io. The CRDs of theaquasecurity.github.iogroup are installed in both storage modes and can hold outdated objects of the same kinds. - A list request returns objects with only
metadataandreport.summaryfilled in. Findings, such asreport.vulnerabilitiesandreport.checks, are empty. To get full objects, add the label selector!metadata-only.deckhouse.ioto the request. ClusterComplianceReport objects are always returned in full. - A request for a single object by name returns the full object.
To get reports with metadata and report.summary only, run:
d8 k get vulnerabilityreports.trivy.deckhouse.io -n <NAMESPACE> -o yamlTo get full reports with all vulnerabilities, run:
d8 k get vulnerabilityreports.trivy.deckhouse.io -n <NAMESPACE> -l '!metadata-only.deckhouse.io' -o yamlTo get a single full report, run:
d8 k get vulnerabilityreports.trivy.deckhouse.io -n <NAMESPACE> <REPORT_NAME> -o yamlObject-level security
VulnerabilityReport
VulnerabilityReport is a resource that contains a report on vulnerabilities found in a container image used in a Kubernetes workload.
The report includes a list of known vulnerabilities in OS packages and application dependencies, with a count per severity level (CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN) in report.summary.
For each container in a multi-container workload, operator-trivy creates a separate VulnerabilityReport in the corresponding namespace.
The link to the Kubernetes object is established via the ownerReferences field.
The report.dbMetadata field records the Trivy vulnerability database that was in use when the report was written: its version and the updatedAt, downloadedAt and nextUpdate times.
Fields with the javaDb prefix hold the same data for the Java vulnerability database.
The field does not change after the report is written.
It is absent if the operator had no information about the database at that time.
To find reports created with an outdated database, compare report.dbMetadata.updatedAt with the trivy-db.updatedAt value in the trivy-db-info ConfigMap, described in Database management.
Object names follow the pattern <workload type>-<workload name>-<container name>.
Example of a VulnerabilityReport for the nginx container of a ReplicaSet:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: VulnerabilityReport
metadata:
name: replicaset-nginx-6d4cf56db6-nginx
namespace: default
labels:
trivy-operator.container.name: nginx
trivy-operator.resource.kind: ReplicaSet
trivy-operator.resource.name: nginx-6d4cf56db6
trivy-operator.resource.namespace: default
resource-spec-hash: 7cb64cb677
ownerReferences:
- apiVersion: apps/v1
kind: ReplicaSet
name: nginx-6d4cf56db6
uid: aa345200-cf24-443a-8f11-ddb438ff8659
controller: true
blockOwnerDeletion: false
report:
artifact:
repository: library/nginx
tag: '1.16'
os:
family: debian
name: '10.3'
registry:
server: index.docker.io
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
summary:
criticalCount: 2
highCount: 0
mediumCount: 0
lowCount: 0
unknownCount: 0
dbMetadata:
version: "2"
updatedAt: "2026-06-10T06:12:44Z"
downloadedAt: "2026-06-10T07:00:12Z"
nextUpdate: "2026-06-11T06:12:44Z"
vulnerabilities:
- vulnerabilityID: CVE-2019-20367
resource: libbsd0
installedVersion: 0.9.1-2
fixedVersion: 0.9.1-2+deb10u1
severity: CRITICAL
score: 9.1
target: library/nginx:1.16
primaryLink: https://avd.aquasec.com/nvd/cve-2019-20367
- vulnerabilityID: CVE-2018-25009
resource: libwebp6
installedVersion: 0.6.1-2
fixedVersion: ''
severity: CRITICAL
score: 9.1
target: library/nginx:1.16
title: 'libwebp: out-of-bounds read in WebPMuxCreateInternal'
primaryLink: https://avd.aquasec.com/nvd/cve-2018-25009ConfigAuditReport
ConfigAuditReport is a resource that contains the results of a configuration audit of a Kubernetes object using tools such as Trivy.
Each check in the report has a category (for example, Kubernetes Security Check) and a severity level (CRITICAL, HIGH, MEDIUM, LOW).
report.summary holds a count per severity level.
Examples of checks include:
- running a container as a non-root user;
- defining resource requests and limits for containers;
- configuring network access (
hostNetwork,hostPID, etc.); - setting security flags to prevent privilege escalation.
ConfigAuditReport can be created for any namespaced object, including:
- workloads (Pod, Deployment, StatefulSet, etc.);
- auxiliary objects (Service, ConfigMap, Role, RoleBinding, etc.).
Each report is linked to the audited object via ownerReferences and stored in the same namespace.
Object names follow the pattern <workload type>-<workload name>.
Example of a ConfigAuditReport for a ReplicaSet of the nginx Deployment:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: ConfigAuditReport
metadata:
name: replicaset-nginx-6d4cf56db6
namespace: default
labels:
trivy-operator.resource.kind: ReplicaSet
trivy-operator.resource.name: nginx-6d4cf56db6
trivy-operator.resource.namespace: default
ownerReferences:
- apiVersion: apps/v1
kind: ReplicaSet
name: nginx-6d4cf56db6
report:
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
summary:
criticalCount: 2
highCount: 0
mediumCount: 0
lowCount: 9
checks:
- checkID: hostPIDSet
severity: CRITICAL
messages: ["Host PID is not configured"]
success: true
- checkID: notReadOnlyRootFilesystem
severity: LOW
messages: ["Filesystem should be read only"]
success: false
scope:
type: Container
value: nginxRbacAssessmentReport
RbacAssessmentReport is a report based on the analysis of RBAC (Role-Based Access Control) settings of a Role.
It includes results of checks performed by configuration audit tools such as Trivy. Examples of checks include identifying roles that:
- grant excessive privileges (for example, full access to secrets across all API groups);
- violate the principle of least privilege.
Each report covers one Role and is stored in the namespace of that Role. ClusterRoles are assessed in ClusterRbacAssessmentReport objects.
Object names follow the pattern role-<role name>.
If the role name cannot be used in an object name, a hash of the name replaces it, as in the example below.
Example of an RbacAssessmentReport for a Role in the kube-system namespace:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: RbacAssessmentReport
metadata:
name: role-868458b9d6
namespace: kube-system
report:
checks:
- category: Kubernetes Security Check
checkID: KSV051
description: Check whether role permits creating role bindings and associating
to privileged role/clusterrole
messages:
- ""
severity: HIGH
success: true
title: Do not allow role binding creation and association with privileged role/clusterrole
- category: Kubernetes Security Check
checkID: KSV056
description: The ability to control which pods get service traffic directed to
them allows for interception attacks. Controlling network policy allows for
bypassing lateral movement restrictions.
messages:
- ""
severity: HIGH
success: true
title: Do not allow management of networking resources
- category: Kubernetes Security Check
checkID: KSV041
description: Check whether role permits managing secrets
messages:
- Role permits management of secret(s)
severity: CRITICAL
success: false
title: Do not allow management of secrets
- category: Kubernetes Security Check
checkID: KSV047
description: Check whether role permits privilege escalation from node proxy
messages:
- ""
severity: HIGH
success: true
title: Do not allow privilege escalation from node proxy
- category: Kubernetes Security Check
checkID: KSV045
description: Check whether role permits wildcard verb on specific resources
messages:
- ""
severity: CRITICAL
success: true
title: No wildcard verb roles
- category: Kubernetes Security Check
checkID: KSV054
description: Check whether role permits attaching to shell on pods
messages:
- ""
severity: HIGH
success: true
title: Do not allow attaching to shell on pods
- category: Kubernetes Security Check
checkID: KSV044
description: Check whether role permits wildcard verb on wildcard resource
messages:
- ""
severity: CRITICAL
success: true
title: No wildcard verb and resource roles
- category: Kubernetes Security Check
checkID: KSV050
description: An effective level of access equivalent to cluster-admin should not
be provided.
messages:
- ""
severity: CRITICAL
success: true
title: Do not allow management of RBAC resources
- category: Kubernetes Security Check
checkID: KSV046
description: Check whether role permits specific verb on wildcard resources
messages:
- ""
severity: CRITICAL
success: true
title: No wildcard resource roles
- category: Kubernetes Security Check
checkID: KSV055
description: Check whether role permits allowing users in a rolebinding to add
other users to their rolebindings
messages:
- ""
severity: LOW
success: true
title: Do not allow users in a rolebinding to add other users to their rolebindings
- category: Kubernetes Security Check
checkID: KSV052
description: Check whether role permits creating role ClusterRoleBindings and
association with privileged cluster role
messages:
- ""
severity: HIGH
success: true
title: Do not allow role to create ClusterRoleBindings and association with privileged
role
- category: Kubernetes Security Check
checkID: KSV053
description: Check whether role permits getting shell on pods
messages:
- ""
severity: HIGH
success: true
title: Do not allow getting shell on pods
- category: Kubernetes Security Check
checkID: KSV042
description: Used to cover attacker’s tracks, but most clusters ship logs quickly
off-cluster.
messages:
- ""
severity: MEDIUM
success: true
title: Do not allow deletion of pod logs
- category: Kubernetes Security Check
checkID: KSV049
description: Some workloads leverage configmaps to store sensitive data or configuration
parameters that affect runtime behavior that can be modified by an attacker
or combined with another issue to potentially lead to compromise.
messages:
- ""
severity: MEDIUM
success: true
title: Do not allow management of configmaps
- category: Kubernetes Security Check
checkID: KSV043
description: Check whether role permits impersonating privileged groups
messages:
- ""
severity: CRITICAL
success: true
title: Do not allow impersonation of privileged groups
- category: Kubernetes Security Check
checkID: KSV048
description: Check whether role permits update/create of a malicious pod
messages:
- ""
severity: HIGH
success: true
title: Do not allow update/create of a malicious pod
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
summary:
criticalCount: 1
highCount: 0
lowCount: 0
mediumCount: 0
updateTimestamp: nullInfraAssessmentReport
InfraAssessmentReport contains the results of infrastructure checks of Kubernetes control plane components that run as pods in the kube-system namespace.
The CIS Kubernetes Benchmark checks of section 1.x use these reports.
The report contains report.scanner, report.summary and report.checks, like RbacAssessmentReport.
It is stored in the namespace of the checked object.
The complianceReports.skipSystemResources parameter does not affect InfraAssessmentReport.
ExposedSecretReport
ExposedSecretReport is a report on potential secrets discovered in a container image used in a Kubernetes workload.
The report lists strings that contain sensitive data (for example, tokens, keys, passwords) found in files within the image. Each finding includes a category, rule ID, severity level, and file path.
For each container in a multi-container workload, operator-trivy creates a separate ExposedSecretReport in the workload’s namespace.
The report is linked to the workload via ownerReferences.
Object names follow the pattern <workload type>-<workload name>-<container name>.
Example of an ExposedSecretReport with two Stripe tokens found in the image of the app container:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: ExposedSecretReport
metadata:
name: replicaset-app-67b77f5965-app
namespace: default
labels:
trivy-operator.container.name: app
trivy-operator.resource.kind: ReplicaSet
trivy-operator.resource.name: app-67b77f5965
trivy-operator.resource.namespace: default
ownerReferences:
- apiVersion: apps/v1
kind: ReplicaSet
name: app-67b77f5965
report:
artifact:
repository: myimagewithsecret
tag: v0.30.1
registry:
server: index.docker.io
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
secrets:
- category: Stripe
ruleID: stripe-access-token
severity: HIGH
target: "/app/config/secret.yaml"
match: "publishable_key: *****"
title: Stripe
- category: Stripe
ruleID: stripe-access-token
severity: HIGH
target: "/app/config/secret.yaml"
match: "secret_key: *****"
title: Stripe
summary:
criticalCount: 0
highCount: 2
mediumCount: 0
lowCount: 0
updateTimestamp: "2022-06-29T14:29:37Z"SbomReport
SbomReport is a report containing the SBOM (Software Bill of Materials) for a container image used in a Kubernetes workload.
It lists all software components, including OS packages and application dependencies found in the container. This information is useful for analyzing image contents, performing security audits, and ensuring compliance with vendor requirements.
For a multi-container workload, operator-trivy creates a separate SbomReport for each container.
The report is stored in the same namespace as the workload and linked via ownerReferences.
Object names follow the pattern <workload type>-<workload name>-<container name>.
Example of an SbomReport for the kube-apiserver container of a control plane pod:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: SbomReport
metadata:
creationTimestamp: "2023-07-10T09:37:21Z"
generation: 1
labels:
resource-spec-hash: 796669cd5d
trivy-operator.container.name: kube-apiserver
trivy-operator.resource.kind: Pod
trivy-operator.resource.name: kube-apiserver-kind-control-plane
trivy-operator.resource.namespace: kube-system
name: pod-kube-apiserver-kind-control-plane-kube-apiserver
namespace: kube-system
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: false
controller: true
kind: Pod
name: kube-apiserver-kind-control-plane
uid: 732b4aa7-91f8-40a3-8b21-9627a98a910b
resourceVersion: "6148"
uid: 2a5000fe-b97e-46d0-9de7-62fb5fbc6555
report:
artifact:
repository: kube-apiserver
tag: v1.21.1
components:
bomFormat: CycloneDX
components:
- bom-ref: 9464f5f9-750d-4ea0-8705-c8d067b25b29
name: debian
properties:
- name: aquasecurity:trivy:Class
value: os-pkgs
- name: aquasecurity:trivy:Type
value: debian
supplier: {}
type: operating-system
version: "10.9"
- bom-ref: pkg:deb/debian/base-files@10.3+deb10u9?arch=amd64&distro=debian-10.9
licenses:
- expression: GPL-3.0
license: {}
name: base-files
properties:
- name: aquasecurity:trivy:LayerDiffID
value: sha256:417cb9b79adeec55f58b890dc9831e252e3523d8de5fd28b4ee2abb151b7dc8b
- name: aquasecurity:trivy:LayerDigest
value: sha256:5dea5ec2316d4a067b946b15c3c4f140b4f2ad607e73e9bc41b673ee5ebb99a3
- name: aquasecurity:trivy:PkgID
value: base-files@10.3+deb10u9
- name: aquasecurity:trivy:PkgType
value: debian
- name: aquasecurity:trivy:SrcName
value: base-files
- name: aquasecurity:trivy:SrcVersion
value: 10.3+deb10u9
purl: pkg:deb/debian/base-files@10.3+deb10u9?arch=amd64&distro=debian-10.9
supplier:
name: Santiago Vila <sanvila@debian.org>
type: library
version: 10.3+deb10u9
- bom-ref: pkg:deb/debian/netbase@5.6?arch=all&distro=debian-10.9
licenses:
- expression: GPL-2.0
license: {}
name: netbase
properties:
- name: aquasecurity:trivy:LayerDiffID
value: sha256:417cb9b79adeec55f58b890dc9831e252e3523d8de5fd28b4ee2abb151b7dc8b
- name: aquasecurity:trivy:LayerDigest
value: sha256:5dea5ec2316d4a067b946b15c3c4f140b4f2ad607e73e9bc41b673ee5ebb99a3
- name: aquasecurity:trivy:PkgID
value: netbase@5.6
- name: aquasecurity:trivy:PkgType
value: debian
- name: aquasecurity:trivy:SrcName
value: netbase
- name: aquasecurity:trivy:SrcVersion
value: "5.6"
purl: pkg:deb/debian/netbase@5.6?arch=all&distro=debian-10.9
supplier:
name: Marco d'Itri <md@linux.it>
type: library
version: "5.6"
- bom-ref: pkg:deb/debian/tzdata@2021a-0+deb10u1?arch=all&distro=debian-10.9
name: tzdata
properties:
- name: aquasecurity:trivy:LayerDiffID
value: sha256:417cb9b79adeec55f58b890dc9831e252e3523d8de5fd28b4ee2abb151b7dc8b
- name: aquasecurity:trivy:LayerDigest
value: sha256:5dea5ec2316d4a067b946b15c3c4f140b4f2ad607e73e9bc41b673ee5ebb99a3
- name: aquasecurity:trivy:PkgID
value: tzdata@2021a-0+deb10u1
- name: aquasecurity:trivy:PkgType
value: debian
- name: aquasecurity:trivy:SrcName
value: tzdata
- name: aquasecurity:trivy:SrcRelease
value: 0+deb10u1
- name: aquasecurity:trivy:SrcVersion
value: 2021a
purl: pkg:deb/debian/tzdata@2021a-0+deb10u1?arch=all&distro=debian-10.9
supplier:
name: GNU Libc Maintainers <debian-glibc@lists.debian.org>
type: library
version: 2021a-0+deb10u1
dependencies:
- dependsOn:
- pkg:deb/debian/base-files@10.3+deb10u9?arch=amd64&distro=debian-10.9
- pkg:deb/debian/netbase@5.6?arch=all&distro=debian-10.9
- pkg:deb/debian/tzdata@2021a-0+deb10u1?arch=all&distro=debian-10.9
ref: 9464f5f9-750d-4ea0-8705-c8d067b25b29
- dependsOn: []
ref: pkg:deb/debian/base-files@10.3+deb10u9?arch=amd64&distro=debian-10.9
- dependsOn: []
ref: pkg:deb/debian/netbase@5.6?arch=all&distro=debian-10.9
- dependsOn: []
ref: pkg:deb/debian/tzdata@2021a-0+deb10u1?arch=all&distro=debian-10.9
- dependsOn:
- 9464f5f9-750d-4ea0-8705-c8d067b25b29
ref: pkg:oci/kube-apiserver@sha256:53a13cd1588391888c5a8ac4cef13d3ee6d229cd904038936731af7131d193a9?repository_url=k8s.gcr.io%2Fkube-apiserver&arch=amd64
metadata:
component:
bom-ref: pkg:oci/kube-apiserver@sha256:53a13cd1588391888c5a8ac4cef13d3ee6d229cd904038936731af7131d193a9?repository_url=k8s.gcr.io%2Fkube-apiserver&arch=amd64
name: k8s.gcr.io/kube-apiserver:v1.21.1
properties:
- name: aquasecurity:trivy:DiffID
value: sha256:417cb9b79adeec55f58b890dc9831e252e3523d8de5fd28b4ee2abb151b7dc8b,sha256:b50131762317bbe47def2d426d5c78a353a08b966d36bed4a04aee99dde4e12b,sha256:1e6ed7621dee7e03dd779486ed469a65af6fb13071d13bd3a89c079683e3b1f0
- name: aquasecurity:trivy:ImageID
value: sha256:771ffcf9ca634e37cbd3202fd86bd7e2df48ecba4067d1992541bfa00e88a9bb
- name: aquasecurity:trivy:RepoDigest
value: k8s.gcr.io/kube-apiserver@sha256:53a13cd1588391888c5a8ac4cef13d3ee6d229cd904038936731af7131d193a9
- name: aquasecurity:trivy:RepoTag
value: k8s.gcr.io/kube-apiserver:v1.21.1
- name: aquasecurity:trivy:SchemaVersion
value: "2"
purl: pkg:oci/kube-apiserver@sha256:53a13cd1588391888c5a8ac4cef13d3ee6d229cd904038936731af7131d193a9?repository_url=k8s.gcr.io%2Fkube-apiserver&arch=amd64
supplier: {}
type: container
timestamp: "2023-07-10T09:37:21+00:00"
tools:
- name: trivy
vendor: aquasecurity
serialNumber: urn:uuid:50dbce86-28c5-4caf-9d08-a4aadf23233e
specVersion: 1.4
version: 1
registry:
server: k8s.gcr.io
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
summary:
componentsCount: 5
dependenciesCount: 5
updateTimestamp: "2023-07-10T09:37:21Z"NodeVulnerabilityReport
This resource is provided only by the operator-trivy module and has no full equivalent in the Aqua Security project.
NodeVulnerabilityReport is a cluster-scoped resource that contains vulnerability scan results for a Kubernetes node’s root filesystem (rootfs).
Unlike VulnerabilityReport which represents container images scanning reports, NodeVulnerabilityReport represents results of scans of the host operating system packages installed directly on the node. This helps identify vulnerabilities in the underlying infrastructure that could affect all workloads running on that node.
The scans are performed using Trivy’s rootfs scanner against the node’s filesystem mounted into the scan Pod.
Like VulnerabilityReport, the report carries the report.dbMetadata field.
Object names follow the pattern node-<node name>.
Example of a NodeVulnerabilityReport for the worker-1 node:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: NodeVulnerabilityReport
metadata:
name: node-worker-1
labels:
trivy-operator.resource.kind: Node
trivy-operator.resource.name: worker-1
node-rootfs.scanner: Trivy
resource-spec-hash: 5d4c3b2a1f
app.kubernetes.io/managed-by: trivy-operator
annotations:
trivy-operator.aquasecurity.github.io/report-ttl: 24h0m0s
ownerReferences:
- apiVersion: v1
kind: Node
name: worker-1
uid: a1b2c3d4-e5f6-7890-abcd-ef1234567890
controller: true
blockOwnerDeletion: false
report:
artifact:
nodeName: worker-1
kind: node-rootfs
rootPath: /hostfs
os:
family: debian
name: Debian GNU/Linux 12 (bookworm)
scanner:
name: Deckhouse Container Security
vendor: Deckhouse
version: v0.6.8
summary:
criticalCount: 0
highCount: 167
mediumCount: 0
lowCount: 0
unknownCount: 0
updateTimestamp: "2026-02-09T09:30:00Z"
vulnerabilities:
- vulnerabilityID: CVE-2024-1234
resource: openssl
installedVersion: "1.1.1"
fixedVersion: "1.1.2"
severity: HIGH
score: 7.5
title: "OpenSSL Buffer Overflow"
primaryLink: https://nvd.nist.gov/vuln/detail/CVE-2024-1234
- vulnerabilityID: CVE-2024-5678
resource: curl
installedVersion: "7.88.0"
fixedVersion: "7.88.1"
severity: HIGH
score: 7.5
title: "Curl HTTP/2 vulnerability"
primaryLink: https://nvd.nist.gov/vuln/detail/CVE-2024-5678Key differences from VulnerabilityReport:
- Cluster-scoped: Not bound to a namespace
- OwnerReference to Node: Report is garbage-collected when the node is deleted
- Artifact type: Contains
nodeName,kind, androotPathinstead of image registry information - Severity filtering: By default, only
CRITICALandHIGHvulnerabilities are reported; other severity levels can be enabled with thenodeScanning.severitiesparameter
RegistryScanTarget
This resource is provided only by the operator-trivy module and has no full equivalent in the Aqua Security project.
RegistryScanTarget is a cluster-scoped resource that defines a container registry with a set of repositories within it to be periodically scanned for vulnerabilities. The registry scanner discovers image tags in each repository, scans them and stores the results in RegistryImageVulnerabilityReport objects.
Object names are chosen freely by the user.
Example — scan all tags matching a semver pattern in two repositories, rescanning every 24 hours:
apiVersion: deckhouse.io/v1alpha1
kind: RegistryScanTarget
metadata:
name: production-registry
spec:
registry: registry.example.com
repositories:
- myapp/backend
- myapp/frontend
tagFilter: '^v\d+\.\d+\.\d+$'
rescanPeriod: 1d
registrySecretRef:
name: registry-credentials
namespace: my-appAfter the first scan cycle, the status reflects progress and, when tagFilter is set, the matched tags per repository.
The time of the last scan cycle is recorded in the registry-scanner.deckhouse.io/last-scan-time annotation of the object.
Example of the status after a successful scan cycle:
status:
targets:
- repo: myapp/backend
tags: ["v1.2.3", "v1.3.0", "v2.0.0"]
- repo: myapp/frontend
tags: ["v1.2.3", "v2.0.0"]
conditions:
- type: Ready
status: "True"
reason: ScanCompleted
message: "Scan cycle completed."
lastTransitionTime: "2026-06-08T10:05:42Z"Key properties:
spec.repositories— list of repository paths to scan, for example["myapp/backend", "myapp/frontend"]. An empty or absent list selects every repository the registry returns from its catalog API; a registry that does not serve the catalog, or serves an empty one, puts the target intoReady=False.spec.tagFilter— optional Go regular expression. Only matching tags are scanned. When set,status.targetslists the matched tags of at most 50 repositories.spec.maxTags— per-repository tag limit after filtering (default:100). When it is exceeded, only the firstmaxTagstags in lexical order are scanned, and theReadycondition message notes the truncation. UsetagFilterto keep the tags you need within the limit.spec.maxRepositories— limit on the repositories taken from the catalog (default:100). It applies only whenspec.repositoriesis empty. The catalog is sorted by name, only the firstmaxRepositoriesrepositories are scanned, theReadycondition message notes the truncation, and the reports of the repositories left out are kept.spec.rescanPeriod— one of12h,1d,2d,7d(default:1d).spec.registrySecretRef— reference to akubernetes.io/dockerconfigjsonSecret for registry authentication.spec.insecure— iftrue, the scanner connects to the registry over plain HTTP or skips TLS certificate verification. Default:false.- Custom CA — if the module-level
additionalRegistryCAparameter is set, or the CA of the DP container registry is present, it is used for TLS automatically. No additional RegistryScanTarget configuration is needed.
RegistryImageVulnerabilityReport
This resource is provided only by the operator-trivy module and has no full equivalent in the Aqua Security project.
RegistryImageVulnerabilityReport is a cluster-scoped resource that stores the CVE scan results for a single image tag discovered via a RegistryScanTarget.
Its report structure mirrors VulnerabilityReport with the addition of registry, repository, tag, and digest fields in the artifact section. The report has no report.dbMetadata field.
Object names follow the pattern <target name>--<repository>--<tag>-<hash>:
- in
<target name>,<repository>and<tag>, upper-case letters are converted to lower case, and every character other thana-z,0-9and-is replaced with-; <hash>is the first 6 hexadecimal characters of the SHA-256 hash of the original target name, repository and tag;- if the name before
-<hash>is longer than 246 characters, it is truncated.
Each report carries an ownerReference to its RegistryScanTarget.
When the target is deleted, all its reports are garbage-collected automatically.
Reports for tags that disappear from the registry are also deleted on the next scan cycle.
Example of a report for the v2.0.0 tag of the myapp/backend repository:
apiVersion: deckhouse.io/v1alpha1
kind: RegistryImageVulnerabilityReport
metadata:
name: production-registry--myapp-backend--v2-0-0-94c793
ownerReferences:
- apiVersion: deckhouse.io/v1alpha1
kind: RegistryScanTarget
name: production-registry
controller: true
blockOwnerDeletion: true
report:
artifact:
registry: registry.example.com
repository: myapp/backend
tag: v2.0.0
digest: sha256:a1b2c3d4e5f6...
os:
family: debian
name: "Debian GNU/Linux 12 (bookworm)"
eosl: false
scanner:
name: operator-trivy
vendor: Deckhouse
version: 0.69.3
summary:
criticalCount: 1
highCount: 4
mediumCount: 12
lowCount: 31
unknownCount: 0
updateTimestamp: "2026-06-08T10:05:42Z"
vulnerabilities:
- vulnerabilityID: CVE-2024-1234
resource: openssl
installedVersion: "3.0.11"
fixedVersion: "3.0.12"
severity: CRITICAL
score: 9.8
title: "OpenSSL: buffer overflow in X.509 certificate verification"
description: "A buffer overflow in OpenSSL allows remote attackers to..."
publishedDate: "2024-01-15T00:00:00Z"
lastModifiedDate: "2024-02-01T00:00:00Z"
primaryLink: https://nvd.nist.gov/vuln/detail/CVE-2024-1234
links:
- https://openssl.org/news/secadv/20240115.txt
class: os-pkgs
packageType: debian
cvss:
nvd:
V3Vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
V3Score: 9.8
redhat:
V3Vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
V3Score: 9.8
cvsssource: nvdKey fields in the report:
report.artifact— identifies the scanned image:registry,repository,tag,digest.report.os— OS information:family,name, andeosl(trueif the OS version has reached end-of-service-life).report.vulnerabilities— list of found vulnerabilities. Each entry includes:vulnerabilityID,resource,installedVersion,fixedVersion,severity,scoretitle,description,publishedDate,lastModifiedDateprimaryLink,links— reference links to the CVE recordclass,packageType,packagePath,packagePURL— package classification detailscvss— map of CVSS scores per source (for example,nvd,redhat), each with V2/V3/V4 vectors and scorescvsssource— the source used for the primaryscorefield
SecurityScore
This resource is provided only by the operator-trivy module and has no equivalent in the Aqua Security project.
SecurityScore holds the security score of its namespace and the signals it was derived from.
The module maintains a single object named security-score in every user namespace and updates it only when the score changes.
SecurityScore is a namespaced resource: read access to it is granted together with access to the namespace by the d8:use:capability:module:operator-trivy:view role.
The score of the whole cluster is stored in a separate resource, ClusterSecurityScore.
Short name: secscore.
Example — the score of a namespace where scanning is enabled and the findings are known:
apiVersion: deckhouse.io/v1alpha1
kind: SecurityScore
metadata:
name: security-score
namespace: my-app
annotations:
security.deckhouse.io/score-updated-at: "2026-09-10T09:20:11Z"
score:
value: 82
formulaVersion: 3
scanned: true
podPolicy: Baseline
networkPolicies: 1
cve:
critical: 0
high: 3
medium: 11
low: 24
unknown: 0
misconfig:
critical: 0
high: 1
medium: 4
low: 9
unknown: 0
exposedSecrets:
critical: 0
high: 0
medium: 0
low: 0
unknown: 0
components:
coverage:
value: 1
cve:
value: 0.6
misconfig:
value: 0.75
network:
value: 1
psa:
value: 0.6
raw: 0.6
secrets:
value: 1Key properties:
score.value— the namespace score from 0 to 100.score.formulaVersion— version of the formula the score was calculated with. Scores calculated with different versions are not comparable.score.components— value of every component from 0 to 1. A component with no reports behind it hasnotMeasured: true, is excluded from the calculation, and itsvalueis0.score.scanned,score.podPolicy,score.networkPolicies— the signals the score was derived from.metadata.annotations—security.deckhouse.io/score-updated-atrecords when the score last changed.
Cluster-level security
ClusterVulnerabilityReport
ClusterVulnerabilityReport is a cluster-scoped resource with the vulnerabilities found in the components of the Kubernetes cluster.
The operator creates it by scanning the SBOM from the ClusterSbomReport of the k8s-cluster scan.
The report is owned by that ClusterSbomReport and is deleted together with it.
The report structure is the same as in VulnerabilityReport.
ClusterConfigAuditReport
ClusterConfigAuditReport is a cluster-scoped resource with the configuration audit results of a cluster-scoped object, such as a ClusterRoleBinding or a CustomResourceDefinition.
The report structure is the same as in ConfigAuditReport.
ClusterRbacAssessmentReport
ClusterRbacAssessmentReport is a cluster-scoped resource with the RBAC assessment of a ClusterRole. It contains the same checks and fields as RbacAssessmentReport.
Object names follow the pattern clusterrole-<ClusterRole name>.
If the ClusterRole name cannot be used in an object name, a hash of the name replaces it.
ClusterInfraAssessmentReport
ClusterInfraAssessmentReport is a cluster-scoped resource with the results of infrastructure checks of a cluster node.
The node configuration for the checks is collected by the node-collector job.
The report structure is the same as in InfraAssessmentReport.
ClusterSbomReport
ClusterSbomReport is a cluster-scoped resource with the SBOM of the Kubernetes cluster components from the k8s-cluster scan.
The report.artifact.tag field holds the Kubernetes version of the cluster.
The operator deletes a ClusterSbomReport whose report.artifact.tag differs from the current Kubernetes version of the cluster, together with its ClusterVulnerabilityReport.
The report structure is the same as in SbomReport.
ClusterComplianceReport
ClusterComplianceReport is a cluster-wide resource that contains a summary report on cluster compliance with security requirements.
The list of supported compliance frameworks is given in the Compliance reports section.
Report structure:
spec.compliance.controls— defines the compliance checks.status— contains the results of the checks defined inspec. Results are based on reports from various security scanners.
The results of this report are available in the ClusterComplianceReport object and in Deckhouse Console (see examples in CIS checks).
Example of the cis ClusterComplianceReport with two controls and the summary of the checks:
apiVersion: trivy.deckhouse.io/v1alpha1
kind: ClusterComplianceReport
metadata:
name: cis
spec:
compliance:
controls:
- checks:
- id: AVD-KCV-0048
commands:
- id: CMD-0001
description: Ensure that the API server pod specification file has permissions
of 600 or more restrictive
id: 1.1.1
name: Ensure that the API server pod specification file permissions are set
to 600 or more restrictive
severity: HIGH
- checks:
- id: AVD-KCV-0049
commands:
- id: CMD-0002
description: Ensure that the API server pod specification file ownership is
set to root:root
id: 1.1.2
name: Ensure that the API server pod specification file ownership is set to
root:root
severity: HIGH
# Other controls are omitted.
status:
summary:
failCount: 9
passCount: 107
updateTimestamp: "2025-07-29T06:00:00Z"ClusterSecurityScore
This resource is provided only by the operator-trivy module and has no equivalent in the Aqua Security project.
ClusterSecurityScore holds the security score of the cluster and the signals it was derived from.
The module maintains a single object named cluster.
Read access is granted by the d8:manage:permission:module:operator-trivy:view role.
Access to a namespace does not grant read access to ClusterSecurityScore.
Per-namespace scores are published as SecurityScore objects.
Short name: clustersecscore.
Example — a cluster where nothing is scanned yet, so the report-backed components are not measured:
apiVersion: deckhouse.io/v1alpha1
kind: ClusterSecurityScore
metadata:
name: cluster
annotations:
security.deckhouse.io/score-updated-at: "2026-09-10T09:20:11Z"
score:
value: 27
formulaVersion: 3
namespaces:
total: 8
scanned: 0
namespaceScores:
total: 8
average: 22
components:
coverage:
value: 0
cve:
notMeasured: true
value: 0
misconfig:
value: 0.26
network:
value: 0.13
psa:
value: 0.53
raw: 0.53
secrets:
notMeasured: true
value: 0
compliance:
value: 1
compliance:
cis:
failCount: 0
passCount: 116
nsa:
failCount: 0
passCount: 25
topNamespaces:
cve: []
misconfig:
- namespace: my-app
critical: 0
high: 16
modules:
operatorTrivy:
enabled: true
denyVulnerableImages: false
complianceReportsEnabled: ["cis", "nsa"]
admissionPolicyEngine:
enabled: true
defaultPolicy: Baseline
enforcementAction: Deny
enforcementMultiplier: 1
runtimeAuditEngine:
enabled: falseKey properties:
score.value— the cluster score from 0 to 100.score.namespaceScores— number of scored namespaces and their average score. The average is not comparable with the cluster score: the cluster includes thecompliancecomponent, a namespace does not.score.topNamespaces— namespaces that need attention first. The field is available to users who cannot list SecurityScore objects across the cluster.score.modules.admissionPolicyEngine— the only field of the object where the pod security enforcement mode and its coefficient are published.score.compliance— pass and fail counts of every deployed compliance report, keyed by report name.
The full list of components, their weights and the formula are described in the Security score section.
Deckhouse Platform installs CRDs but does not remove them when a module is disabled. If you no longer need the created CRDs, delete them.