Why container vulnerability management in a regulated estate needs its own design
Regulated organizations running self-hosted Kubernetes rebuild container images often, and many services inherit the same base image, so one vulnerable layer can appear in dozens of workloads at once. Trivy covers container images, filesystems and cluster resources, DefectDojo holds the findings, deduplication and remediation records, and the right split depends on where your clusters run and who must prove that a finding was fixed. A regulated estate that runs clusters in its own cloud accounts, data centers or air-gapped networks has different feed, scanning and evidence constraints than one that uses a managed registry. This page covers only what changes for containers and Kubernetes. Host patching, feed selection and framework deadlines are covered on the sibling pages.
Container findings differ from host findings in three ways. First, workloads are ephemeral: a pod may exist for minutes, so a scan that runs only on a weekly schedule against live hosts misses it. Trivy Operator addresses this by scanning as workloads are created and storing results as Kubernetes custom resources, which means the evidence lives in the cluster and must be exported or retained on purpose. Second, vulnerabilities are inherited: a CVE in a base image layer belongs to the image build, not to the application team that owns the service, so ownership and fix paths must be mapped to the base image pipeline. Third, risk is often configuration rather than package code. Misconfigurations, exposed secrets and RBAC gaps are cluster-level issues that a host scanner may not model at all.
Before you select tooling, confirm three things with your platform and security teams: which registries and clusters are in scope, whether the databases Trivy uses can be reached or must be mirrored internally, and which Kubernetes benchmark or hardening guide your assessors expect the cluster to be measured against. The Trivy Operator compliance reports cover several such profiles, but whether they satisfy a given assessor is a question to put to that assessor, not to the tool vendor.
Which regulatory requirements shape container scanning and what they mean for the build
This table maps the HIPAA technical safeguards and FTC Safeguards Rule provisions to concrete container and Kubernetes controls, showing what each asks for and what evidence an assessor will want to see. Use it to shape your CI pipeline, cluster audit settings and log retention. The rules do not name tools or scan intervals, so confirm cadence and retention periods with your assessor before fixing them in the build.
| Requirement | What the build should include | Evidence to keep |
|---|---|---|
| HIPAA 45 CFR 164.312 access control (unique user identification) | Individual Kubernetes user identities via OIDC, no shared admin kubeconfig, RBAC limiting who can read or change scan results | RBAC bindings export, identity provider user list, access review records |
| HIPAA 45 CFR 164.312 audit controls | Kubernetes audit logging enabled for the API server, Trivy Operator reports stored as custom resources, scan results forwarded to a central store | Audit policy file, sample of recorded API events, report history showing scans per workload |
| HIPAA 45 CFR 164.312 person or entity authentication | Authenticated access to the registry and DefectDojo, signed or digest-pinned images promoted through CI | Registry access logs, CI pipeline run records, image digest-to-release mapping |
| FTC Safeguards Rule 16 CFR 314.4 monitoring and logging of authorized user activity | Logs of who pulled, pushed, deployed or exempted an image, plus cluster admission and exec events | Log samples covering user actions, alert records for blocked deployments, reviewer sign-off on exceptions |
| FTC Safeguards Rule 16 CFR 314.4 multi-factor authentication | MFA enforced at the identity provider for anyone who can reach the registry, CI system, cluster API or DefectDojo | Identity provider MFA policy, enrollment report, exception list with approvals |
| Log retention for scanner and cluster activity | Retention periods for CI logs, audit logs and scanner reports set in writing with the assessor, stored outside the cluster | Written retention schedule, storage configuration, test restore of an older log |
| Scan frequency and rescan cadence | Scans on image build, on registry push and on a schedule for running workloads, with cadence documented per framework | Scan schedule record, Trivy Operator configuration, dated scan results for sampled images |
| Confirm with your assessor | Tool choice and scan intervals are not set by these rules; ask which evidence your framework requires and how long to keep it | Assessor's written list of expected evidence and retention periods |
Which open-source tools fit container and cluster scanning, and why
Container and cluster scanning usually combines an image and filesystem scanner, an in-cluster scanner that reports on running workloads, a place to track findings, and the cluster itself. The cards below cover each piece, the license terms that matter, and the features that depend on which edition you run.
Trivy for images, filesystems and IaC
Trivy is licensed under Apache-2.0 and scans container images, filesystems, remote Git repositories, virtual machine images and Kubernetes manifests. It finds OS packages and software dependencies, CVEs, infrastructure as code misconfigurations, exposed secrets and licenses, and it can generate an SBOM or read an existing one. Output formats include table, JSON and SARIF, so the same scan can feed a CI gate and a tracker. Check which scanners your pipeline enables, because one scan type rarely covers every risk.
Trivy Operator for continuous cluster reports
Trivy Operator is licensed under Apache-2.0 and scans a cluster as workloads change, for example when a new Pod is created. It stores vulnerability, config audit, exposed secret and RBAC reports as Kubernetes custom resources, so teams can query them with standard tooling. Its compliance reports cover the NSA/CISA Kubernetes Hardening Guidance, the CIS Kubernetes Benchmark and the Pod Security Standards baseline and restricted profiles. Confirm the report set and CRD versions you deploy against your cluster version before you build dashboards on them.
DefectDojo for tracking and deduplication
The DefectDojo open-source edition is licensed under BSD-3-Clause and orchestrates findings, deduplicates them and tracks remediation across scanners. Its REST API v2 lets pipelines push Trivy results automatically. In the open-source edition, accounts are local only: SSO with SAML, OIDC or OAuth, LDAP and MFA are Pro features. Decide early whether local accounts meet your access policy, and confirm current feature availability with the vendor before you commit to a design.
Kubernetes secrets handling
Kubernetes is licensed under Apache 2.0, and its Secrets are stored unencrypted in etcd by default. Scanners will flag exposed secrets in manifests, but they will not fix the storage default. Configure encryption at rest, restrict list and watch access with least-privilege RBAC, or pull secrets from an external store through the Secrets Store CSI Driver. Ask your platform team to show the encryption configuration as evidence, since assessors commonly request it.
Trivy commercial offering and project status
Trivy is an Aqua Security open source project, and Aqua's commercial offering is built on top of Trivy. Open-source use and commercial support are separate decisions. Before you rely on a feature, check whether it appears in the Apache-2.0 project or only in a commercial product, and ask the vendor which version receives security fixes and how long. Record the answer in your vendor register so that an upgrade or support change does not surprise the team.
How image scans in CI, registry checks and cluster reports connect
Trivy runs at three points in the container lifecycle, and each one should feed the same DefectDojo engagement history. The first is pre-deployment in CI, where Trivy scans an image after it is built and before it is pushed or promoted. This is where a policy can either fail the pipeline or only warn, and the choice between those two modes is the first decision to make: blocking on high or critical findings stops known-vulnerable images from shipping, while warning-only keeps delivery moving but depends on someone reading the output. The second point is registry scanning for images already stored, which catches CVEs published after an image was built. The third is continuous in-cluster scanning by Trivy Operator, which runs when new Pods appear and stores vulnerability reports as Kubernetes custom resources. Confirm which of these your teams will rely on before you write the pipeline logic, because each one produces a different artifact.
Trivy can write results in table, JSON, SARIF and other formats, and DefectDojo imports scanner output through its REST API (API v2) and its parsers. The Trivy report format each pipeline emits must match a DefectDojo parser that your installed version supports, so validate the import path for every report type with a sample file from your own images before relying on it for audit evidence. Trivy Operator reports are Kubernetes resources rather than files, so you will need a small export step, or a separate collection job, to get them into DefectDojo; design and test that step as part of the implementation, not as an afterthought. DefectDojo's deduplication uses per-parser hashcode fields, so confirm which fields the chosen parser hashes and whether the same CVE on a rebuilt image is treated as one finding or as several.
Deduplication is what keeps a rebuilt image from creating a fresh queue of tickets for the same vulnerability. When a team rebuilds an image with a patched base layer, the CVE on the older image and the newer image should resolve to a single tracked finding within the same product, not a duplicate that engineers have to close again. Test this with two builds of one test image before you rely on it. Plan for the case where the same CVE appears in an image, in a registry copy and in a running Pod: whether DefectDojo treats these as one finding depends on how each import is scoped (product, engagement and component identifiers), so agree that scoping with the security team first. Illustrative example: if a payments service image is rebuilt weekly, the reader should see one open finding per CVE that moves to closed when the base image changes, not seven new entries.
How deployment location changes database updates and scanning reach
Where the scanner and cluster can reach the public internet, Trivy can pull its vulnerability, Java and check databases directly from the default sources on each run or on its own schedule. This is the simplest model because the database refresh is handled by the scanner itself, and the scan data reflects the most recent published advisories at the time of the scan. The trade-off is that every scanning workload depends on outbound access and on the availability of external sources, which many security teams will need to approve explicitly.
- Freshness: Results reflect the latest database the scanner downloads, so a scan run today sees advisories published today.
- Outbound access: Scanner pods or CI runners need approved egress to the database sources, which should be documented in the network diagram.
- Update ownership: The platform team usually owns the scanner image and its cache, while the security team owns the rule that a scan must not run on a stale database.
- Evidence: Keep the scanner version and database timestamp in each report so an assessor can see which data supported a finding.
- Concurrency: Many parallel scans can each fetch databases, so confirm cache sharing in the build system.
Confirm with your security team whether egress for database downloads is permitted from build and cluster networks before you rely on this model.
Many regulated organizations allow only outbound traffic through a controlled proxy or a managed internal registry. In this model, the Trivy databases (trivy-db, trivy-java-db and trivy-checks) are published as OCI images into an internal registry, and the scanner is pointed at that registry with the database repository flags. The scanner then fetches its data from inside the network, and the security team controls when new database versions are admitted.
- Flags: Set
--db-repository,--java-db-repositoryand--checks-bundle-repositoryto the internal mirror paths in the scanner configuration. - Mirror freshness: The mirror is only as current as its last sync, and the Trivy documentation warns that mirrors must be kept updated.
- Update job: Assign a named owner for the sync job, with an alert when the mirror timestamp exceeds the freshness threshold your policy sets.
- Image provenance: Store mirrored database images in the same registry controls used for application images, including access logs and retention.
- Testing: Test a new mirror version in a non-production scan path before it becomes the default for cluster admission scans.
Confirm the exact mirror path format and sync tooling against the current Trivy self-hosting documentation for the version you deploy.
On networks with no route to the internet, the database has to arrive by controlled transfer. The Trivy documentation describes downloading the trivy-db or trivy-java-db archive on a connected machine and copying it into the cache db directory on the offline system. Freshness in this model depends entirely on how often the transfer happens, so the scan cadence and the transfer cadence must be designed together.
- Transfer process: Download the archive on a connected machine, verify it, record its origin and time, and move it through the approved media process.
- Cache location: Place the archive in the Trivy cache db directory on the offline scanner host or in the image used for offline scans.
- Freshness ceiling: Scan results can never be newer than the last accepted transfer, so document that date in every report.
- Update ownership: Usually shared between the platform team (transfer and load) and the security team (acceptance and sign-off), with a named backup for each.
- Kubernetes scope: Offline clusters still need images built and scanned upstream, so align transfer dates with the image promotion process.
Confirm with your accreditation or network security authority how often transfers are permitted and what they must record.
How a container vulnerability program rolls out in phases
The sequence builds an inventory first, then adds scanning in stages so that each phase produces evidence the next one depends on. Gates that block builds arrive last, once the team has agreed what counts as an exception.
Inventory clusters, registries and base images
DeployOpen's engineers and your platform team list every Kubernetes cluster, container registry, CI pipeline that builds images, and the base images those builds start from, including which teams own each one. Your platform team should confirm the owner for each registry and cluster, and whether any clusters are managed by a cloud provider or a vendor. The phase is done when the inventory is reviewed and each image family has a named owner.
Run Trivy in CI in report-only mode
Trivy is added to existing build pipelines to scan images and produce reports in formats such as table, JSON or SARIF, without failing any build. This lets the team see the baseline count of findings and check that scans complete reliably. Your engineering leads should confirm which pipelines are in scope and where reports are stored. The phase closes when every in-scope pipeline produces a report on each build and the baseline is recorded.
Scan images in the registry
Scanning is extended to images already stored in the registries, which catches images built before CI scanning existed and images pushed outside the standard pipeline. Trivy's vulnerability databases should be mirrored to an internal registry if your environment restricts internet access, and the mirror must be refreshed on a schedule. Your security team should confirm which registries are reachable and who receives the registry scan output. The phase is complete when every registry is covered and the mirror update process is documented.
Deploy Trivy Operator in a non-production cluster
Trivy Operator is installed in one non-production cluster so it can scan workloads as they are created and store results as Kubernetes custom resources. Reports on configuration, exposed secrets and RBAC are reviewed alongside vulnerability results, and compliance reports are compared against the benchmarks your auditors use. Your cluster administrators should confirm the operator's permissions and the resource overhead in that cluster. The phase is complete when reports appear for every workload type in the test cluster and the team has reviewed them for noise.
Import and deduplicate findings in DefectDojo
Trivy results from CI, registries and the operator are imported into DefectDojo, which groups duplicate findings and tracks each one to a remediation outcome. Engineering and security leads agree how product, engagement and owner are assigned so that findings reach the right team. Your team should confirm which fields and deduplication settings match its scan sources. The phase closes when a single view shows open findings per application and duplicates from the different sources are merged.
Define exceptions before enabling policy gates
Security, platform and application owners agree a written exception process, covering who can accept a risk, how long an exception lasts, and what compensating control applies. Known false positives and unfixable base image findings are recorded with their justification. Your risk owner should approve the exception criteria before any gate is enforced. The phase is done when the exception register exists and the criteria are signed off.
Enable policy gates for critical findings
Once exceptions are defined, the pipeline and admission controls are set to block deployment of images with critical findings that lack an approved exception. Gates are first applied to the non-production clusters and pipelines, then extended to production after the team has tested the failure path. Your release engineers should confirm how blocked builds are reported and who can override them under the exception process. The phase closes when a test build with an unapproved critical finding is blocked and the same build with an approved exception passes.
Run the base image update process
A recurring process is set up to rebuild application images when their base images receive fixes, track which applications use each base image, and route updates to owners. Kubernetes version support and cluster upgrade schedules are reviewed alongside, because node and control plane changes can affect the images that run. Your platform team should confirm the rebuild cadence and who approves base image changes. The phase is complete when a base image update flows from the registry to the affected applications and the result is recorded in DefectDojo.
What buyers ask about container vulnerability management before hiring help
What drives the cost of container vulnerability management?
The main drivers are the number of clusters, registries and build pipelines in scope, how many base images and application images your teams maintain, the volume of exceptions and risk acceptances you need to record, and how many systems the findings must reach, such as ticketing, chat and reporting tools. Trivy and DefectDojo are open source, so the license line is usually zero, but you still pay for people: pipeline integration, cluster deployment, policy design and remediation coordination. Ask any partner for a quote that separates these components, lists the clusters and registries in scope, and states which integrations are included. DeployOpen does not publish a price list; a quote follows from the written scope.
Which parts of container scanning are one-time work and which recur?
One-time work includes designing the scanning architecture, wiring Trivy into CI and registries, deploying Trivy Operator into clusters, importing findings into DefectDojo, and setting the blocking policies. Recurring work includes keeping vulnerability databases current, updating scanner versions, reviewing new findings each week, rebuilding base images, handling Kubernetes upgrades, and reviewing exceptions before they expire. The Trivy documentation warns that internal mirrors of its databases must be kept updated, so that refresh process is a standing duty, not a setup task. Ask a partner to state which items are fixed-scope deliverables and which fall under a support retainer.
Can our own team run Trivy without outside help?
Yes, many teams run Trivy themselves, because it is Apache-2.0 licensed and scans container images, filesystems, Git repositories, virtual machine images and Kubernetes. The harder part is the operating model: deciding which findings block a build, who owns each base image, how exceptions are approved, and how results reach engineering teams without flooding them. Trivy reports can be produced as table, JSON, SARIF, template, SBOM or GitHub dependency snapshot formats, so integration choices matter early. An in-house team should confirm it has an engineer who can own the pipeline, a platform owner for clusters, and time for weekly triage. An outside partner is most useful for the initial design, the policies and the handover.
How does Kubernetes upgrade cadence affect vulnerability scanning?
Kubernetes releases happen about three times per year on a cycle of roughly 14 weeks, and the project maintains only the three most recent minor releases. As of September 2026, the supported minors were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to kubernetes.io/releases. Kubernetes 1.19 and newer receive about one year of patch support, so scanners must track which minor version each cluster runs and flag clusters drifting out of support. The version skew policy also means kubelets can be up to three minor versions behind the API server, so mixed versions must be scanned and planned for. Ask your partner how upgrade windows feed into scan scope and exception records.
What do engineering and security teams need to supply?
Security needs to define severity thresholds, exception rules, remediation deadlines and the evidence it must keep. Platform engineering needs to provide cluster access, registry access, CI runner permissions and a place to run DefectDojo and the Trivy Operator, with an internal mirror for scanner databases if the clusters have restricted egress. Application teams need a named owner for each image and a way to receive tickets. The work also needs someone who can approve blocking policies so builds do not fail without warning. Ask any partner to list these inputs in the written scope so that missing access does not delay the rollout.
Do we need DefectDojo Pro to get SSO and MFA?
The DefectDojo README states that the open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are Pro features. If your policy requires single sign-on or MFA for the vulnerability tracker, you must either buy the Pro edition or place access behind an identity-aware proxy or other control in your environment. Confirm the current feature list with DefectDojo before deciding, since editions change. Also confirm that the Pro edition, which the README lists from $100 per month, fits your hosting and procurement rules. Keep this decision in the risk register, because the tracker holds sensitive vulnerability data.
How long does a container vulnerability rollout take?
Rollout is best described in phases rather than as a fixed duration, and the length depends on cluster count, pipeline complexity and how many teams must adopt the process. The first phase is discovery: inventory of clusters, registries, base images and CI systems, plus agreement on policies and severity thresholds. The second phase is pilot: scanning in CI for a small set of images, deploying the Trivy Operator to one cluster, and importing results into DefectDojo. The third phase is expansion to remaining clusters and registries, followed by blocking policies enabled gradually and a handover of runbooks. Ask a partner to propose these phases with deliverables and acceptance criteria in a written, fixed scope.
Which evidence assessors request and what to ask a partner
An assessor who samples container vulnerability management will usually ask for a short list of records: Trivy scan logs and JSON or SARIF output from CI and registry scans, Trivy Operator compliance reports for the cluster, DefectDojo finding history showing when each finding was imported, who owns it, what severity it carries and when it closed, exception approvals with an expiry date and a named approver, and records of base image updates showing which image digests replaced which. DeployOpen prepares these records, configures the pipelines and reports that produce them, and documents how they are retained. The assessment conclusion itself belongs to the independent auditor or certification body, so the evidence should be designed for their sampling method, not for a presentation to them.
When you interview a partner, start with the Trivy database mirror. Ask how the trivy-db, trivy-java-db and trivy-checks images are mirrored to your internal registry, who runs the update job, how the --db-repository and related flags are pinned in CI, and how stale mirrors are detected, since Trivy's documentation warns that mirrors must be kept updated. Then ask how the policy gate is designed: which severities or CVEs block a build, whether exceptions are stored as code with an expiry, and how a blocked deploy is reported to the team that owns it. Ask what Trivy Operator costs the cluster in CPU, memory and scan load on node pools, and how scan scheduling is tuned. Ask where DefectDojo will run, who patches it, how its data is backed up, and what retention period you will document. Finally, ask who rebuilds base images, who approves the rebuild, and how the rebuild reaches every dependent image.
How DeployOpen scopes and supports container vulnerability management
The sequence below moves from a written scope to a running Trivy and DefectDojo workflow inside your own environment, with hardening, documentation and handover recorded before any retainer begins. Each step closes with a check you can verify.
Agree the written scope first
Before any work starts, DeployOpen and your team agree the scope in writing: which registries, CI pipelines, clusters, infrastructure as code repositories and base images are in, which teams receive findings, and which environments are excluded. Your security lead, platform lead and a representative from the engineering teams that own the images should review the draft. The step is done when the signed scope lists named systems, deliverables and acceptance checks. Ask for the scope to state how the Trivy vulnerability databases will reach the environment, since that depends on whether the network is connected.
Confirm the environment and data path
DeployOpen reviews where the tools will run: your cloud accounts, data centers or an air-gapped network. The review records where Trivy databases come from, whether they are mirrored to an internal registry through the documented repository settings, and how offline updates are carried in when there is no direct connection. It also records who can read scan results, since image findings can expose internal package and configuration details. The step closes with an environment decision record that your security and platform teams approve.
Deploy Trivy in CI and registries
DeployOpen installs Trivy in your build pipelines and wires scanning of container images, filesystems and infrastructure as code into the stages you named in scope. Output formats are set to suit each consumer, such as table output for developers, JSON for automation and SARIF for code hosting views. Scanning also covers secrets and licenses where your scope includes them. The step is complete when test builds produce reports in every agreed format and a deliberately vulnerable test image fails the scan as expected.
Deploy Trivy Operator in the clusters
In each cluster in scope, DeployOpen installs Trivy Operator so that workloads are scanned as they run, for example when a new Pod is created. Results are stored as Kubernetes custom resources, including vulnerability, configuration audit, exposed secret, RBAC and compliance reports. Compliance profiles are enabled only where your scope names them, such as the CIS Kubernetes Benchmark or Pod Security Standards. The step closes when reports appear for sample workloads in each cluster and your platform team can query them with standard Kubernetes tooling.
Stand up DefectDojo as the findings system
DeployOpen installs DefectDojo inside your environment and configures product and engagement structures that match your ownership model. Trivy and Operator results are imported through the API, and duplicate handling is tuned so that the same image vulnerability does not reopen as a new item on every build. Access is set up with the accounts your scope allows. The open-source edition uses local accounts, and SSO, LDAP and MFA are listed as DefectDojo Pro features, so the scope should state how identity will be handled. The step is done when imports from pipelines and clusters land in the correct products without duplicates.
Set policy gates and ticket routing
DeployOpen configures the rules that decide when a build or deployment is blocked, using severity thresholds and findings states agreed in scope, and connects DefectDojo findings to the queues your engineering teams already use. Base image update handling is documented so that a fixed upstream image flows back to affected services. Exceptions are recorded with an owner and a review point. The step closes when a test build is blocked by a policy gate and a test finding creates a ticket in the agreed queue.
Harden, document and hand over
DeployOpen hardens the deployed components, including access to the scanner services, storage of reports and the Kubernetes permissions that govern who can read vulnerability resources. It then writes runbooks for updating Trivy databases, upgrading components, handling exceptions and rebuilding the environment. A handover session walks your platform and security teams through the runbooks. The step is complete when your team has run the database update procedure and a restore test succeeds, and the documentation is accepted in writing.
Decide on an optional retainer
After handover, your team can choose whether to keep DeployOpen on a retainer for upgrades, continuous testing or ongoing support. Retainers are separate from the fixed-scope build and are agreed in their own written terms. The decision should consider how often your clusters change, how quickly Kubernetes minor versions move through their support windows, and whether your team can keep Trivy databases and components current without outside help. The step closes with a signed retainer scope or a documented decision to operate in-house.
