Refactor to support multiple CWEs #1467
Comments
stevespringett
added
enhancement
…ng change on Finding API. Updated docs. Updated CPE spec to v4.6 Signed-off-by: Steve Springett <steve@springett.us>
|
@stevespringett, may I ask you to not add a breaking change to the API for this? You could leave the existing elements and let them return the values of the first entry of the list of CWEs while And isn't the API supposed to be versioned by its URI (based on that "v1" in the URI)? If so, adding breaking changes would not be permitted. |
|
@sephiroth-j That's a valid concern. I opened a PR #1633 that addresses this by including a |
… in API objects and notifications Addresses concerns with 3rd party integrations, e.g. DependencyTrack#1467 (comment) Signed-off-by: nscuro <nscuro@protonmail.com>
|
@nscuro , thank you but the fields where previously named |
|
@sephiroth-j Good catch! Fix is underway. |
Dependency Track upgraded the export of results format in order to follow the relevant updated FPF format, so now multiple CWEs are included into to the vulnerabilities export. For information visit their release log https://docs.dependencytrack.org/changelog/ version 4.5.0 . In order to not change their API and relevant integrations (such as DefectDojo) they created a work around. So, in case there are multiple CWEs in a single finding they would always use the first one in the list (under the same JSON objects "cweId"and "cweName"), while the total count of CWEs and relevant information will be available in a new array. For more information DependencyTrack/dependency-track#1467 (comment). Close old findings and deduplication features breaks since findings with multiple CWEs may include a different CWE than the one used in order to calculate the original hash (due to the new CWE holding the first place in the array). Based on the above I would propose to change the "HASHCODE_FIELDS_PER_SCANNER" for "Dependency Track Finding Packaging Format (FPF) Export" in order to not include CWE by default.
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The enhancement may already be reported! Please search for the enhancement before creating one.
Current Behavior:
Only a single CWE can be specified for a vulnerability. This design decision was based on legacy implementation detail from the NVD.
Proposed Behavior:
Add support for an array of CWEs per vulnerability. This will be a breaking change for the vulnerability REST APIs and notifications.
Related to #96
The text was updated successfully, but these errors were encountered: