VXDF Format Comparison

Compare traditional vulnerability reports with VXDF's structured evidence approach

SQL Injection Example

Critical

CWE-89

Traditional Security Report

Potential SQL Injection

User input may not be properly sanitized before database query execution.

Confidence:

Low

Investigation:Manual investigation required

Location:LoginController.java:42

Evidence:None provided

Recommended Actions:

• Manual testing required to confirm exploitability

• Review code for potential input validation issues

• Consult security team for further analysis

Limitations:

⚠Static analysis may produce false positives
⚠Actual exploitability not verified
⚠Impact assessment requires manual review

False Positive Likelihood: High uncertainty

VXDF Evidence-Based Report

Validated SQL Injection - Authentication Bypass

Demonstrated SQL injection allows authentication bypass and data extraction.

Confidence:

Confirmed

Investigation:Minimal verification needed

Data Flow:LoginController.java:42 → DatabaseUtils.java:156

Evidence:

HTTP Request: username=' OR '1'='1' --&password=test

Database Query: SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='test'

Response: 200 OK with admin session token

Data Extracted: 15,432 user records including passwords

Remediation Steps:

1Replace string concatenation with prepared statements
2Implement input validation for username/password fields
3Add rate limiting to login endpoint

Validated & Actionable: Ready for immediate remediation

Structural Differences Comparison

Evidence Structure

Traditional:Unstructured text

VXDF:33 structured types

Structured data

Validation Requirement

Traditional:Not required

VXDF:Mandatory

Evidence-based

Remediation Guidance

Traditional:General advice

VXDF:Specific steps

Actionable details

Machine Readability

Traditional:Limited

VXDF:Full JSON Schema

API-friendly

Ready to Experience Evidence-Based Security?

Explore the full VXDF schema and see how it transforms vulnerability management