What's Inside a DigVel Code Audit Report
Last updated: October 15, 2026
1. Overview
Every audit ends in a technical report that your engineering team can act on and your CTO can read. It serves as documented evidence of security testing for requirements such as the EU Cyber Resilience Act, and it contains enough detail for your developers to verify and close each vulnerability without our help. See the service page for pricing and the methodology for how findings are produced and validated.
Each finding includes:
- Identifier and severity with a CVSS score.
- Description of the flaw.
- Impact on your business logic and data.
- Location: the file and lines of code.
- Reproduction steps: an exact, step-by-step instruction.
- Recommendation for remediation.
2. Example Finding
An illustrative finding, as it appears in a report:
DVE-2026-001 - High, CVSS 8.1
Access to other customers' documents by changing an identifier (IDOR)
- Description: the API method checks that the user is signed in but does not check who owns the requested document.
- Impact: any customer can read other customers' documents by substituting their identifier in the request.
- Location:
src/api/documents/handler, lines 84-97. - Reproduction steps: 1) Sign in as user A. 2) Send
GET /documents/{id}with a document ID owned by user B. 3) Receive the content of user B's document. - Recommendation: verify that the document belongs to the current user before returning it.
3. Request a Sample Report
Leave your work email and we'll follow up with a redacted sample report so your team can see the format before ordering.