How to actually integrate DT with a CI/CD setup?

[jakub-bochenski]

There isn't much information about running DT in a CI/CD setup.

What I found is:

• Analyse only mode - Upload BOMs without creating new projects/versions #3344 (reply in thread)
• Need advice on DT usage: suppressing a vuln on multiple similar projects #1910 (reply in thread)
• https://devsec-blog.com/2024/03/a-practical-approach-to-sbom-in-ci-cd-part-iii-tracking-sboms-with-dependency-track/

Which doesn't really help.

When I say CI/CD I mean a setup when each commit to master is potentially releasable.
I want the SBOM produced during the build to be the source of truth for the components in DT.

This seems to cause problems with DT, as each version is a separate project.

[jakub-bochenski]

It seems that maybe using aggregation projects could make the situation better, e.g. aggegating only latestVersion?

[jakub-bochenski]

You can make parent projects that aggregate metrics only from latest version or from certain tags.

PROS:

• can see the aggregated metrics

CONS:

• project can have only one parent, so you can't include it in multiple aggregates (e.g. if you have multiple production deployments)
• there seems to be no direct way to see which projects are included in the aggregation (e.g. the collection project details shows you all included projects, there is not option to filter only the ones used in aggregation)

Note: setting "latest version" on a project automatically unset it on all other versions.
If you would like to use tags instead then you have to tag the new project as "production" and untag the previous one(s). This is likely to create problems as there are no transactions, so if the process is aborted you end up with inconsistent state.

[jakub-bochenski]

I've seen people mentioning that Hyades is supposed to make things easier for such a setup, but I see no mention of it in the README

[jakub-bochenski]

Another approach would be to deactivate/delete the old versions. This requires an external cron etc, but looks relatively simple to do.

[jakub-bochenski]

a kind of "SNAPSHOT" version representing the main/master branch and specific versions for releases. Additionally, when a specific version goes into production, some housekeeping is done: all active previous versions (according to semantic versioning) are marked as inactive.

This is one approach proposed here: jenkinsci/dependency-track-plugin#329 (comment)

PROS:

• can fine-tune the logic to your requirements

CONS:

• setup is more complicated with the external houskeeping process
• houskeeping logic can be buggy

[jakub-bochenski]

There is another approach: jenkinsci/dependency-track-plugin#142 (comment)

• find project by name
• if exist get the uuid -> upload the bom -> patch the version of the project
• if not exist upload the bom with project name, project version and create project set to true

PROS:

• similar to using "stage as version", but version information is included in D-T

CONS:

• more complex, as you have to do additional API calls on each BOM upload

[jakub-bochenski]

Using "metaversions" or "stage as version" (production, staging, testing, etc.) seems to be the simplest approach. Inspired by this screenshot in documentation:

PROS:

• easy to setup
• can clearly see what is deployed to which stage

CONS:

• there is no actual version information in D-T, you can only see how things changed on various stages (which might not be that much of a problem in a CD setup)

[arjavdongaonkar]

Another Approach: Single Project per Microservice + Dual-Mode Scanning

In a microservice architecture, we maintain one DT project per microservice rather than creating a new project/version for every build.

Workflow:

1. Pre-Production (Prod-Candidate) Builds

   • When a pre-production (release candidate) build is triggered in CD, the pipeline:

     1. Generates an SBOM for the build
     2. Publishes it to DT (against the single, fixed project for that service)
     3. Waits for processing to complete
     4. Fails or passes the build based on DT policy violation results

2. All Other Builds (PR / Staging)

   • Do not publish to DT to avoid cluttering projects and versions

   • Instead:

     1. Fetch existing DT data for the project
     2. Compare DT’s findings against Trivy scan results
     3. Classify vulnerabilities as new, existing, suppressed, or resolved
     4. Run a lightweight, in-house policy engine to determine policy violations in PRs/staging

   • This gives developers visibility on vulnerabilities early, without polluting DT with non-production data

Benefits:

• DT remains clean, showing only production security posture
• PRs and staging builds still get full vulnerability visibility and suppression context
• Single source of truth for suppressions in DT
• Avoids flooding DT with hundreds of transient project versions
• Policy enforcement ensures vulnerable code never reaches production

Cons:

• added Complexity for policy checks and policy engine outside DT
• DT project view does not reflect non-production SBOMs, so no full historical view in DT itself

[jakub-bochenski]

Thanks for this suggestion.
I'd add the need to implement in-house policy engine as another "con". You might've meant that with "for policy checks outside DT" (looks like the begging of the sentence is cut?).

I was also considering just running a second D-T instance and do all-non production runs against it. I think it would have similar effects to what you describe

[arjavdongaonkar]

Thanks, Updated the comment