CycloneDX evidence identity records how a tool concluded who a component is. Each entry names the identity field, such as purl or version, the methods used, and a confidence between 0 and 1. It lets a reviewer tell a manifest-derived identity from a guess made from a file name.
What the fields mean
In the 1.6 JSON reference, a component's evidence can hold an identity array. Each identity object has a required field naming which identity property it describes. The allowed values are group, name, version, purl, cpe, omniborId, swhid, swid and hash.
It also holds a confidence number from 0 to 1, where 1 is 100 percent. A concludedValue gives the value concluded from all methods. A methods array lists each technique used, each with its own confidence.
The technique values include source-code-analysis, binary-analysis, manifest-analysis, ast-fingerprint, hash-comparison, instrumentation, dynamic-analysis, filename, attestation and other.
The spec notes that single identity objects were introduced in 1.5 and arrays in 1.6, and recommends using arrays even for one entry.
"evidence": {
"identity": [{
"field": "purl",
"confidence": 0.9,
"concludedValue": "pkg:npm/example@1.2.3",
"methods": [{ "technique": "manifest-analysis", "confidence": 0.9 }]
}]
}
How to read it
Treat technique as a trust ranking you decide yourself. A match from a lockfile entry is normally stronger than one from a file name. A hash comparison against a known artifact is stronger again. The numbers are the tool's own estimates, so do not compare scores across different tools.
| Technique | Typical strength |
|---|---|
| manifest-analysis | Good when the manifest lists exact versions |
| hash-comparison | Strong when the reference hash is trusted |
| binary-analysis | Useful when no source exists, may be approximate |
| filename | Weak, easily wrong |
Where it helps
Triage of low-confidence components. If a high severity finding hangs on a component identified by file name alone, verify the identity first. A false match wastes an engineer's day.
Supplier questions. When a customer challenges an entry, evidence shows how you derived it. Pair that with where in the repo it was found, using the occurrences list, which can hold a location, a line and extra context.
Tool comparison. If two scanners disagree on a version, the evidence trail shows which method each used.
Limits
Evidence is optional, and many generators leave it out. Its presence does not prove the identity is right. It shows the reasoning. A file with confidence 1.0 and a manifest technique can still be wrong if the manifest was stale.
Safeguard can generate SBOMs and run dependency scanning across your repositories, so the fields discussed here are checked on real projects instead of by hand. You can try the free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo, click through the component list, and look at how each package is identified and what is missing.
Click through it at your own pace, or open it full screen.
Quick check
Is evidence required in CycloneDX?
No. It is optional on a component, and many tools do not emit it.
Can I compare confidence numbers between tools?
Not reliably. The score is the producing tool's own estimate, so use the technique as the more comparable signal.
Sources
Last reviewed: 19 October 2026.
