When a buyer asks to review your source code, offer evidence that answers their underlying concern first: scan results, a pipeline walkthrough and test reports. If they still insist, propose a supervised, scoped review under NDA rather than handing over a repository. Decide your position in advance, with the deal owner.
What they are really asking
Most reviewers do not want to read your code. They want assurance that you build securely and that the product has been tested. A request for source can be a template item, a regulator driven habit or a lack of other options. Treat it as a question about confidence, not a demand for files.
A ladder of options
| Step | What you offer | Typical outcome |
|---|---|---|
| 1 | Written description of the development process and controls | Often enough for low risk deals |
| 2 | Evidence pack: dependency scan exports, SBOM summary, review settings, test summaries | Satisfies most reviewers |
| 3 | Live walkthrough of the pipeline with an engineer | Builds confidence on process |
| 4 | Summary of an independent test or review, with findings and fixes | Strong signal for high risk deals |
| 5 | Supervised review of defined modules under NDA, in your environment | For rare, high value cases |
Move up the ladder only when the lower step does not satisfy the buyer.
If you reach step five
A supervised review needs ground rules written before anyone looks at code.
- Scope. Name the modules and exclude the rest, such as billing logic or customer data handling you consider sensitive.
- Environment. Review in your own system or a controlled screen share. No copies leave.
- People. Named reviewers, bound by confidentiality.
- Time box. A set number of hours.
- Output. Findings go to you first, with a stated response window.
The legal terms are for the deal owner and counsel. Your role is to describe what is technically feasible and safe.
Do not hand over a repository
A copy of your repository carries secrets history, internal comments and the full intellectual property of the company. It also expands your own supply chain risk by adding another place where the code can leak. If a buyer demands a copy, escalate to leadership, because it is a business decision with consequences that engineering should not make alone.
Software escrow is a different topic
Some buyers ask for escrow to protect against vendor failure, not for security assurance. That is about continuity, and it is covered in software escrow and supply chain continuity planning.
Prepare the lower steps now
Because most buyers stop at steps two and three, invest there. Keep a standing evidence pack and a diagram of your pipeline. The NIST Secure Software Development Framework, SP 800-218, offers a vocabulary for describing practices such as review, testing and vulnerability response, and it describes practices, not a certification. Use it to structure the written description, and only describe what you actually do.
Try it yourself
Click through it at your own pace, or open it full screen. See what a code scan reports, the kind of summary that often satisfies a buyer without sharing source.
Safeguard provides SAST and dependency scanning, and its free scan can generate output you can summarise for a reviewer.
Quick check
Is refusing a source review a deal breaker?
Rarely, if you offer credible alternatives. Reviewers generally accept evidence and a walkthrough.
Who decides if we allow a supervised review?
Leadership with the deal owner, informed by engineering on scope and safety.
Sources
Last reviewed: 19 October 2026.
