feat: add custom SBOM tags support #4142
Conversation
Add support for arbitrary key-value pairs in SBOMs through new --sbom-property CLI flags. This enables users to add custom metadata to SBOMs for better organization and compliance tracking. Closes: anchore#3734 Signed-off-by: Henry Sachs <[email protected]>
Signed-off-by: Henry Sachs <[email protected]>
Signed-off-by: Henry Sachs <[email protected]>
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Henry Sachs <[email protected]>
|
I rebased the branch to match the latest syft changes and regenerated the schema |
There was a problem hiding this comment.
Hey @henrysachs overall this looks great. My main feedback is about being consistent with naming; properties makes more sense to me than tags
| Enrich []string `yaml:"enrich" json:"enrich" mapstructure:"enrich"` | ||
|
|
||
| // custom SBOM properties | ||
| SBOMProperties []string `yaml:"sbom-properties" json:"sbom-properties" mapstructure:"sbom-properties"` |
There was a problem hiding this comment.
Should is be a map[string]string? I think this is properly supported with all the configuration tooling, but we'd need a different field for the CLI flags of the type []string, probably
| for k := range tags { | ||
| keys = append(keys, k) | ||
| } | ||
| slices.Sort(keys) |
There was a problem hiding this comment.
I think you can just use slices.Sorted(maps.Keys(theMap))
| var parts []string | ||
| parts = append(parts, "SBOM Properties:") | ||
| for _, key := range keys { | ||
| parts = append(parts, fmt.Sprintf(" %s: %s", key, tags[key])) |
There was a problem hiding this comment.
Is there a reason for whitespace here? I think newlines shouldn't cause a problem, but maybe it's safer to use a different separator? Have you tried this in Tag-Value format? maybe we just output this like <key>=<value>;<key>=<value>, I think the = at least, is more consistent with the configuration here?
| Distro LinuxRelease `json:"distro"` // Distro represents the Linux distribution that was detected from the source | ||
| Descriptor Descriptor `json:"descriptor"` // Descriptor is a block containing self-describing information about syft | ||
| Schema Schema `json:"schema"` // Schema is a block reserved for defining the version for the shape of this JSON document and where to find the schema document to validate the shape | ||
| Tags map[string]string `json:"tags"` // Tags contains custom properties added to the SBOM |
There was a problem hiding this comment.
Tags seems like it might be misleading, confused with image tags maybe? Is there another term we could use here to be more clear what this is used for? CDX Properties seems a bit better, to me, maybe we adopt Properties?
| if tags == nil { | ||
| return make(map[string]string) | ||
| } | ||
| // Create a copy to avoid modifying the original map |
There was a problem hiding this comment.
Why would this be modified?
2 participants
Add support for arbitrary key-value pairs in SBOMs through new --sbom-property CLI flags. This enables users to add custom metadata to SBOMs for better organization and compliance tracking.
Closes: #3734
Description
This will allow users to define so called "tags" to their sbom. I already implemented SPDX and CycloneDX JSON Support. But as @kzantow also has stated I'm unsure about adding these values to the
commentsection of SPDX v2. As I'm not that deep into the standards I don't know when we can assume v3 to be released and would take the comment key as the best we can currently do. On the other hand i read that you can add "custom" values to the JSON as long as you prefix them. So we could add custom syft prefixed keys to the SPDX Document.Also to be open about it: I'm not that good in Software Testing so I used AI to help me write those Tests.
example command:
Type of change
Checklist: