Prepare a safe source snapshot for security review
Send a versioned, minimized code snapshot for review without secrets, local configuration, or executable setup steps. Keep a clear evidence manifest.
For a source-based security review, prepare a fixed snapshot of the code needed to answer the review question. Include enough context to trace the relevant behavior, but exclude credentials, customer data, local machine configuration, and unrelated repositories. Record the commit and file hashes so findings can refer to the exact material reviewed.
Do not ask a reviewer to run an unfamiliar project's installation script just to read it. Source inspection and execution are separate activities with different permissions and controls. The OWASP secure code review guidance provides background on examining code for security properties. The preparation procedure here is our suggested handoff format.
What should the package contain?
| Include | Why |
|---|---|
| Relevant routes and handlers | Locate the operation under review |
| Authentication and policy code | Trace identity and permission decisions |
| Data access layer | See how ownership filters reach storage |
| Dependency manifests and lockfiles | Identify the code's declared dependencies |
| Synthetic tests and schemas | Understand expected behavior without real records |
| Snapshot manifest | Bind paths to an immutable review version |
List exclusions in the manifest. If a policy service is omitted, say so. A reviewer should not infer that the missing service has no security role.
How do you remove sensitive material?
- Export the approved revision into a new review directory.
- Exclude environment files, key stores, credentials, private certificates, database dumps, and runtime logs.
- Check configuration defaults, fixtures, comments, and screenshots for embedded sensitive values.
- Review secret-scanner results manually. A clean scan does not prove the absence of secrets.
- Hash the final files and save the exclusions and review question.
- Transfer through the approved channel with named recipients and retention rules.
Do not include repository history unless the scope requires it. Deleted secrets can remain in earlier commits. If history is required, review it separately and agree on the handling of any discovered secret.
What must the recipient avoid assuming?
A snapshot is evidence, not permission to execute code or load project instructions into an agent. Treat build scripts, repository prompts, hooks, and comments as untrusted input. An approved reading task does not imply network access or package installation.
Keep the archive unchanged after transfer. Send a new version and change list when code changes. If the reviewer cannot resolve a file reference or reproduce its hash, pause conclusions tied to that file.
To plan a review, tell Sourced which behavior needs inspection. Do not attach private code to the first inquiry. Agree on scope and secure transfer first.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.