What would you like to be added:
Include matchDetails object in the CycloneDX output format as well.
matchDetails object example
"matchDetails": [
{
"type": "exact-indirect-match",
"matcher": "rpm-matcher",
"searchedBy": {
"distro": {
"type": "fedora",
"version": "23"
},
"package": {
"name": "krb5",
"version": "1.14.1-6.fc23"
},
"namespace": "fedora:distro:fedora:23"
},
"found": {
"vulnerabilityID": "CVE-2016-3120",
"versionConstraint": "< 0:1.14.3-8.fc23||< 0:1.14.3-4.fc23 (rpm)"
},
"fix": {
"suggestedVersion": "0:1.14.3-4.fc23"
}
}
]Why is this needed:
Match details include important information about the match, including type of the match. Marking package as vulnerable based on a CVE issued to an upstream package may result in false positives and less confidence. Including information about direct/indirect match would allow consumers to understand how the match was made and avoid false positives.
Additional context:
The match details object is already part of the json format so I recon it's part of a public stable API. As such I don't see a reason to not include it in the CycloneDX format as well. CycloneDX allows setting custom properties for each vulnerability finding (see spec). Because only string values are allowed, I propose stringifying the matchDetails object. Syft already makes use of proterties to store syft:package:type.
Although I have only use case for the match type, I don't see a reason to not include the whole object.
Previously discussed on Discourse: Additional properties in CycloneDX-json Grype output
What would you like to be added:
Include matchDetails object in the CycloneDX output format as well.
matchDetails object example
Why is this needed:
Match details include important information about the match, including type of the match. Marking package as vulnerable based on a CVE issued to an upstream package may result in false positives and less confidence. Including information about direct/indirect match would allow consumers to understand how the match was made and avoid false positives.
Additional context:
The match details object is already part of the json format so I recon it's part of a public stable API. As such I don't see a reason to not include it in the CycloneDX format as well. CycloneDX allows setting custom properties for each vulnerability finding (see spec). Because only string values are allowed, I propose stringifying the matchDetails object. Syft already makes use of proterties to store
syft:package:type.Although I have only use case for the match type, I don't see a reason to not include the whole object.
Previously discussed on Discourse: Additional properties in CycloneDX-json Grype output