Repository navigation
Unified evidence model #979
Description
One shared evidence model for components and vulnerabilities that records what was found, how it was determined, the confidence, and the tools and parties involved. 2.0 closes the evidence gaps that 1.x could not address without breaking changes.
Work
- Shared
cyclonedx-evidencemodel, reused by component and vulnerability evidence with structural context separation - Request: Evidence for Vulnerabilities #333 Vulnerability evidence: presence, absence, graded exploitability, occurrences, supporting data
- Add support for array of callstack frames #278 Multiple call stacks as a first class array, aligned with SARIF code and thread flows
- Substantiate license and copyright evidence (methods, confidence, tools, occurrences), matching identity evidence
- Attribute evidence to the parties involved, not only the tools (
assertion.parties) - Detection rules, policies, and queries, plus scanner and engine versions; method external references
- LLM assessment support via
promptandcompletionsupporting data types - Centralize the repeated
contentsconstruct in the data model - Replace enum
otherwith the 2.0 string or object form
Breaking changes are allowed in 2.0 and kept minimal. Reference schema validated against a JSON Schema 2020-12 test corpus.
Activity
jkowalleck commentedon Jul 20, 2026
RFC notice sent on July 20, 2026
Public RFC period ends August 17, 2026
elang2 commentedon Aug 17, 2026
Is behavioral evidence (what an agent did, not what it is) in scope for the unified evidence model? The current framing covers component and vulnerability evidence. My implementation experience suggests a gap: for AI agents, the harder problem is attesting the sequence of actions taken, not the inventory of components loaded.
I built mcp-audit (https://github.com/elang2/mcp-audit-gateway) which produces integrity-sealed, hash-chained records of tool calls. Each record is signed and links to the previous via SHA-256, making partial deletion or reordering detectable. The anchor point back to a BOM would be a digest of the tool manifest at proxy startup.
If behavioral evidence is out of scope for the unified model, would a separate behaviorEvidence external reference type in Blueprints be the right direction? Happy to follow whatever process makes sense.