Could DT support an optional vulnerability occurrence count when calculating project and portfolio metrics?

[wataltera]

DT rolls up component vulnerabilities to calculate project risk. Could DT also support vulnerability occurrence counts?

DDT treat each vulnerability "affects" record as a single finding when calculating project and portfolio metrics.

This works well for CVEs, but some vulnerability types may occur many times in a component:

SAST findings
Secret scanning results
IaC findings
DAST findings
Misconfigurations
Code quality/security-quality findings

For example, a SAST tool might find 10 occurrences of SQL Injection in a component. This is one vulnerability type (SQL Injection / CWE-89) but 10 findings that must be remediated.

Our VEX representation associates the vulnerability with a component and stores the number of findings as a property:

"affects": [
{
"ref": "pkg:nuget/dimpoc@1.0.0"
"properties": [
{
"name": "dt:occurrence-count",
"value": "10"
}
]
}
]

Could DT support an optional occurrence count when calculating project and portfolio metrics?

We don't want to turn DT into a SAST platform. Information such as filenames, line numbers, traces, sinks, sources, and guidance would stay in external tooling. DT would be the aggregation and prioritization layer.

We use DT's project hierarchy to generate enterprise, business-unit, product, and sub-product risk reports. In that context, occurrence counts would provide a more accurate measure of remediation effort and residual risk than the current assumption that every vulnerability record represents a single finding.

Is there an existing extension point for this, or would support for occurrence-aware metrics require major changes to DT's aggregation logic?