[Feature] Dependency-Track Integration for Continuous SBOM & Vulnerability Management

[Nitr4x]

Summary

Integrate ScopeGuardian with OWASP Dependency-Track to enable
continuous, centralised SBOM ingestion and vulnerability tracking. After each scan, the
generated SBOM should be automatically uploaded to a configured Dependency-Track instance,
providing a persistent, queryable record of component inventory and policy violations over time.

Problem / Motivation

ScopeGuardian currently produces point-in-time scan results (e.g., sbom.syft.json,
grype-result.json) stored as files. Teams that need to:

• Track vulnerability trends across multiple projects and over time.
• Enforce organisational policies (e.g., "no Critical CVEs in production images").
• Maintain an auditable, centralised component inventory for compliance (SOC 2, ISO 27001).

...have no way to do so within ScopeGuardian today. Dependency-Track solves exactly this
problem: it ingests CycloneDX SBOMs, enriches them with vulnerability data from multiple
sources (NVD, OSV, GitHub Advisories, etc.), and provides a dashboard, REST API, and
policy engine.

Proposed Solution

Add an optional post-scan upload step that sends the CycloneDX SBOM produced by Syft to a
Dependency-Track instance via its REST API.

Configuration

Extend loader/dto.go with a new DependencyTrack block:

dependency_track:
  enabled: true
  url: "https://dtrack.example.com"
  api_key: "${DT_API_KEY}"
  project_name: "my-service"
  project_version: "1.0.0"
  auto_create: true

Upload service

Add a new package features/integrations/dependencytrack/ that:

• Reads SCAN_DIR/results/sbom.syft.json (CycloneDX format).
• Calls the Dependency-Track PUT /api/v1/bom endpoint to upload the SBOM.
• Returns a project URL for display in scan output.

Engine wiring

Register the upload as a post-scanner step in engine/engine.go that runs only after
both Syft and Grype have completed successfully, consistent with the existing
prerequisites/scanners execution model.

Error handling

Treat upload failures as warnings (not errors) so a Dependency-Track outage does not
block the primary scan workflow.

Key API endpoints

Method	Endpoint	Purpose
PUT	/api/v1/bom	Upload CycloneDX SBOM
GET	/api/v1/project	Look up existing project
PUT	/api/v1/project	Create project if auto_create is enabled

Alternatives Considered

• Grype DB / local vulnerability DB only: Works for point-in-time checks but provides
  no historical tracking, policy enforcement, or multi-project aggregation.
• DefectDojo: Broader scope (supports many scanner formats) but less SBOM-native and
  more complex to operate than Dependency-Track.
• Manual SBOM archiving: Storing SBOMs as CI artefacts gives auditability but no
  automated vulnerability enrichment or policy evaluation.

Additional Context

• Dependency-Track: https://dependencytrack.org/
• Dependency-Track REST API: https://docs.dependencytrack.org/integrations/rest-api/
• Dependency-Track is an OWASP flagship project, widely used and actively maintained.
• The SBOM produced by Syft in CycloneDX format is directly compatible with
  Dependency-Track's ingestion pipeline.
• API key should be read from an environment variable to avoid secrets in config files.
• Grype scan package reference: features/scans/grype/ (service, factory, const, dto).
• Engine execution model reference: engine/engine.go.