Best practices in regards to CI pipeline

[dlux95]

Hi,

first of all i would like to thank all contributors for this awesome project! Keep up the good work!

I am currently struggeling to implement Dependency-Track into my CI/CD pipeline because there are some issues (i think mostly because i don't know how to do these things the "right way").
I wan't to achieve the following:

1. SBOMs are automaticly uploaded to a new project version every time a CI/CD pipeline runs (this one works already)
2. i find it really confusing that every version gets handled as it was a new project (regarding the audit results of vulnerabilities). An already suppressed vulnerability should not pop up again if nothing changes for the component (like component version, or hash, or something else).
3. Run these vulnerability scan possibly on releases only
4. Run license policy scan on every build (espacially on merge requests/pull requests)

The second one is really what i struggle with because i can't get my head around of how to handle the non-linearity in git and therefore the cloning and keeping of the audit trail as it is difficult to get the version of the preceding build (in the e.g. branch and not the time).

If you have some ideas i would be happy to discuss that further. Because i think this workflow is kind of a general one i would like to write a simple best practice guide for this situation and contribute it to the project.

BR
Daniel

[mendorf]

Hi, after reading through / opening some similar discussions I am sharing my findings here, these might not help you but provide a starting point for anyone else.

• Dependency Track version 5 seems to provide a solution to most issues in the future, however it is not yet GA.

• With version 4, others apparently worked around the current behaviour using these approaches:

  • Do not use the "autocreate projects" flag during BOM upload:

    • use only "latest" as a version string. This will prevent you from maintaining a versioned analysis history of your projects.

      I now only get the last pipeline run but at least it doesn't lose manually added license information for example ... Of course, this requires me to set up projects in DT first, then copy over the UUID. No auto-onboarding of new projects. (autoCreateProjects and project versions #3683)

    • clone projects to new versions and choose to keep analysis details.

      Cloning a project during the upload of a BOM is not supported. Autocreate will simply create a new project without carrying over any audit history. Use the /v1/project/clone API to clone a project. Cloning is performed asynchronously (Audit workflow and project version #1294)

      Make sure your clone request object contains includeAuditHistory: true (Need advice on DT usage: suppressing a vuln on multiple similar projects #1910)

      When cloning a project, there's an option to include audit decisions. No such option currently exist for policy decisions. (Take processed policy violations into account when adding new project version #1597)

      You might do something like this 1. Clone project (+wait for token) 2. upload BOM (+wait for token) 3. fetch results 4. delete project (Analyse only mode - Upload BOMs without creating new projects/versions #3344)

  • Leverage VEX, adding a custom CLI around DT REST API. That CLI has an upload command that takes a SBOM parameter and optionally a VEX parameter. If a VEX is supplied to that command, the CLI upload the SBOM, wait for the analysis to complete and then upload the VEX to the same project. ... company projects manage a VEX file at the root of their git repository so that it is versioned along with the related source code. (Need advice on DT usage: suppressing a vuln on multiple similar projects #1910)

  • Integrate https://github.com/nscuro/dtapac (How may I supress one vulnerability for 100 projects? #2995)

Always keen to read from others about their journey with DT, so please everyone share your experience + other possible solutions here!