How Veyra runs an application and API assessment.

The system, the roles, the reviewer.

An engagement begins with three documented inputs: the system under test (with environment, base URL, and version reference), the roles and credentials Veyra will exercise, and the external review or platform driving the request — marketplace approval, enterprise procurement, SOC 2 examination, or pre-launch diligence.

Inputs are captured in the client intake questionnaire and re-stated verbatim in the Statement of Work. Anything Veyra cannot reproduce from the inputs is not in scope.

Coverage is mapped to a public standard.

Application surfaces are assessed against OWASP ASVS v4.0.3 Level 2. API surfaces are assessed against the OWASP API Security Top 10 (2023). The technical report includes a coverage matrix that names each control evaluated, the test technique applied, and the in-scope routes the technique was applied to.

CVSS v3.1, with v4.0 dual-scoring on critical and high.

Every finding carries a CVSS v3.1 base vector. Critical and high findings additionally carry a CVSS v4.0 vector. The severity label rendered on the report is the higher of the two when they disagree, and the chosen vector is named in the finding header.

If a second qualified reviewer cannot reproduce it, it is not a Veyra finding.

A scanner alert is a candidate, not a finding. Every reportable issue is exercised by hand against the in-scope environment, captured as a request/response pair with the relevant excerpt, and described with the precondition, the action, and the observed effect. Findings without a reproducible request are removed from the report.

The manual validation rule is enforced by the Veyra Engagement Engine — our internal assessment workflow — as a pre-finalization gate. A finding cannot move to FINAL without a captured evidence artifact and a CVSS rationale.

Tools are disclosed in the report. Tools do not author findings.

The technical report appendix names every tool and version used during the engagement, the surface it was directed at, and the role it played — discovery, fuzzing, traffic interception, request replay. Tooling output is supporting evidence; severity, exploitability, and remediation are determined by the assessor.

Veyra does not describe the assessment as “AI-powered,” “fully automated,” or “machine-validated.” Engine assistance is described accurately as engine-assisted coverage with manual validation by the assessor.

The evidence pack is sized to the next reviewer.

Each finding is delivered with a reproducible request, the response excerpt that establishes the effect, and the precondition needed to reach the affected route. The evidence pack is keyed to finding IDs and is delivered alongside the technical report so a marketplace, procurement, or audit reviewer can verify any single line item without contacting Veyra.

Raw evidence is retained for one year; final reports for three. Test credentials are deleted within seven days of final delivery.

Some surfaces are excluded unless explicitly added.

Veyra does not assess physical security, social engineering of named individuals, denial-of-service against production, third-party SaaS endpoints not owned by the client, or end-user devices. These can be added by written amendment to the Authorization to Test, with the additional authorizations the surface requires.

Source-code review is white-box and is not part of a gray-box engagement unless contracted as a separate service. Gray-box engagements include source-assisted context — architecture, schemas, role documentation — but do not include line-by-line source review.