feat: add custom properties to external references #610
Conversation
Urist-McGit
force-pushed
the
feat/ext-reference-properties
branch
2 times, most recently
from
f5e6bed to
aaf9399
Compare
With this property external references can be annotated with additional metadata in a machine-readable format. Signed-off-by: Christoph Steiger <[email protected]>
Urist-McGit
force-pushed
the
feat/ext-reference-properties
branch
from
aaf9399 to
ed9918d
Compare
|
@Urist-McGit, the current state looks promising. According to the CycloneDX working model, the next step would be to move from "prototype" to "draft", meaning the community review phase (RFC) would start. |
|
@gernot-h any reservations? Otherwise I think we can continue to the RFC |
|
Thanks, @Urist-McGit, for taking care! From my side, please proceed to RFC step! |
jkowalleck
added
draft
RFC notice sent
|
RFC notice sent.
Public RFC period ends April 13, 2025 |
| <reference type="component-analysis-report"> | ||
| <url>http://example.com/extref/component-analysis-report</url> | ||
| <properties> | ||
| <property name="author">John Doe</property> |
There was a problem hiding this comment.
This is confusing to me. What if the external source has a different value for author and timestamp?
There was a problem hiding this comment.
Sorry, but what exactly do you mean by "different values for author and timestamp"? This is an example for additional properties provided in the SBOM for this report. They might be added because this metadata isn't available from the external source or just because it saves us an additional query to the external server when I need this information when handling the SBOM.
There was a problem hiding this comment.
Take externalReferences.type == bom. If there are differences in the value for properties (say author), then there is a question about source of truth. Caller has to make an additional query to the external server.
We use annotations attribute to add/store additional information about certain attributes. Any issues with that?
There was a problem hiding this comment.
Hmm, but how would how such additional information for an external reference differ from any other data points you provide for a component in your SBOM? Same problem would also apply for author or licenses or other properties of a component and most of them could usually also be looked up on a homepage or package repository. I think the idea of an SBOM is to document your understanding of your BOM in a central place, no-one protects you from providing wrong data there.
Regarding annotations: What we need is a machine-readable key/value store per external reference. Today, we mis-use the comment field of external references for storing such data, which obviously doesn't scale. I don't think using annotations would really improve that and also doesn't allow us to document these fields in our taxonomy.
With this property external references can be annotated with additional metadata in a machine-readable format.
As discussed in #608 this adds support for custom properties in external references.
fixes #608