It depends on the product and the deployment mode. Some SAST tools run inside your pipeline and send back only results, others copy source to a hosted service for analysis. Do not assume either. Ask where analysis runs, what leaves your network, how long it is kept, and how it is deleted.
Why this question comes up early
Source code is among the most sensitive assets a company has, and security and legal reviewers will ask about it before a pilot starts. Settling the data handling story first saves weeks. The questions below are a checklist for that conversation, and the answers should come in writing from the vendor.
Eight questions
- Where does analysis run? In your CI runner, on a server you host, or in the vendor's cloud?
- What leaves your environment? Full source, snippets around findings, metadata only?
- Is the transfer encrypted, and to which regions? Ask for the regions explicitly.
- How long is code or derived data retained? Is there a stated retention period?
- Can you request deletion, and how is it confirmed?
- Who at the vendor can access it, and is that logged?
- Is your code used to train or tune any model? Ask for the answer in writing, including for features you do not plan to use.
- What changes if you use an AI assisted feature? Some features send code to a model provider. Ask which one and under what terms.
What a good answer looks like
Good answers are specific. "Analysis runs in your runner, and only finding records and file paths are sent" is specific. "We take security very seriously" is not. If the answer depends on a plan or a setting, ask which setting and who controls it.
| Deployment style | Typical data movement | What to confirm |
|---|---|---|
| Runs in your pipeline | Results sent out, source stays | What exactly is in the results payload |
| Self hosted | Source stays inside your network | Who operates updates and rule feeds |
| Vendor hosted | Source copied to the vendor | Retention, region, access and deletion |
These are general patterns. A given product can offer more than one.
Evidence to ask for
Ask for the vendor's security documentation, their data processing terms, and any independent assurance reports they can share under NDA. Read what the document says about the exact feature you plan to use, not just the company in general. Be careful when a report is described as complete or a certification is implied. Confirm the status and scope directly.
Keep your own side tidy
Before the pilot, decide which repositories are in scope and exclude the ones that hold material you cannot share. Remove secrets from test branches. A pilot on a low sensitivity repository tells you most of what you need on accuracy and workflow.
Document the decision
Record the answers in your vendor file along with the date. If the vendor changes its data handling later, you will have a baseline to compare with. A one page summary is enough: where analysis runs, what leaves, how long it is kept, and who approved it.
A worked example: a one page data handling review
A mid sized company wants to pilot a SAST tool on two repositories. Their security reviewer asks the vendor the eight questions and records the answers in a table. The entries below are an illustration of the format, with made up answers, not statements about any real product.
| Question | Example answer received | Follow up |
|---|---|---|
| Where does analysis run? | In the customer's CI runner | Which runner image? |
| What leaves the environment? | Finding records and file paths | Does a record include code snippets? |
| Regions | Customer chooses at setup | Confirm in the contract |
| Retention | Results kept until deleted by the customer | Is there a hard maximum? |
| Deletion | Self service, with confirmation | Backups, and how long? |
| Staff access | Support access with customer approval | Is it logged and exportable? |
| Model training | Customer code not used for training | Get it in writing |
| AI features | Off by default | Which provider if enabled? |
The follow up column is where the real review happens. A first answer is rarely complete. A reviewer who reads "finding records" should ask whether those records include the lines of code around each finding, because snippets are source code too.
Step by step: run the review
- Send the eight questions in writing before the first call, so the vendor can prepare accurate answers.
- Ask for the security documentation and data processing terms for the exact product and plan you will use.
- Compare the written answers with the documents. Note any difference and ask which one is correct.
- Decide which repositories are in scope for the pilot, based on sensitivity.
- Configure the pilot so the minimum data leaves your environment, for example by turning off optional features you do not need.
- Record the final configuration, the date and the approver.
- Revisit the review when the vendor announces a change to its data handling or when you enable a new feature.
Details that are easy to miss
- Snippets in findings. Many tools show code around a finding. Ask whether that text is stored and for how long.
- Pull request comments. If findings are posted back to your source control system, the text lives there too, under your own retention rules.
- Logs. Debug logs on a runner may contain file names or code fragments. Decide who can read them.
- Subprocessors. A vendor may use other companies to host or process data. Ask for the list and how changes are announced.
- Exports. Reports you download may contain code. Treat them with the same care as the source.
Matching the answer to your own rules
Your internal policy decides what is acceptable. A company with strict rules about source code leaving its network may require a mode where analysis runs on its own infrastructure. Another company may accept a hosted service with clear retention and deletion terms. Neither is right in general. The point is to compare the vendor's answers with your own written requirements instead of making a judgment on impressions.
If the answer is "it depends"
Ask what it depends on. Plan, region, feature flags and contract terms are common factors. Get the combination that applies to you in writing. A statement such as "most customers use X" does not tell you what your tenant will do.
Evidence and assurance reports
If the vendor offers an independent assurance report, read its scope: which systems and which period it covers, and whether it covers the product you plan to use. A report that exists is not the same as a report that is complete for your use case. Never describe a vendor's report status to others without checking the document itself.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what each finding contains, such as file paths and code context, because that is the kind of data to ask about.
Quick check
Is a cloud SAST tool always a risk?
Not automatically. The question is what the vendor does with the code, how it is protected, and whether that meets your own rules.
What is the single most useful question?
What leaves my environment, exactly. The answer shapes every other review step.
Can I pilot without sending any real code?
Yes. Use a sample or open source project of similar size and language, or a low sensitivity internal repository. You still learn about accuracy and workflow.
Safeguard offers compliance and evidence automation and a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
