Ask where your code is processed, what the tool can read and write, how long data is kept, who at the vendor can see it, and how you leave. A scanner touches your most sensitive repository, so it deserves the same review as any other supplier with access to it.
Why this is easy to skip
Teams adopt security tools to reduce risk, so a review of the tool can feel redundant. It is not. A tool with read access to a monorepo and write access to pull requests is a high privilege integration. Treat it as part of your own supply chain.
NIST's Secure Software Development Framework, SP 800-218, describes a core set of high level secure development practices that organizations can integrate into their software lifecycle. Reviewing the tools in that lifecycle fits the same spirit.
Questions by topic
Data flow
- Does the code leave your network, or does analysis run inside it?
- If it leaves, which parts: whole files, metadata or only dependency lists?
- Where is it processed, and in which regions?
Access
- What permissions does the integration request? Ask for read only to start.
- Can access be limited to chosen repositories or directories?
- Does it need to write to pull requests or branches, and can that be turned off?
Retention and visibility
- How long are code, results and logs kept after a scan?
- Who at the vendor can access them, and under what process?
Exit
- Can you export your results and delete your data on request?
- What happens to open pull requests or comments when you disconnect it?
Reading the answers
| Answer you want | Answer that needs follow up |
|---|---|
| Analysis can run in your environment | Code is uploaded with no option to stay local |
| Scoped, read only access by default | Broad write access required from the start |
| Stated retention with deletion on request | No retention statement |
| Documented export and offboarding | "Contact us" for exit |
Ask for answers in writing. If a claim matters to your decision, ask for the document that backs it up, not a verbal assurance.
Run the review in parallel, not in sequence
Start the vendor review while you plan the pilot. Pilot on a low sensitivity directory or a public sample while procurement and legal finish, so the technical work does not wait on paperwork.
Keep the integration small
Whatever the answers, grant the narrowest access that lets the pilot work. Use a dedicated service account, short lived tokens where possible and a named owner for rotating them. Log what the account does, and review the log after the first week.
Where Safeguard fits
Safeguard's CLI (1.4.0, curl and PowerShell installers) runs on your machine, and the free scan at https://gold.safeguard.sh/scan lets you try the product on a small project before any integration. Ask Safeguard these same ten questions; you should expect written answers.
Quick check
Does a vendor security review replace a pilot?
No. The review checks risk; the pilot checks fit. Do both, and start with the narrowest access.
Who should own the review?
Security leads it, with input from legal on retention and data location, and from engineering on access scope.
Sources
Last reviewed: 19 October 2026.
