Audit workflow and project version

[adambir]

Hello,

I'm discovering the tool and I am not sure how auditing workflow could be used in my case. Is it right that auditing has to be done again for every vulnerability, for every version of my applications ? If I suppress a vulnerability for my application, or set it as NOT IMPACTED, it the audit choice won't be rolled out to the next version of the application ?

Also, the total risk score of my company will keep on increasing for every version released, as they stack, right ? What is the good practice ? Set the old version of my applications as inactive manually on a regular basis ?

Regards,
Adam

[stevespringett]

Is it right that auditing has to be done again for every vulnerability, for every version of my applications ?

Auditing is optional. Many development and security teams like to triage findings to help prioritize what the team should fix. Prioritization based solely on the severity of findings leads to a lot of unnecessary work for many teams. This is especially useful for teams with time-boxed constraints. But, auditing is completely optional.

If I suppress a vulnerability for my application, or set it as NOT IMPACTED, it the audit choice won't be rolled out to the next version of the application ?

Assuming you want individual projects in DT for each of version of your application (e.g. 1.0, 2.0, etc), then audit trails carry over when the project is cloned. If you clone project 1.0 creating 2.0, then the inventory, audit decisions, etc will also be cloned. If you do not clone and simply create a new 2.0 project, then no historical data is carried over.

Also, the total risk score of my company will keep on increasing for every version released, as they stack, right ?

Depends. Findings that are suppressed will not increase risk score. Findings that are not suppressed will.

Set the old version of my applications as inactive manually on a regular basis ?

Inactive states are for projects where you want to maintain history of something, but does not affect actual risk to the organization. For example, if 3.0 of an application is what is supported or in production and all prior releases are not supported or not in production, then it's recommended to mark 1.0 and 2.0 as inactive as they represent no risk to the organization. Inactive projects will also not be scanned in the future - so there are positive performance reasons for using the inactive state as well.

See also:

• https://docs.dependencytrack.org/triage/auditing-basics/
• https://docs.dependencytrack.org/triage/analysis-states/
• https://docs.dependencytrack.org/triage/suppression/

[adambir]

Thanks for the answer.

I think I am doing something wrong with my workflow, because I did some auditing on version 2.0.1 and it did not carry over to 2.0.2. How do you clone a project vs create a new one ?

Right now I'm using that syntax in a Jenkinsfile :

stage("Publish SBOM") {
      def pomModel = readMavenPom()
      dependencyTrackPublisher artifact: 'target/bom.xml', projectName: pomModel.artifactId, projectVersion: pomModel.version, synchronous: true
}

I also have auto create on.

The other way to updload the bom is to use projectId (that would require a little more manual actions) but it also means that the version would not be updated ?

[stevespringett]

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 and is not guaranteed to take place the moment the request comes in. Asynchronous tasks are placed in a FIFO queue and processed across all CPU cores. The more CPU/RAM you have on the server, and the less busy it is, the more likely it is that cloning will be immediate.

[adambir]

In the end, what I did was

stage("Publish SBOM") {
      def pomModel = readMavenPom()
      dependencyTrackPublisher artifact: 'target/bom.xml', projectName: pomModel.artifactId, projectVersion: 'CURRENT', synchronous: true
}

When uploading on the same version, it just overiddes it and keeps the history of the previous analysis etc. It is good enough for me.