What is the correct way to refer to evidence components #613
-
I am looking for a way to capture components primarily used for evidence purposes. These may include lock files, manifest files, self-declared .about files, and similar items. Depending on the BOM tooling, such files may be represented using properties, metadata, or metadata.component.properties, etc. By reusing the component object, I can leverage Below are some examples I have developed so far:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6",
"version": 1,
"metadata": {},
"components": [
{
"type": "file",
"bom-ref": "ref1",
"name": "package-lock.json",
"hashes": [
{"alg": "MD5", "content": "md5_hash"}
],
"scope": "excluded",
"evidence": {
"identity": [{
"field": "name",
"methods": [{"technique": "filename"}]
}]
}
},
{
"type": "library",
"bom-ref": "component_ref2",
"name": "library1",
"version": "version",
"purl": "pkg:npm/library1@version",
"hashes": [
{"alg": "MD5", "content": "md5_hash"}
],
"scope": "required",
"evidence": {
"identity": [{
"field": "name",
"methods": [{"technique": "manifest-analysis"}]
}]
},
"externalReferences": [
{"url": "urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/ref1", "type": "evidence"}
]
}
]
}
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6",
"version": 1,
"metadata": {
"timestamp": "2025-03-19T12:00:00Z",
"tools": [
{
"vendor": "CycloneDX",
"name": "cdxgen",
"version": "latest"
}
]
},
"components": [
{
"type": "file",
"bom-ref": "ref1",
"name": "package-lock.json",
"hashes": [
{"alg": "MD5", "content": "md5_hash"}
],
"scope": "excluded",
"evidence": {
"identity": [{
"field": "name",
"methods": [{"technique": "filename"}]
}]
}
},
{
"type": "library",
"bom-ref": "component_ref2",
"name": "library1",
"version": "version",
"purl": "pkg:npm/library1@version",
"hashes": [
{"alg": "MD5", "content": "md5_hash"}
],
"scope": "required",
"evidence": {
"identity": [{
"field": "name",
"methods": [{"technique": "manifest-analysis"}]
}]
},
"externalReferences": [
{"url": "urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/ref1", "type": "evidence"}
]
}
],
"formulation": [
{
"workflows": [
{
"bom-ref": "workflow1",
"uid": "package_uid1",
"name": "builder",
"resourceReferences": [
{"ref": "ref1"}
],
"tasks": [
{
"bom-ref": "npm-install-step1",
"uid": "package_uid1",
"taskTypes": [
"build"
]
}
],
"steps": [
{"name": "npm-install-command", "commands": [{"executed": "npm ci"}]}
]
}
]
}
]
} Any thoughts on this design? Are downstream tools likely to implement such semantic parsing, or will they prefer misusing properties? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
It makes perfect sense to me. I think the maturity of consumption tools needs to improve a bit. Not sure how many tools would support this today. But almost every tool that supports properties will not take any action on them, rather, just use them as a name/value store. Small correction though. The ref should be:
not
|
Beta Was this translation helpful? Give feedback.
It makes perfect sense to me. I think the maturity of consumption tools needs to improve a bit. Not sure how many tools would support this today. But almost every tool that supports properties will not take any action on them, rather, just use them as a name/value store.
Small correction though. The ref should be:
not