Deployment guide

Dependency-Track

Overview

Dependency-Track is the OWASP flagship platform for software supply chain component analysis. You upload a CycloneDX SBOM (Software Bill of Materials) for each project you ship. Dependency-Track keeps an always-current inventory of every component in that software and continuously re-evaluates it against vulnerability intelligence as new advisories are published.

Rather than telling you what was vulnerable the day you scanned, it tells you what is vulnerable now. This is why teams use it to run software supply chain risk programmes across large portfolios.

The SecureAnyCloud image installs the official Dependency-Track 5.0.2 API server distribution and the official frontend single-page application. Both are verified against the upstream release SHA256 checksums at build time. The API server runs under a dedicated non-root dtrack service user on the OpenJDK 25 JRE. nginx sits in front as the only public listener: it serves the frontend on port 80 and reverse-proxies /api to the API server.

A local PostgreSQL is the backing store, because Dependency-Track 5.x requires PostgreSQL and no longer supports an embedded database.

Dependency-Track seeds a well-known default admin / admin account. On the first boot of every deployed VM, the image rotates that password to a unique per-VM value, verifies the rotation, and confirms the default credential is rejected before the VM is handed over. The result is written to /root/dependency-track-credentials.txt with mode 0600, so no two VMs share credentials and the shipped default is never usable.

What you get:

Dependency-Track 5.0.2 API server (/opt/dependency-track) on the OpenJDK 25 JRE, run as the non-root dtrack user
The official Dependency-Track frontend SPA served by nginx on :80, with /api reverse-proxied to the API server and an unauthenticated /health endpoint
PostgreSQL 16 as the backing database, bound to loopback only
A dedicated 40 GiB Azure data disk at /var/lib/dependency-track holding the API server data directory and the PostgreSQL datadir, separate from the OS disk and re-provisioned with every VM
An nftables ruleset keeping the API server port 8080 and the management port 9000 off the public interface, so nginx on :80 is the only way in
Telemetry submission disabled by default
JVM heap sized automatically at first boot from the VM's actual memory
Per-VM admin password, rotated at first boot, in a root-only file
dependency-track.service, postgresql.service, nginx.service and nftables.service as systemd units, enabled and active
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended starting size. The API server JVM, its analysis workers and PostgreSQL share the VM, and vulnerability database mirroring is memory- and IO-hungry.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp from the networks your users and CI runners reach Dependency-Track on. For public exposure, front port 80 with TLS (see Enabling HTTPS).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Dependency-Track by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

First boot initialisation takes approximately three to five minutes after the VM starts. During this time Dependency-Track runs its database migrations, seeds its default objects and rotates the admin password.

Step 2 - Deploy from the Azure CLI

az vm image terms accept --urn sac1647283583153:dependency-track-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-dependency-track \
  --image sac1647283583153:dependency-track-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-resource-group --name my-dependency-track --port 80

Step 3 - Connect to your VM

ssh azureuser@<vm-ip>

Step 4 - Confirm the services are running

systemctl is-active dependency-track.service postgresql.service nginx.service nftables.service curl -s -o /dev/null -w 'health: HTTP %{http_code}\n' http://127.0.0.1/health curl -s http://127.0.0.1/api/version

All four units report active, the health endpoint returns 200, and the version endpoint reports Dependency-Track 5.0.2.

Step 5 - Retrieve your administrator login

Every VM generates its own administrator password at first boot. The image rotates the shipped admin / admin default and then verifies that it is rejected, so it can never be used against your instance.

sudo cat /root/dependency-track-credentials.txt

sudo stat -c '%n mode=%a owner=%U:%G' /root/dependency-track-credentials.txt

The file is mode 600, is owned by root, and holds DTRACK_USERNAME and DTRACK_ADMIN_PASSWORD for this VM only.

Step 6 - First sign-in

Browse to http://<vm-ip>/ and sign in as admin with the password from Step 5.

You can also confirm the same credential over the API, and confirm that the shipped default is rejected:

PASS=$(sudo grep '^DTRACK_ADMIN_PASSWORD=' /root/dependency-track-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=$PASS")
curl -s -o /dev/null -w 'authenticated API call: HTTP %{http_code}\n' \
  -H "Authorization: Bearer $TOKEN" http://127.0.0.1/api/v1/team
curl -s -o /dev/null -w 'default admin/admin: HTTP %{http_code} (401 expected)\n' \
  -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=admin"

Step 7 - Upload your first SBOM

SBOMs drive Dependency-Track. Generate a CycloneDX SBOM for your project with a tool such as cyclonedx-npm, cyclonedx-maven-plugin or syft, then upload it.

The example below creates a small SBOM and uploads it, so you can see the whole path working end to end.

cat > /tmp/example-bom.json <<'BOM' { "bomFormat": "CycloneDX", "specVersion": "1.5", "version": 1, "components": [ {"type":"library","group":"org.apache.logging.log4j","name":"log4j-core","version":"2.14.1","purl":"pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"}, {"type":"library","name":"lodash","version":"4.17.15","purl":"pkg:npm/lodash@4.17.15"} ] } BOM
PASS=$(sudo grep '^DTRACK_ADMIN_PASSWORD=' /root/dependency-track-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=$PASS")
UPLOAD_TOKEN=$(jq -nc --arg b "$(base64 -w0 < /tmp/example-bom.json)" \
  '{projectName:"example-app", projectVersion:"1.0.0", autoCreate:true, bom:$b}' \
  | curl -s -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -X PUT http://127.0.0.1/api/v1/bom --data-binary @- | jq -r .token)
echo "upload token: $UPLOAD_TOKEN"

Processing is asynchronous. Poll until it completes, then confirm that the components were analysed:

PASS=$(sudo grep '^DTRACK_ADMIN_PASSWORD=' /root/dependency-track-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=$PASS")
PROJECT_UUID=$(curl -s -H "Authorization: Bearer $TOKEN" \
  --get --data-urlencode "name=example-app" --data-urlencode "version=1.0.0" \
  http://127.0.0.1/api/v1/project/lookup | jq -r .uuid)
curl -s -H "Authorization: Bearer $TOKEN" \
  "http://127.0.0.1/api/v1/component/project/$PROJECT_UUID?limit=20" \
  | jq -r '.[] | "\(.name) \(.version) \(.purl)"'

In the web interface the uploaded project appears under Projects, with its BOM format and last import time.

Step 8 - Review the analysed components

Open a project and choose Components to see every component Dependency-Track extracted from the SBOM, each with its Package URL. Dependency-Track evaluates every future advisory against this inventory.

Step 9 - Review vulnerabilities

Vulnerabilities shows the vulnerability intelligence Dependency-Track has mirrored. Vulnerability Audit is where you triage findings against your own projects.

Mirroring the full National Vulnerability Database on a new instance runs in the background and takes a while to complete after first boot. Findings against your projects populate as the mirror progresses.

Step 10 - Confirm the data tiers

findmnt -no SOURCE,TARGET,FSTYPE /var/lib/dependency-track
sudo -u postgres psql -tAc 'SHOW data_directory' grep '^DT_DATA_DIRECTORY=' /etc/dependency-track/dependency-track.env

Both the PostgreSQL datadir and the API server data directory sit on the dedicated Azure data disk. You can resize the disk independently, and it is separate from the OS disk.

sudo nft list table inet sac_dtrack

The ruleset keeps ports 8080 and 9000 off the public interface, so nginx on :80 is the only way in.

Enabling HTTPS

Dependency-Track handles SBOMs and vulnerability data for your software estate, so terminate TLS before you expose it beyond a trusted network.

Point a DNS record at the VM, then use certbot to obtain a certificate and update the nginx site:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d dependency-track.your-domain.com --redirect --agree-tos -m you@your-domain.com

Certbot rewrites /etc/nginx/sites-available/sac-dependency-track to listen on :443 with your certificate and redirects :80 to :443. The packaged systemd timer handles renewal.

Once TLS is in place, restrict 80/tcp and 443/tcp in the NSG to the networks that need access.

Backup and maintenance

Back up the backing database. It holds every project, SBOM inventory, finding and audit decision:

sudo -u postgres pg_dump -Fc dtrack > /var/tmp/dtrack-$(date +%F).dump ls -lh /var/tmp/dtrack-*.dump

Copy the dump off the VM, for example to Azure Blob Storage, or apply an Azure Backup policy to the data disk. Both the database and the API server data directory live on /var/lib/dependency-track, so a snapshot of that data disk captures the full application state.

Ubuntu's unattended-upgrades, which is enabled in the image, delivers operating system security updates. To upgrade Dependency-Track itself, follow the upstream release notes. The API server is a self-contained distribution in /opt, and the frontend is a static bundle served by nginx.

Support

SecureAnyCloud publishes and supports this image. For help with deployment or configuration, contact sales@secureanycloud.com. Product documentation for Dependency-Track is at docs.dependencytrack.org.

Deploy on Azure

Launch Dependency-Track on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

This image runs Dependency-Track, the OWASP software supply chain component analysis platform. Dependency-Track ingests CycloneDX Software Bills of Materials (SBOMs) for your applications and maintains a living inventory of every component they depend on. It continuously identifies known vulnerabilities, outdated libraries and policy violations as new intelligence arrives.

Instead of a point-in-time scan, it keeps a durable, queryable picture of software supply chain risk across every project in your portfolio.

The platform runs as a Java API server (on OpenJDK 25, which Dependency-Track 5.x requires) fronted by nginx as a reverse proxy. The single-page web application is served on port 80, and the API is reached through the same origin under /api. A PostgreSQL database holds the component inventory, findings and configuration.

The API server's main port (8080) and its management and metrics port (9000) are kept off the public interface. The management endpoint binds loopback only, and an nftables ruleset drops any external traffic to both ports, so nginx on port 80 is the only intended public listener.

The PostgreSQL data directory and the API server data directory both live on a dedicated EBS data volume mounted at /var/lib/dependency-track. The volume is independently resizable and separate from the operating system disk.

On the first boot of every deployed instance, a one-shot service rotates the well-known default admin account to a fresh per-instance password through the Dependency-Track API. It also rotates the PostgreSQL role password, and it verifies that the new credential works and that the default admin/admin no longer authenticates. It writes the login to /root/dependency-track-credentials.txt with mode 0600. No shared or default credentials ship in the image.

Prerequisites

Before you deploy this image, make sure you have:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and inbound ports 80 and 443 from the networks your developers and build agents will reach Dependency-Track on
The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Dependency-Track. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. The API server JVM (around a 4 GiB heap), its analysis workers and a local PostgreSQL share the instance, and vulnerability database mirroring is memory- and IO-hungry. m5.large is the minimum for this stack.

Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group. The group must allow inbound port 22 from your management network and inbound ports 80 and 443 from the networks your users use.

Leave the root volume at the default size or larger. The image adds a separate data volume for the database and API server storage automatically.

Select Launch instance. First boot initialisation runs before SSH becomes ready. On m5.large, the platform is serving within a couple of minutes of the instance reaching Running with its status checks passed.

Launch the Instance from the AWS CLI

The command below launches an instance from the SecureAnyCloud Dependency-Track Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22, 80 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=dependency-track-01}]'

The command prints a JSON document on success. Note the instance ID, then retrieve its public address once it is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect and Retrieve the Administrator Login

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched. For Dependency-Track 5.0 on Ubuntu 24.04, the login user is ubuntu.

The first-boot service runs before the SSH daemon becomes ready, so the credentials file is always in place when you log in for the first time.

ssh <login-user>@<public-ip>
sudo cat /root/dependency-track-credentials.txt

The file is plain text. It contains the sign-in URL, the administrator username (admin) and the per-instance password.

From the same SSH session, confirm that the deployment is healthy. nginx serves the open health endpoint, and the API reports its version through the same nginx proxy:

curl -s http://127.0.0.1/health
curl -s http://127.0.0.1/api/version

The health endpoint returns ok and the version endpoint returns a JSON document whose version field is the running Dependency-Track release.

First Sign-In to the Web UI

Open http://<public-ip>/ in your browser. The Dependency-Track sign-in screen appears. Sign in with the username admin and the per-instance password from /root/dependency-track-credentials.txt. First boot already rotated the default admin/admin credential, and it no longer works.

After you sign in, you land on the portfolio dashboard. It summarises portfolio vulnerabilities, projects at risk, vulnerable components and the inherited risk score across everything you have analysed. The dashboard is empty on a fresh instance until you upload your first SBOM.

Upload Your First SBOM

Dependency-Track builds its inventory from CycloneDX SBOMs. You can upload one through the web UI or through the API. In the web UI, choose Projects, then Create Project, then open the project's Components tab and choose Upload BOM.

The command below authenticates with the per-instance admin password, generates a session token, and uploads a small CycloneDX SBOM through the API. It auto-creates a project called my-first-app. Run it on the instance over SSH.

PW=$(sudo grep '^DTRACK_ADMIN_PASSWORD=' /root/dependency-track-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=$PW")
cat > /tmp/my-first-bom.json <<'BOM' { "bomFormat": "CycloneDX", "specVersion": "1.5", "version": 1, "components": [ { "type": "library", "group": "org.apache.logging.log4j", "name": "log4j-core", "version": "2.14.1", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" }, { "type": "library", "name": "lodash", "version": "4.17.15", "purl": "pkg:npm/lodash@4.17.15" } ] } BOM
B64=$(base64 -w0 < /tmp/my-first-bom.json) jq -nc --arg b "$B64" '{projectName:"my-first-app", projectVersion:"1.0.0", autoCreate:true, bom:$b}' \
  | curl -s -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -X PUT http://127.0.0.1/api/v1/bom --data-binary @-

The response contains a processing token. Dependency-Track processes the upload asynchronously. The next command waits for processing to finish, then confirms that the project and its analysed components exist.

PW=$(sudo grep '^DTRACK_ADMIN_PASSWORD=' /root/dependency-track-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1/api/v1/user/login \
  --data-urlencode "username=admin" --data-urlencode "password=$PW")
UUID=$(curl -s -H "Authorization: Bearer $TOKEN" \
  --get --data-urlencode "name=my-first-app" --data-urlencode "version=1.0.0" \
  http://127.0.0.1/api/v1/project/lookup | jq -r '.uuid')
echo "project uuid: $UUID" curl -s -H "Authorization: Bearer $TOKEN" \
  "http://127.0.0.1/api/v1/component/project/$UUID?limit=100" | jq 'length'

The project lookup returns a UUID, and the component count is the number of components in the SBOM. In the web UI, the same project now appears under Projects, showing its version, the CycloneDX BOM format, its risk score and its vulnerability count.

Open a project and select the Components tab to see the full dependency inventory built from the SBOM. Each component shows its version, group, licence and risk score. Buttons on the tab let you upload a new BOM or download the current one.

Enable Vulnerability Sources

A fresh instance has an empty vulnerability database. To have Dependency-Track match your components against known vulnerabilities, enable and mirror the vulnerability sources. Open Administration, then Vulnerability Sources, and enable sources such as the National Vulnerability Database, the GitHub Advisory Database and OSS Index.

Once a source is enabled and its initial mirror completes, Dependency-Track re-analyses your existing projects automatically and populates the vulnerability counts on the dashboard and project views.

The Administration area is also where you configure BOM formats, analyzers, repositories, notifications, integrations and access management.

Integrate SBOM Upload into Your Pipeline

The same PUT /api/v1/bom call you ran in step 5 is how you wire SBOM analysis into CI/CD. Generate a CycloneDX SBOM during your build, for example with the CycloneDX Maven, Gradle or npm plugins. Then upload it against a project keyed by name and version, so every release is analysed automatically.

For pipeline use, create a dedicated team with an API key under Administration, then Access Management. Send the key as the X-Api-Key header instead of an interactive session token, so your automation never uses the interactive admin password.

Add HTTPS with a Trusted Certificate

The image serves plain HTTP on port 80 so that it works immediately on launch. For any real deployment, put Dependency-Track behind HTTPS.

Point a DNS record at the instance and make sure inbound port 443 is open. Then install a certificate with certbot and the nginx plugin. Replace your-domain with your fully qualified hostname.

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain

certbot obtains a certificate, rewrites the nginx server block to listen on 443, and sets up automatic renewal.

After you enable HTTPS, open Administration, then Configuration, then General. Set the Base URL to your https:// URL so generated links and notifications use it.

Services, Storage and Maintenance

The stack runs under systemd. Check and control the services with these commands:

systemctl status dependency-track postgresql nginx

dependency-track.service is the API server, postgresql.service is the database, and nginx.service is the reverse proxy. The nftables.service ruleset keeps the API server and management ports off the public interface. Inspect it with sudo nft list table inet sac_dtrack.

The database and the API server data directory (vulnerability mirrors, local file storage and the secret-management key set) live on the dedicated EBS data volume mounted at /var/lib/dependency-track. Confirm the mount and its free space with:

df -h /var/lib/dependency-track

Because the data tier is a separate EBS volume, you can grow it independently of the operating system disk and snapshot it for backup. For a consistent database backup, run pg_dump of the dtrack database as the postgres user, or snapshot the EBS volume.

Keep the operating system patched with sudo apt-get update && sudo apt-get upgrade.

Support

SecureAnyCloud maintains this image and provides 24/7 technical support by email and chat.

We can help with deployment, SBOM ingestion, vulnerability source configuration, policy design, CI/CD integration, database and storage maintenance, and backup and upgrade planning. Contact sales@secureanycloud.com.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on AWS

Launch Dependency-Track on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS