In scope are the product, environment and repositories the buyer will actually rely on: the production service they will use, the code and pipelines that build it, and the vendors that touch their data. Write the scope down before you answer questions, so every answer refers to the same boundary.
Why scope is the first answer
Questionnaires say "your software" or "your environment" without defining either. A startup may run a main product, a legacy tool, an internal admin app and an experimental service. If you answer "all code is scanned" and the legacy tool is not, you have made a false statement without meaning to.
Scope also protects you from the opposite problem. Without a boundary, a buyer may assume their review covers things they will never use.
What to define
| Item | Question to settle |
|---|---|
| Product | Which product and which edition will the buyer use? |
| Environment | Production only, or also staging and sandbox? |
| Repositories | Which repositories build and deploy that product? |
| Pipelines | Which CI and release systems touch those repositories? |
| Vendors | Which third parties process the buyer's data? |
| Exclusions | What is deliberately out of scope, and why? |
Put this on one page, dated, and attach it to your answers.
Build the repository list
Start from deployment, not from the repository host. For each running service, follow the chain back: image, build, repository, base image, shared libraries. Then compare against the repository host to find repositories nobody mentioned. Orphaned or forgotten repos are where gaps hide.
For each in scope repository, record:
- Owner.
- Language and package manager.
- Whether dependency scanning runs, and since when.
- Whether branch protection and required review are on.
- Whether it produces an SBOM.
A gap in any column is something to fix or to state honestly.
Handle the awkward ones
Legacy tool outside the main flow. If it handles no customer data and ships nothing to customers, you may exclude it, but say so. If it is on the same network as production, think harder before excluding it.
Shared libraries and internal packages. These are in scope if the product includes them. They are an easy thing to forget.
Third party code you vendored into the repo. It is still your responsibility. Make sure the scanner reads it, or list it separately.
Wording
"Scope for this review is the production application and its supporting services, built from nine repositories listed in the attached table. Staging and an internal admin tool are excluded. Excluded systems hold no customer data."
Only say the last sentence if you have checked it. See also which pen test document to share at each deal stage for a similar scoping habit.
Keep it current
When you add a service, the scope document changes. Add a line to your release checklist, so new repositories join the table and the scanning rules on the day they are created.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how inventory groups components by project, which helps you check that every in scope repository is represented.
Safeguard's asset discovery and SBOM features can help you find repositories and products you may have missed. A free scan covers the first repository.
Quick check
Can we exclude staging?
Often yes, if it holds no customer data and you say so. State the exclusion, do not leave it implied.
Who approves the scope?
An engineering lead and the security owner, then the deal owner confirms it matches what the buyer expects.
Last reviewed: 19 October 2026.
