OWASP scores should be per-component, not global, to support contextual VEX ratings

[fahedouch]

Current Behavior

After merging CycloneDX/specification#722, I'm working on importing OWASP Risk Rating scores from CycloneDX VEX into Dependency-Track.

I've identified an architectural challenge: OWASP scores are currently stored at the Vulnerability level (global), not at the Component level. This seems inconsistent with how VEX Analysis states work, which are stored per component-vulnerability pair.

This means:

• One CVE has one OWASP score shared across all projects/components
• Cannot store different OWASP scores for the same vulnerability in different contexts

Proposed Behavior

OWASP scores should be moved to the Analysis level (component-vulnerability scope) to properly support context-aware risk assessments from VEX.

Why this is needed:

OWASP Risk Rating methodology is context-dependent. The same CVE can have different risk scores in different applications based on:

• System exposure (internet-facing vs internal)
• Data sensitivity
• Business criticality
• Security controls in place

Benefits:

• ✅ Aligns OWASP scoring with the CycloneDX VEX specification
• ✅ Enables proper import of tools like VENS that generate contextual OWASP scores per project
• ✅ Consistent with existing Analysis architecture
• ✅ Supports context-aware risk assessments per project/component

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

Rating have already been added to Analysis in v5: https://github.com/DependencyTrack/hyades-apiserver/blob/480e5b5e6a4e35fe246348ea7f28c3ab327a4660/apiserver/src/main/java/org/dependencytrack/model/Analysis.java#L106-L153

This was done for CVSS and OWASP scores, and it effectively acts as an override of the global ratings. Currently only the vulnerability policy feature populates these fields.

If we want to extend this to also be used by VEX (which I agree we should), then what's missing is a proper distinction as to who / what applied the assessments. That is, if a rating was applied via VEX, do we want users to modify it manually? And if a rating was applied via policy, do we want VEX to be able to overwrite it, and vice versa?

[fahedouch]

Rating have already been added to Analysis in v5: https://github.com/DependencyTrack/hyades-apiserver/blob/480e5b5e6a4e35fe246348ea7f28c3ab327a4660/apiserver/src/main/java/org/dependencytrack/model/Analysis.java#L106-L153

Excellent news! The feature already exists in v5! 🎉

Thanks for the pointer! I'll work on the hyades-apiserver repository then.

If we want to extend this to also be used by VEX (which I agree we should), then what's missing is a proper distinction as to who / what applied the assessments. That is, if a rating was applied via VEX, do we want users to modify it manually? And if a rating was applied via policy, do we want VEX to be able to overwrite it, and vice versa?

IMHO, the solution is implementing a source tracking to avoid override conflicts, I suggest adding a ratingSource field to track the origin of ratings with precedence rules:

1. MANUAL: Security analyst manually overrides score to 9.0 after incident investigation
2. VEX: Import VEX with OWASP score 7.2 based on app context (internet-facing, handles PII)
3. POLICY: Organizational rule sets all SQLi vulns to 8.0 minimum
4. Default: NVD global CVSS score 5.3

Happy to contribute a PR for the VEX import integration in https://github.com/DependencyTrack/hyades if this approach works.

[nscuro]

@fahedouch A source tracking system should work. But we then also need to define which source is overwritable by which other source.

e.g. we likely want MANUAL to be overwritable by VEX and POLICY, but we presumably would not want POLICY to be overwritable by MANUAL (it currently is, but it shouldn't).

[fahedouch]

Hi @nscuro
Before I start implementing this, I wanted to get your input on the approach.
Should I start with a v4 implementation first to validate the idea and source tracking system? My concern is that going straight to Hyades means the feature won't be usable in production for a while, and we're already getting requests in vens for importing risk scores into Dependency-Track.
What do you think - v4 first, or straight to Hyades?

[fahedouch]

But we then also need to define which source is overwritable by which other source.

How should we proceed with defining the source hierarchy? Should I propose an implementation in a PR that we can refine iteratively?

[nscuro]

@fahedouch I think the data model should be almost if not entirely identical between v4 and v5. If you raise a PR for v4 it just means additional work for us to port it to v5, which tbh I would love to avoid. However, if this is a small to medium sized change, it should be fine.

Should I propose an implementation in a PR that we can refine iteratively?

Please just go ahead and either propose a possible design or even an implementation, whatever you see fit.