How software validation reports work

Every case starts with a written scope: the areas to review (for example authentication, database policies, API design) and the exact project version. The reviewer checks only what's in scope.

Reviewers are community members at level 4 or higher who switched on "Available for validation". Open a reviewer's profile to see their skills, ratings and past reviews, then click "Request validation". Or post an open request: reviewers read your project name, areas and description (never your links or files) and send offers, and you choose one.

An invited reviewer has 48 hours to accept or decline. If they decline, invite someone else.

• Share access only after the reviewer accepts — the case page shows you how.
• GitHub: add the reviewer as a collaborator with Read access. The reviewer confirms it works.
• Or use a test site with a test account, or upload a zip of the relevant code.
• Never share production passwords, live API keys or customer data.
• When the review is done, remove the reviewer's access. The case reminds you before it closes.

• Severity: critical, high, medium, low or informational.
• Evidence: where and how the issue was observed.
• Recommendation: how to fix or reduce the risk.

You fix what you can and request a retest. The reviewer checks each fix and records the result. Findings you decide not to fix can be marked as accepted risks.

The reviewer issues a dated, versioned report with the scope, reviewer, methods, every finding and its status, unresolved issues and known limitations. If you fix more later, a new version can be issued; earlier versions stay in the revision history.

You can make the report readable by anyone with its link, and rate your reviewer. Ratings appear on their profile and earn them reputation.

A report is a record of a defined review — not a certificate that the software is secure, bug-free or legally compliant.