Illustrative sample · synthetic data

A finding is the start of a review.

This example explains how to read security evidence. It is not a customer report, an executed scan, or a claim that this sample application is safe.

Release decision: insufficient evidence

The example repository review identifies a possible secret in a browser-facing file. Database access-policy evidence is missing and deployment settings have not been checked. A release decision still needs those checks and verification of any changes.

1. Check what the review actually covers

Repository
Illustrative finding only; no real commit scanned
Supabase policies
Missing — no database review executed
Deployment
Missing — no deployment evidence collected
Verification
Not run — no fix has been verified

In a real review, inspect the source, revision and collection time. Fresh evidence can still contain findings. A failed or missing check does not become a passing result.

2. Investigate the finding

Possible privileged key in client configuration. The synthetic example points to src/example-client.ts, line 12. No real key is displayed. Confirm the credential type and whether the file enters a client bundle before deciding the exposure and severity. A public Supabase publishable key is expected in client code; a secret/service-role key is not.

A pattern match alone does not establish whether a credential is active, what it can access, or whether anyone used it. Those questions require authorized evidence.

3. Review a proposed fix

If a privileged key was exposed, rotate it, investigate its use and move privileged operations behind authenticated server-side authorization. Remove the key from client configuration and inspect generated assets. Deleting a line does not revoke a credential or erase repository history. Supported repository changes can be proposed in a draft pull request; review the diff before merging.

4. Collect verification evidence

  • Record the new commit and deployment being assessed.
  • Confirm the old credential is revoked through the provider's supported process.
  • Inspect the deployed client assets for the exposed value without sharing it in a report.
  • Check authorized and unauthorized access to the server operation using synthetic test data.
  • Rerun affected checks and retain the result, source and time.

These are suggested operator steps, not a claim that Sentrail automatically performs every verification. Until qualifying evidence exists, the example remains unverified.

Start with your own scope

Review connection setup, how verdicts work and remediation controls. Connect only resources you are authorized to assess. This example makes no compliance, penetration-test or complete security guarantee.

Start Free