Dependency-Track - Continuous SBOM Analysis Cheatsheet
Dependency-Track (an OWASP flagship project) is a platform for continuous software supply chain risk management. Its defining idea: instead of scanning your dependencies once at build time, you upload a CycloneDX SBOM per project and the platform continuously re-evaluates those components as new vulnerabilities are disclosed. When a CVE drops, you immediately know which of your applications contain the affected component — without rebuilding or rescanning anything.
Deployment
| Method | Command |
|---|
| Docker Compose | curl -LO https://dependencytrack.org/docker-compose.yml && docker compose up -d |
| Container (API) | docker run -p 8081:8080 dependencytrack/apiserver |
| Frontend | dependencytrack/frontend container (default UI on 8080) |
| Kubernetes | Helm chart available |
| Requirements | ~4GB+ RAM; PostgreSQL for production |
Core Concepts
| Term | Meaning |
|---|
| Project | An application/service you track |
| Component | A dependency within a project |
| SBOM | CycloneDX bill of materials you upload |
| Vulnerability | A CVE/advisory affecting a component |
| Policy | Rules that gate risk (license, severity, age) |
| Portfolio | All projects, aggregated |
Uploading an SBOM
Generate with Syft or cyclonedx-* tooling, then upload via API:
# Generate a CycloneDX SBOM
syft dir:. -o cyclonedx-json > bom.json
# Upload to Dependency-Track
curl -X POST "http://localhost:8081/api/v1/bom" \
-H "X-Api-Key: $DT_API_KEY" \
-F "project=$PROJECT_UUID" \
-F "bom=@bom.json"
| Endpoint | Purpose |
|---|
POST /api/v1/bom | Upload an SBOM |
GET /api/v1/project | List projects |
PUT /api/v1/project | Create a project |
GET /api/v1/vulnerability/project/{uuid} | Vulnerabilities for a project |
GET /api/v1/metrics/project/{uuid}/current | Current risk metrics |
Vulnerability Intelligence Sources
| Source | Provides |
|---|
| NVD | CVE data |
| GitHub Advisories | Ecosystem-specific advisories |
| OSV | Open Source Vulnerabilities database |
| VulnDB | Commercial (optional) |
| Internal | Your own advisories |
The platform mirrors these feeds and re-analyzes every stored component against them on a schedule.
Policy Engine
| Policy condition | Example |
|---|
| Severity | Fail if any CRITICAL vulnerability |
| License | Block GPL in proprietary products |
| Component age | Flag dependencies unmaintained for N years |
| Coordinates | Ban a specific package/version |
| CWE | Flag specific weakness classes |
Policies produce violations that appear alongside vulnerabilities, so license and hygiene risk are tracked in the same place.
CI/CD Integration
# In a pipeline: build → generate SBOM → upload → gate
syft dir:. -o cyclonedx-json > bom.json
curl -X POST "$DT_URL/api/v1/bom" -H "X-Api-Key: $DT_API_KEY" \
-F "project=$PROJECT_UUID" -F "bom=@bom.json"
# Poll for the analysis result and fail on policy violations
| Integration | Note |
|---|
| Jenkins/GitHub Actions | Official plugins/actions available |
| Webhooks | Notify Slack/Teams/Jira on new findings |
| VEX | Record exploitability decisions (not affected, etc.) |
Triage & VEX
| Action | Meaning |
|---|
| Not Affected | Vulnerable code path is not reachable |
| False Positive | Detection is wrong |
| Resolved | Fixed in this project |
| Suppressed | Accepted risk with justification |
Recording these as VEX keeps the noise down and documents decisions for auditors.
Dependency-Track vs Point Scanners
| Aspect | Dependency-Track | Grype/Trivy | Socket |
|---|
| Model | Continuous SBOM platform | Point-in-time scan | Behavioral malware detection |
| Re-evaluation | Automatic on new CVEs | Only when you rerun | On dependency changes |
| Portfolio view | Yes (all projects) | Per-scan | Per-PR |
| Best for | Org-wide supply chain risk | CI scanning | Malicious package detection |
Feed it SBOMs from Syft; pair with Grype for build-time scanning and Socket for malicious-package detection.
Resources
