What your verification report looks like.
Overall score, a clear PASS / HOLD / FAIL verdict, claim-vs-evidence checks, and prioritised findings — each citing file-level evidence.
PASS / HOLD / FAIL logic
One headline score (0–100) across the 7 layers, mapped to a clear commercial verdict.
No P0 issues; risks are minor and manageable. Reasonable to proceed.
Material issues found. Proceed only with conditions or remediation. This sample: 72.
Severe or systemic issues. Do not proceed without major rework.
Findings by priority
Severity uses P0 (critical) → P1 (high) → P2 (medium), plus low-priority notes.
Claim vs. evidence
We test what the product says against what the code and configuration actually do.
| Public / pitch claim | Evidence found | Verdict |
|---|---|---|
| "Bank-grade encryption of customer data" | User email & phone stored in plaintext; no column/at-rest encryption | NOT SUBSTANTIATED |
| "Proprietary AI model" | Thin wrapper over a third-party API; no model weights or training code in repo | PARTIALLY SUBSTANTIATED |
| "99.9% uptime / production-grade" | No staging gate, no monitoring/alerting; deploys straight to production | NOT SUBSTANTIATED |
| "Automated test coverage" | 12 test files present; no coverage report or CI enforcement | PARTIAL |
| "Scalable microservice architecture" | Single service; business logic + DB queries co-located in large controllers | PARTIAL |
Technical risk register (extract)
Representative rows from the full register. Every row maps to one of the 7 layers and cites observable evidence.
| Layer | Check | Evidence | Sev. | Result |
|---|---|---|---|---|
| Security | Secrets excluded from version control? | Hardcoded AWS key in config/database.php (line 23), not rotated | P0 | NO |
| Data handling | PII encrypted at rest? | users table stores email/phone in plaintext | P0 | NO |
| Data handling | Data retention / deletion policy implemented? | No retention or deletion logic; records kept indefinitely | P1 | NO |
| Security | Dependencies pinned & scanned? | 47/89 packages on caret ranges; no lockfile; no CVE scan | P1 | PARTIAL |
| Launch readiness | Staging gate before production? | CI deploys directly to prod; no approval/staging step | P1 | PARTIAL |
| Code substance | Separation of concerns? | 340-line controllers mixing logic + data access | P2 | PARTIAL |
| UX & workflow | Core promised workflow complete end-to-end? | Billing flow stubs present but not wired to provider | P2 | PARTIAL |
P0-1 — secret in version control
Every finding in the full report is documented at this depth.
Are secrets (API keys, tokens) excluded from version control?
Exposed cloud credentials create unauthorised-access risk to infrastructure, data stores, and downstream services — a common target for automated credential scanners.
Rotate the key immediately. Move secrets to a manager (AWS Secrets Manager / Vault), add .env to .gitignore, and scan full git history for further exposures.
Treat as a condition of close or launch: require written confirmation of rotation and a secrets-history audit before proceeding.
Prioritised action plan
The report closes with a ranked, time-boxed plan so teams fix the right things first.
- 1Rotate & vault all secrets. Remove keys from history; move to a secrets manager.Before launch
- 2Encrypt PII at rest. Add column/at-rest encryption for email and phone.Before launch
- 3Add a staging gate. Require approval + staging before production deploys.2 weeks
- 4Pin & scan dependencies. Commit a lockfile; enable CVE scanning in CI.2 weeks
- 5Align public claims. Correct "bank-grade" / "proprietary AI" messaging to match reality.30 days
What you receive
Evidence Report
Full narrative, every finding with file/line evidence.
Findings Matrix (.csv)
Machine-readable register, importable to Excel/Sheets.
Risk Dashboard
Score, verdict, and layer-by-layer heatmap.
SHA-256 Manifest
Tamper-evidence hash of every file reviewed.