This guide installs OWASP Dependency-Track on Kubernetes with the official Helm chart, publishes it via ingress with a Let’s Encrypt certificate and connects the Trivy Operator. Trivy scans every workload in the cluster, creates SBOMs and a small bridge service pushes them into Dependency-Track automatically – so every running image shows up as a project with its vulnerabilities.
Updated September 2026: official chart repository, current chart versions (1.x and 2.x), Trivy Operator 0.36 and the webhook setup that was missing in the first version.
Quick start: Dependency-Track Helm chart
If you only need Dependency-Track itself, three commands are enough:
helm repo add dependency-track https://dependencytrack.github.io/helm-charts
helm repo update
helm install dtrack dependency-track/dependency-track --version 1.5.0 \
--namespace dtrack --create-namespace -f values.yamlThe official chart comes in two lines – pick the one that fits:
| Chart version | Dependency-Track | Database |
|---|---|---|
1.x (e.g. 1.5.0) | 4.14 | embedded H2 – nothing else to install, fine for labs and small teams |
2.x (e.g. 2.5.0) | 5.x | external PostgreSQL required (see step 2b) |
The old chart from evryfs/helm-charts is no longer maintained – use dependencytrack.github.io/helm-charts.
Prerequisites
- A Kubernetes cluster (kind, k3s, managed – anything works) and Helm 3
- An ingress controller, e.g. ingress-nginx
- cert-manager with a ClusterIssuer for Let’s Encrypt (here:
letsencrypt-production) - A DNS record for Dependency-Track pointing to your ingress, e.g.
dtrack.example.com - Memory: plan at least 4–5 GiB for the Dependency-Track API server
Step 1: values.yaml for ingress and Let’s Encrypt
The chart routes /api to the API server and / to the frontend through a single ingress. Create a values.yaml:
ingress:
enabled: true
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-production"
hostname: "dtrack.example.com"
ingressClassName: "nginx"
tls:
- secretName: dt-tls
hosts:
- dtrack.example.comUse ingressClassName instead of the old annotation kubernetes.io/ingress.class – the annotation is deprecated.
Step 2: Install Dependency-Track with Helm
helm repo add dependency-track https://dependencytrack.github.io/helm-charts
helm repo update
helm install dtrack dependency-track/dependency-track --version 1.5.0 \
--namespace dtrack --create-namespace -f values.yaml
kubectl get pods -n dtrack
kubectl get certificate -n dtrackAs soon as the certificate is Ready, the frontend is reachable at https://dtrack.example.com. Log in with admin / admin and change the password right away.
Step 2b: Dependency-Track 5 (chart 2.x) with PostgreSQL
From chart 2.0 on, Dependency-Track needs an external PostgreSQL. Create a secret with the credentials and add the database section to your values.yaml:
kubectl create secret generic dtrack-db -n dtrack \
--from-literal=username=dtrack --from-literal=password='<your-password>'database:
jdbcUrl: "jdbc:postgresql://postgres.dtrack.svc:5432/dtrack?reWriteBatchedInserts=true"
existingSecret:
name: dtrack-dbThen install with --version 2.5.0 instead of 1.5.0.
Step 3: Install the Trivy Operator
The Trivy Operator scans all workloads and stores the results as Kubernetes resources (VulnerabilityReport, SbomReport, ConfigAuditReport). With operator.webhookBroadcastURL it also sends every new report to the bridge from step 4:
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system --create-namespace \
--version 0.36.0 \
--set operator.webhookBroadcastURL=http://sbomreport-to-dependencytrack.dtrack.svc.cluster.local:8080/Check the first results:
kubectl get vulnerabilityreports --all-namespaces -o wide
kubectl get sbomreports --all-namespaces
kubectl get configauditreports --all-namespaces -o wide
kubectl logs -n trivy-system deployment/trivy-operatorStep 4: Import SBOMs automatically with sbomreport-to-dependencytrack
sbomreport-to-dependencytrack receives the reports from the Trivy Operator and uploads them as BOM to Dependency-Track.
API key: In Dependency-Track go to Administration → Access Management → Teams → Automation and copy the API key. If projects are created but tags are missing, give the team the permission PORTFOLIO_MANAGEMENT.
kubectl create secret generic sbomreport-to-dependencytrack -n dtrack \
--from-literal=api-key=odt_xxxxxxxxxxxxxxxxCreate dtrack-trivy-operator-values.yaml. The tags make projects filterable by namespace and workload:
config:
apiKeySecretName: sbomreport-to-dependencytrack
baseUrl: "https://dtrack.example.com"
projectName: "[[.sbomReport.report.artifact.repository]]"
projectVersion: "[[.sbomReport.report.artifact.tag]]"
projectTags: "kube_namespace:[[.sbomReport.metadata.namespace]],kube_name:[[.sbomReport.metadata.name]]"helm repo add sbomreport-to-dependencytrack https://takumakume.github.io/sbomreport-to-dependencytrack/charts
helm repo update
helm install sbomreport-to-dependencytrack sbomreport-to-dependencytrack/sbomreport-to-dependencytrack \
--namespace dtrack -f dtrack-trivy-operator-values.yamlKeep the release name sbomreport-to-dependencytrack – the service name in the webhook URL from step 3 depends on it. After a few minutes the first projects appear in Dependency-Track.
Upgrade
helm repo update
helm upgrade dtrack dependency-track/dependency-track --version <new-version> -n dtrack -f values.yaml
helm upgrade trivy-operator aqua/trivy-operator --version <new-version> -n trivy-system --reuse-valuesSwitching from chart 1.x to 2.x is a major upgrade (H2 → PostgreSQL). Read the chart’s migration notes and back up first.
Troubleshooting
| Symptom | Check / fix |
|---|---|
| No certificate, browser warning | kubectl describe certificate -n dtrack – does the ClusterIssuer name match the annotation? |
| API server restarts (OOMKilled) | Raise apiServer.resources.limits.memory to at least 4–5 GiB |
| No projects in Dependency-Track | kubectl logs -n dtrack deploy/sbomreport-to-dependencytrack – webhook URL, API key and permissions |
| Trivy finds nothing | Enable debug logs (below) and check kubectl logs -n trivy-system deployment/trivy-operator |
Trivy Operator debug mode: set OPERATOR_LOG_DEV_MODE: "true" in the ConfigMap and restart the operator – new ConfigMap values only apply after a rollout:
kubectl edit configmap trivy-operator-config -n trivy-system
kubectl rollout restart deployment trivy-operator -n trivy-systemUseful commands
kubectl get configmap -n trivy-system
kubectl describe configmap trivy-operator-trivy-config -n trivy-system
kubectl describe configmap trivy-operator-config -n trivy-system
kubectl rollout restart deployment trivy-operator -n trivy-system
helm list -A
