When vuln-scan.sh merges Grype results into a CycloneDX SBOM, it places vulnerability data under a custom vulnerability_scan key. CycloneDX 1.4+ defines a standard top-level vulnerabilities array that spec-compliant consumers (SCA platforms, dependency dashboards, etc.) expect.
The recommended fix is to map Grype matches into the CycloneDX vulnerabilities schema (id, source, ratings, description, affects) and conditionally add the array when .bomFormat == "CycloneDX". The custom vulnerability_scan key can remain for Forge tooling.
This issue was deferred from a Copilot comment on PR #57. Field mapping between Grype JSON and CycloneDX vulnerabilities schema is (surprisingly) non-trivial, so warrants its own PR with testing against Grype output. In the meantime, having it there in a non-standard format is arguably better than missing some of it from untested remapping.
When
vuln-scan.shmerges Grype results into a CycloneDX SBOM, it places vulnerability data under a customvulnerability_scankey. CycloneDX 1.4+ defines a standard top-level vulnerabilities array that spec-compliant consumers (SCA platforms, dependency dashboards, etc.) expect.The recommended fix is to map Grype matches into the CycloneDX vulnerabilities schema (id, source, ratings, description, affects) and conditionally add the array when
.bomFormat == "CycloneDX". The customvulnerability_scankey can remain for Forge tooling.This issue was deferred from a Copilot comment on PR #57. Field mapping between Grype JSON and CycloneDX vulnerabilities schema is (surprisingly) non-trivial, so warrants its own PR with testing against Grype output. In the meantime, having it there in a non-standard format is arguably better than missing some of it from untested remapping.