Vulnerability policies should have a priority

[nscuro]

It is totally possible that multiple vulnerability policies match for any given finding.

For each finding, there can only be a single applicable analysis. Even though multiple policies matched, only one of them can take effect.

Dependency-Track has no way of knowing which of them to pick. We thus need a way to prioritize policies, such that Dependency-Track can make a sensible decision in such cases.

I propose to:

• Extend the vulnerability policy schema with a mandatory priority field
• The field should be an unsigned integer
• A lower number indicates higher priority (0 is highest)
• Extend implementation(s) of VulnerabilityPolicyProvider such that applicable policies are returned in order of priority (descending)

An open question is how we deal with situations where multiple matched rules have the same priority.
Possible solutions:

• Enforce uniqueness of priority values across all policies
  • ✅ Deterministic
  • ✅ Easy to do in code, straightforward to implement
  • ❌ Complicated to manage for humans
  • ❌ Not assertable with JSON schema alone on a file-by-file basis
• Simply use the "oldest" policy (lower database ID, earliest createdAt timestamp, ...)
  • ✅ Easy to do in code, straightforward to implement
  • ✅ No necessary actions for humans
  • ❌ Not necessarily deterministic
    • createdAt is optional in the schema
    • Database ID can differ across systems

Other / better solutions to be discussed...

[skhokhlov]

Extend the vulnerability policy schema with a mandatory priority field

Maybe it's better to have this field optional with some default value like 100? Otherwise it can overcomplicate policies. Plus this field won't solve issue when multiply policies with similar conditions were created unintentionally. So I think DT should use both of mentioned solutions. Also it should mention in audit log that there was a conflict between policies and how it was solved