What is the correct way to refer to evidence components

[prabhu]

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:

1. ref1 is a package lock file. component_ref2 refers 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"} ] } ] }

2. Example showing a component ref1 referred 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-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?

[stevespringett]

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