🚀 Motivation

SBOM component property keys are being migrated from vendor-specific prefixes (osv-scanner:, datadog-sbom-generator:) to a unified canonical format (datadog:). During this transition period, SBOMs can contain either the old legacy keys or the new canonical keys (or both). datadog-ci must be able to handle both formats seamlessly to avoid dropping data.

📝 Summary

• Renamed existing SBOM property constants to LEGACY_* (osv-scanner: and datadog-sbom-generator: prefixes) and introduced new canonical constants with datadog: prefix (PACKAGE_MANAGER_PROPERTY_KEY, IS_DEPENDENCY_DIRECT_PROPERTY_KEY, IS_DEPENDENCY_DEV_ENVIRONMENT_PROPERTY_KEY, EXCLUSION_KEY, REACHABLE_SYMBOL_LOCATION_KEY_PREFIX).
• Updated payload.ts to parse both legacy and canonical property names when building dependencies. Canonical (datadog:) values take precedence over legacy ones when both are present.
• Exclusions from legacy (datadog-sbom-generator:exclusion) and canonical (datadog:exclusion) keys are merged via a Set to avoid duplicates.
• Reachable symbol location entries from both datadog-sbom-generator:reachable-symbol-location:* and datadog:reachable-symbol-location:* are collected together; deduplication is delegated to another component.
• Added a new fixture (sbom-with-both-legacy-canonical-properties.json) and a corresponding test case that validates the dual-parsing behaviour, priority rules, and merging logic.

🧪 Testing

• New tests were added for new logic.
• Existing tests were updated for new logic, and not only so that they pass!
• Benchmark results prove that performance is the same or better.

🚧 Staging validation

• Deployed and monitored using Datadog dashboards.
• Proof that it works as expected, including profiling or UX screenshots.

Tested locally comparing the payload output using as input different SBOM files

🆘 Recovery

Notes for on-call - select only one:

• The change can be rolled back.
• Do not roll back. Why?: