Repository navigation
Request: Evidence for Vulnerabilities #333
Description
Request: Evidence for Vulnerabilities
Similar to existing support for evidence for components, and other requests for evidence elsewhere, the request is to support evidence in the Vulnerability object. Specifically, what evidence can be provided to substantiate the presence or status of the vulnerability. Evidence can also be used in the "negative" context - to establish that a vulnerability is NOT AFFECTED, for example.
- Evidence (Type: [object])
- Presence (similar concept to
identityon component evidence) “Evidence that substantiates the presence or absence of the vulnerability.”- Confidence (Type: number) (Required) “The overall confidence of the evidence from 0-1, where 1 is 100% confidence”
- Methods (Type: [object])
- Technique (Type: enum) (Required) “The technique used in this method of analysis”
- SAST
- Binary SAST
- DAST
- IAST
- WAF
- Pen Testing
- WaaP
- RASP
- Emulation
- AST Fingerprint
- File Hash Comparison
- Function Hash Comparison
- Signature
- AST Dataflow / Taint Analysis
- Software Identifier (e.g. CPE, PURL that matches a software component in the BOM)
- CI / CD Security
- IaC Security
- Mobile AST (MAST)
- Other
- Technique (Type: enum) (Required) “The technique used in this method of analysis”
- Value (Type: string) “The value or contents of the evidence.”
- Description (Type: string) "A description of the evidence that may contain additional information about the investigation, for example"
- Tools (Type: [string]) "Tools used to conduct the scan and/or generate the evidence"
- Ref / Bom-Link
- Occurrences (Type: [Object])
- Location (Type: Object)
- Line number (Type: integer) “Line number in the affected file where the vulnerability occurs”
- Binary offset (Type: integer) “Decimal offset in bytes in the affected file where the vulnerability occurs”
- File name (Type: string) “File name of the file where the vulnerability occurs”
- Bom-ref (Type: string) “Optional identifier that can be used to reference the occurrence exists in the referenced BOM element.”
- Callstack (Type: object) (Optional)
- Frames (Type: object) (Optional)
- Function (Type: string)
- Parameters (Type: [string])
- Line (Type: integer)
- Column (Type: integer)
- Full filename (Type: string)
- Frames (Type: object) (Optional)
- Location (Type: Object)
- Presence (similar concept to
Example
"metadata": {
"timestamp": "2023-10-23T16:52:01.762473+00:00",
"tools": [
{
"services": [
{
"bom-ref": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb",
"provider": { ... },
"name": "...",
"version": "xxxx"
...
}
],
"components": [
{
"bom-ref": "dddddddd-dddd-dddd-dddddddddddd",
"provider": { ... },
"name": "...",
"version": "xxxx"
}
]
},
],
},
...
"vulnerabilities": [
{
"bom-ref": "aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"id": "CVE-2023-38408",
"source": {
"name": "xxx",
"url": "https://website.com"
},
"description": "CVE Description",
"detail": "CVE Details",
"affects": [
{
"ref": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
],
"evidence": [
{
"presence": {
"confidence": 1.0,
"methods": {
"technique": "software-identifier"
},
"value": "cpe:2.3:a:openbsd:openssh:7.2:*:*:*:*:*:*:*"
},
"tools": {
"ref": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
},
"occurences": {
"location": {
"bom-ref": "cccccccc-cccc-cccc-cccccccccccc"
}
}
},
{
"presence": {
"confidence": 1.0,
"methods": {
"technique": "signature"
},
"value": "<some binary signature that indicates that PKCS#11 Feature is enabled>"
},
"tools": {
"ref": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
},
"occurences": {
"location": {
"file-name": "/usr/sbin/sshd",
"binary-offset": 3478,
"bom-ref": "cccccccc-cccc-cccc-cccccccccccc"
}
}
},
{
"presence": {
"confidence": 1.0,
"methods": {
"technique": "pen-testing"
},
"description": "[2023-11-06-15-21-51] - Pen testing team executed POC script from https://github.com/kali-mx/CVE-2023-38408/blob/main/CVE-2023-38408.sh and found that the binary was vulnerable. Here could be a longer description of the evidence provided by that team."
},
"tools": {
"ref": "dddddddd-dddd-dddd-dddddddddddd"
}
}
]
}
]
Activity
stevespringett commentedon Nov 7, 2023
Excellent suggestion @nickvido. I think we need to clarify a few things...
AST Dataflow / Taint Analysisis typically one of many types of analyzers employed by SAST. Other common analyzers includecontrol flow,structural,semantic, andconfiguration. We could go down to that level if necessary, or we could keep it higher level and simply specify SAST. I currently don't have a strong opinion one way or the other. If we go down to the type of analyzer used, then we'll have to account for multiple static analysis rules that could possibly identify the vulnerability via the different analyzers used. This would be good info to have, but at the same time its also getting rather close to what FPR and SARIF can do today.code reviewshould likely be another option that would signify that human review was performed.valueexpected to be? Perhaps we could leverage many of the external references such aspentest-reportandstatic-analysis-reporthere instead?nickvido commentedon Nov 13, 2023
Thanks, @stevespringett
RE: Duplication and details of methods
I agree. It might make sense to have a description to go along with the
Techniqueenum? i.e. free-form text to let us specify what type of SAST, as in your example.code reviewis a good addition as well.RE:
valuefieldI'll admit I was thinking this could be pretty flexible, and a single string field might not be appropriate to capture structured output from a tool - e.g. if it has a
code_snippet,attack_details,request_details,response_details... I'm definitely open to suggestions on this. I see value in having some structured data at hand. I also think having an additional external references field here could be useful as well.stevespringett commentedon Dec 9, 2023
I'd like to get feedback from @brianf and @planetlevel if possible.
planetlevel commentedon Dec 11, 2023
Are you thinking this is only for CVEs? Lots of the tools and techniques listed identify vulns that will never be a CVE. Should we enable organizations to use CDX to communicate about these internal vulns?
I didn't see a lot about exploitability here. Just binary "presence." Since a huge number of "vulnerabilities" are unexploitable in real systems, I think it's important to capture the evidence to help organizations decide what to do. A lot of overlap with the idea of VEX here.
Vulnerabilities don't exist in a single line of code or stack frame. They typically span many files, methods, and libraries.
I capturing this entire trace is important. Generally, I think we should include HTTP location or other information about the attack surface targeted and any backend systems involved.
I have a lot more thoughts, but want to be sure I'm thinking about the right use case for this.
stevespringett commentedon Dec 28, 2023
@planetlevel yes, CDX should (and does) allow orgs to communicate about internal vulns. This enhancement proposal would expand the specs existing support for VEX and VDR by providing evidence of how a vulnerability was discovered.
The spec currently supports a description of the vulnerability, details, and recommendation, along with proof of concept including reproduction steps, environment information, and supporting material.
While all that information is good (and necessary) for vulnerability communication and disclosure, it's mostly textual based. This proposal is to add a bit more machine parsable metadata about how the vulnerability was discovered.
When looking at this proposal, think of it as the application as a whole, where 1st party or 3rd party code may be the culprit.
stevespringett commentedon Dec 28, 2023
IMO, I think the
occurrencesincluding the location and callstack may need a bit more work. But we may be able to get the "methods" in place for v1.6.stevespringett commentedon Dec 29, 2023
The follow is the proposed enumeration of techniques and the existing techniques used in component identity evidence.
source-code-analysisand/orbinary-analysis@nickvido can I get some feedback on this please?
Also, I'd like to get feedback from @jkowalleck, @coderpatros, and @christophergates
Are there techniques that are missing that can substantiate the presence or status of a vulnerability?
I'm also interested in further guidance that could fulfill the following use case:
While it is impossible to prove a negative, using evidence to build a case is an interesting perspective and could give credibility to VEX decisions.
stevespringett commentedon Dec 29, 2023
I'm also hopeful that we can come up with a common set of techniques that can be leveraged across component identity evidence and vulnerability presence evidence - similar to how we have a common set of external references that can be applied to virtually any object type.
stevespringett commentedon Dec 29, 2023
@nickvido with respect to:
I'm wondering if "presence" is the correct noun to use. We may want to choose something else. OR, we may want to have both "presence" and "absence". For example, if we had both, it could be possible to supply evidence in support of, and against the affected state of a vulnerability.
If we only have "presence", then we will need to also rely on vulnerability->analysis->state being set, as we will not know if the evidence is in support of the application being affected by a vulnerability, or not affected by a vulnerability.
stevespringett commentedon Dec 29, 2023
Draft Pull Request
planetlevel commentedon Dec 29, 2023
Because there exists such a massive range of quality and coverage in tools, I'm not sure it helps to list the generic category of tool that reports (or doesn't report) a vulnerability. For example SAST tools range from simple grep to full dataflow. So I'm afraid people will seek to check a bunch of boxes as "proof" when really they didn't prove jack shit.
There are three options that would be useful.
For (2) I'm imagining somehow detailing the contribution that the tool makes to the exploitability argument. A SAST tool reports the presence of a vulnerability, but generally doesn't have enough context to contribute to the exploitability discussion. Same with static SCA. But some tools calculate static reachability. That's one step closer to exploitability. Runtime Security tools (IAST/RASP) capture runtime reachability... that's one more step closer. Runtime Security tools also capture runtime data reachability... one more step. Pentest tools can go even further, actually demonstrating exploitability on the actual system -- that's pretty convincing evidence.
For what it's worth, here's my conception of "levels" of exploitability proof... Is there any way we could make this what CDX captures? Like, how far did you get in proving exploitability?
So, a set of evidence that says
"this is exploitable because I found it with SAST and DAST" is really weak.
But I'd be really convinced if the argument said:
"Reported by _____ SAST (or SCA) tool. Known exploit ________. Confirmed code is active with ____ Runtime Security tool. Confirmed required untrusted data reaches vulnerability with _____ Runtime Security tool. Confirmed other exploit conditions manually using ZAP and manual code review. Exploit confirmed manually - see writeup."
All you'd really need to report is the last step -- the actual exploit is 100% convincing. But I kind of like reporting the "discovery and analysis history."
8 remaining items
devashridatta-dotcom commentedon Jul 14, 2026
Following the reference to this issue in #956 and the earlier request in comment 12 for better LLM prompt/response evidence, I would suggest adding AI-specific evidence techniques to the vulnerability evidence model.
For AI systems, exploitability evidence often does not map cleanly to a CVE, file path, line number, or traditional static/dynamic scan result. The relevant proof may be behavioral, contextual, or tied to model, runtime, retrieval, or agent state.
Proposed AI evidence techniques:
prompt-transcript- the prompt or ordered sequence of prompts used to trigger or reproduce the vulnerability, such as prompt injection or jailbreak behavior.completion-transcript- the model output demonstrating the exploit or unsafe behavior, paired with the prompt transcript.behavioral-test- a reproducible test showing that the model exhibits the vulnerable behavior, similar to a unit test for AI safety or security properties.retrieval-trace- the retrieved documents or chunks involved in a RAG-based exploit, especially for indirect prompt injection or poisoned retrieval content.tool-call-trace- agent tool calls triggered by the exploit, showing the operational blast radius of an agentic workflow compromise.model-artifact-integrity- evidence about model weights, adapters, tokenizer files, chat templates, or configuration digests used to support an affected or not_affected decision.These additions would make the evidence model more useful for AI/ML vulnerabilities where the finding depends on behavior, provenance, prompt context, retrieval state, or agent tool access rather than a vulnerable package alone.
stevespringett commentedon Jul 20, 2026
Comments in the public RFC period should be made to #980 only.
jkowalleck commentedon Jul 20, 2026
RFC notice sent on July 20, 2026
Public RFC period ends August 17, 2026