New Analysis State: UPDATE

[msymons]

Current Behavior:

Dependency-Track v3.4.1 (and 3.5.0-SNAPHOT) offers the following Audit Analysis states:

State	Description
EXPLOITABLE	The finding is exploitable (or likely exploitable)
IN_TRIAGE	An investigation is in progress to determine if the finding is accurate and affects the project or component
FALSE_POSITIVE	The finding was identified through faulty logic or data (i.e. misidentified component or incorrect vulnerability intelligence)
NOT_AFFECTED	The finding is a true positive, but the project is not affected by the vulnerability identified
NOT_SET	Analysis of the finding has not commenced

These states do not cover the situation where auditing has been performed and it has been determined that updating the component will resolve the vulnerability.

Proposed Behavior:

Create an additional Analysis State:

State	Description
UPDATE	This finding is a true positive and can be resolved via upgrading the version used.

Thus, in a multi-project system with (say) 1000 vulnerabilties and 200 triaged to to have status UPDATE, one has a better indication on where to start with fixing things.

Having an UPDATE status might also allow for additional "hint" functionality to be incorporated (something that I will log separately).

[msymons]

Another use case: At such time that Issue Tracking (eg JIRA) might be added to DT, then it would be useful to know when vulnerability has status UNKNOWN and there is no linked issue.

[stevespringett]

Thanks for the suggestion. I would rather UPDATE be part of a new audit field. Perhaps called 'Remediation Guidance' or 'Risk Response'.

For example, an audit state may be EXPLOITABLE and the remediation guidance is to UPDATE.

Possible values may include:

Response	Description
ACCEPT	Accept risk. No further action required.
BACKPORT	Merge in the fixes from a newer version to the older one. Useful for when there's a major version change in the affected component and upgrading introduces too much risk
DISCONTINUE	Refactor code to no longer use the affected component. This may occur if a component has or will be blacklisted, or the component is defined in the manifest but is no longer used by the application
NOT_SET	No remediation guidance provided
UPDATE	Update the component to the latest version or to the next unaffected version

This would also allow you to mark an audit state as NOT_AFFECTED and still have remediation guidance of UPDATE. If pushed to JIRA, the dev team would be able to prioritize UPDATEs where it's EXPLOITABLE over the tickets that are NOT_AFFECTED.

Thoughts?

[stevespringett]

I think ACCEPT would need its own permission however.

[msymons]

I think that it's spot-on to have UPDATE as part of a new audit field.

Bear in mind that UPDATE might also be a guidance that is applicable for components that have no threats at all. They are just not up to date. ie, applying the OWASP Component Analysis guidance on age.

DISCONTINUE is something that I would want to use for multiple components which are no longer maintained.

Aside: my BOM files currently exclude all components with scope "test" but I want to track them in DT... I know that there is a LOT of seroiusly out-of-date stuff there. This is where I am hoping that CycloneDX v1.1 will be able to help...allowing all components to be uploaded and the DT takes care of differentiating the scope.

[stevespringett]

If there isn't already an enhancement request for it, please create a new ticket that is specific to filtering components/dependencies based on their scope as well as their type (application, library, framework, device, etc). I may have a need for similar use-cases in my own environment.

[msymons]

I have been thinking further about responses for 'Remediation Guidance' and reckon that UPDATE does not quite cover all bases. Would find this more useful:

• UDATE_NOW: This can be used when a fixed version is available and (when using DT Jenkins plugin), one might want builds to fail.
• UPDATE_ASAP: This can be used when a fix version is not currently available but is expected, In this scenario, might want to have builds marked unstable. One would certainly want to frequently seek all UPDATE_ASAP in DT and perform a re-audit.

[stevespringett]

I can also see the logic of _NOW and _ASAP applying to discontinue and backport. Both terms are a bit ambiguous, ASAP being much more so.

I think we can accomplish what you want one of two ways.

1) Along with the 'Remediation Guidance' field, have a 'Status' field. The possible values of the status field would be 'Required' or 'Recommended'. So you could have a remediation guidance set to 'update' and the status set to 'recommended' and the build could be put in a warning state. Or if the status is required, them the build would be in a failed state.

2) Along with the 'Remediation Guidance' field, have a 'Priority' field. Possible values of the priority field would be high, medium, and low. So an 'update' with medium or low priority may result in a warning build whereas a high priority may result in a failed build.

Regardless of the approach taken, either the 'status' or 'priority' field could be used in conjunction with any value in the remediation guidance, including discontinue and backport.

[jensenv]

We would love if there was a way to indicate likelihood of an exploit being used in our software. Either something like:

1) Not Affected 2) Exploitable; likely to occur during normal use 3) Exploitable; could occur during lifetime of software 4) Exploitable; not likely to occur

Or, a new 'Likelihood' menu could be done separately from the Analysis State if that is seen as a better approach. (But this menu should be selectable/visible only if the current Analysis State is Exploitable or In Triage.)