Sample product-security validation report
This fictional example demonstrates validation scope, current evidence, qualified impact, a prioritized fix queue, revalidation history, and explicit limitations. It is not customer data.
Validation scope
- Connected source
- Fictional private GitLab project · main branch
- Checks performed
- Supported secrets and code validation; example web exposure validation
- Checks not performed
- GitHub configuration audit, SCA, IaC, container, cloud, dynamic pentest
- Last successful validation
- 24 July 2026 at 14:32 UTC
- Coverage limitations
- Fetched and selected supported scope only; unknown context remains unknown
Current state
- Open high-priority findings
- 1
- Findings requiring review
- 2
- Resolved since previous validation
- 3
- Validation freshness
- Current as of 24 July 2026
Illustrative data only
This is not a customer report, audit, penetration test, or proof that a real repository was scanned. It is a product example that demonstrates report shape and wording.
Example grade
B
Supported findings show improvement is needed, but no critical issue is shown in this fictional snapshot.
Example risk score
71
Illustrative score based on severity, category, and available context.
Findings shown
4
A short fictional set covering secrets, repository posture, exposure, and documentation.
Executive summary
The fictional project receives a B grade because the example scan found one high-severity secret-like value, two medium-priority posture or exposure issues, and one low-priority documentation gap.
The recommended first action is credential review and rotation, followed by repository hardening and client-side exposure review. The report should be followed by a rescan after fixes are applied.
Evidence confidence
Confirmed
The supported validation directly observed the described condition.
Supported
Evidence supports the conclusion within the stated validation scope.
Conditional
The impact depends on validity, scope, restrictions, or reachability not fully observed.
Unknown
Available evidence cannot safely support a stronger conclusion.
Remediation and revalidation
In this fictional history, an earlier validation reported three credential-like values. The team rotated or reviewed them, removed the repository evidence, and ran another validation. The later scan did not report those same supported findings.
That comparison confirms only that the later supported validation no longer observed the evidence in scope. It does not prove provider-side revocation, complete removal from every historical copy, or total product security.
Example findings
These findings are fictional. Real reports should only include evidence from authorized scans and should protect sensitive paths, snippets, and security metadata.
| ID | Severity | Category | Location | Action |
|---|---|---|---|---|
| SEC-001 | High | Secrets detection | src/config/payment.tsPAYMENT_API_KEY=redacted_example_value | Rotate or revoke the credential, move sensitive access server-side, and rescan after removal. Blast radius: Possible provider API impact if the value is real, active, and scoped beyond test usage. |
| SEC-002 | Medium | Repository posture | GitHub repository settingsBranch protection not detected for the example main branch. | Require pull request review, status checks, and restricted direct pushes for protected branches. Blast radius: Could allow direct changes to important code paths if the repository is used for production releases. |
| SEC-003 | Medium | Client-side exposure | apps/web/.env.examplePUBLIC_ANALYTICS_KEY=redacted_example_value | Confirm whether the value is public by design, restrict provider permissions, or move sensitive usage server-side. Blast radius: Likely narrow if intentionally public and provider-restricted; review is still needed. |
| SEC-004 | Low | Repository security | SECURITY.mdSecurity policy file not found in the example repository root. | Add a security policy with contact instructions, supported versions, and disclosure expectations. Blast radius: Operational impact during vulnerability disclosure or customer security review. |
Example fix queue
- 1Rotate or revoke the high-severity credential-like value and remove it from repository content.
- 2Enable branch protection for the primary release branch and require review before merging.
- 3Review client-side environment values and confirm whether they are intentionally public and restricted.
- 4Add a SECURITY.md file so external reporters and customers know how to reach the team.
- 5Rescan the repository and attach the updated report to the internal remediation record.
What this does not prove
- It does not prove the fictional repository is secure.
- It does not represent a full audit, penetration test, SOC 2 review, or ISO 27001 assessment.
- It does not prove every secret, vulnerability, dependency issue, or cloud risk has been found.
- It does show how supported findings can be summarized, prioritized, and explained with limitations.
Technical appendix
Scan target
Fictional GitHub repository selected by an authorized user. This page does not represent a live customer scan.
Data retained
The report represents findings, paths, short evidence snippets, severity, and remediation context. It does not imply full source-code retention.
Severity model
Severity is an operational decision aid based on supported evidence. Teams should adjust priority when they have stronger business or architecture context.
Blast radius
Impact language is conservative. Unknown or conditional impact should stay visible rather than being invented.