-
-
Notifications
You must be signed in to change notification settings - Fork 93
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 hashes and other details to describe the evidence components more precisely.
Below are some examples I have developed so far:
ref1is a package lock file.component_ref2refers to this component via a BOM-Link in external references.
{
"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"}
]
}
]
}- Example showing a component
ref1referred as an evidence and in a workflow step.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6",
"version": 1,
"metadata": {
"timestamp": "2025年03月19日T12: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?
All reactions
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:
urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/1#ref1
not
urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/ref1
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:
urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/1#ref1
not
urn:cdx:fc56cbe5-3448-407b-b7e9-c8c090e6e8a6/ref1
All reactions
-
👍 1