# Additional properties in CycloneDX-json Grype output

**URL:** <https://anchorecommunity.discourse.group/t/additional-properties-in-cyclonedx-json-grype-output/652>\
**Category:** General\
**Created:** [June 15, 2026, 12:19pm UTC](https://anchorecommunity.discourse.group/t/additional-properties-in-cyclonedx-json-grype-output/652 "2026-06-15T12:19:03Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![staticnoise](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/staticnoise/32/202_2.png) [@staticnoise](https://anchorecommunity.discourse.group/u/staticnoise)\
**Post date:** [June 17, 2026, 10:11am UTC](https://anchorecommunity.discourse.group/t/additional-properties-in-cyclonedx-json-grype-output/652/3 "2026-06-17T10:11:26Z")

</div>

Adding vulnerable ranges would work. Following the standardized SBOM fields is a better approach than adding custom properties. The ranges should be specific to a given package on a given software distribution (e.g. Debian 10), so I don’t expect there to be more than one vulnerable range in most situations.

I specifically asked about direct/indirect match to separate direct matches from matches based on the upstream package as [discussed here](https://anchorecommunity.discourse.group/t/indirect-matches-vulnerabilities-affecting-the-upstream-packages-are-sometimes-too-broad/523). It would help us to filter out matches with less confidence. We could stringify the whole match details object and put it into a single property to include everything, but I have only use case for that one specific field.

---

_[View the full topic](https://anchorecommunity.discourse.group/t/additional-properties-in-cyclonedx-json-grype-output/652)._