Add support for CycloneDX component properties

[nscuro]

Current Behavior

Properties are a great way of enriching BOMs with additional information throughout their lifecycle.

Properties can add important context to a component, which is interesting to DT users and downstream systems consuming from DT alike.

Trivy for example includes various metadata about the identified package:

"properties": [
  {
    "name": "aquasecurity:trivy:PkgID",
    "value": "alsa-lib@1.2.7.2-1.el8.x86_64"
  },
  {
    "name": "aquasecurity:trivy:PkgType",
    "value": "redhat"
  },
  {
    "name": "aquasecurity:trivy:SrcName",
    "value": "alsa-lib"
  },
  {
    "name": "aquasecurity:trivy:SrcVersion",
    "value": "1.2.7.2"
  },
  {
    "name": "aquasecurity:trivy:SrcRelease",
    "value": "1.el8"
  },
  {
    "name": "aquasecurity:trivy:LayerDigest",
    "value": "sha256:0696ddd1a0cc312db85739d667022f06cff29fda7d0907fb88d67cf4618a30ae"
  },
  {
    "name": "aquasecurity:trivy:LayerDiffID",
    "value": "sha256:fba413f75dde5d35219e05c062c2f8345ccf955a4c6508c86ba3b98e461eb7bd"
  }
]

Other examples can be found in the CycloneDX property taxonomy, among them GitLab.

Dependency-Track does not currently support component properties.

Proposed Behavior

Ingest component properties from BOMs, and expose this information via REST API and UI.

Ensure that properties are included in the various forms of export formats (Inventory, inventory with vulnerabilities, VDR?).

It should be possible to add, update(?), and delete(?) properties via REST API and UI.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

Slightly related to #2373, which discusses properties on the project level.

Do we want ingested properties to be mutable? Do we want users to be able to alter what was stated in the BOM?

[robertlagrant]

Do we want ingested properties to be mutable? Do we want users to be able to alter what was stated in the BOM?

One use case this might be helpful in is software as a medical device. We need to track what's called SOUP (Software of unknown provenance), along with some decision-tracking fields for risk assessment. Being able to add that information in the DT user interface, for example, would probably fit a lot of workflows.

[github-actions]

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.