A security platform typically stores five kinds of data: repository and asset metadata, scan findings, any code or file excerpts attached to findings, user and account data, and operational logs. Ask the vendor to list each class, where it lives, how long it stays, and who can read it.
Why the question is bigger than "do you store our code"
Buyers often ask one narrow question, "do you keep our source code?", and accept a one line answer. That leaves most of the data unexamined. A scanner that never copies a repository can still hold a map of your whole software estate, a list of your unfixed vulnerabilities and the names of the people who work on them.
That material is sensitive. A list of open, unpatched weaknesses is exactly what an attacker wants. Treat it as confidential even when it contains no secrets and no customer records.
The five data classes to ask about
| Data class | Examples | What to ask |
|---|---|---|
| Asset metadata | Repo names, branch names, package manifests, image tags | Is it stored, and for how long after a repo is disconnected? |
| Findings | Vulnerability IDs, severity, affected component, fix status | Who can read it inside the vendor? Is it used for anything beyond your account? |
| Code excerpts | Snippets in static analysis results, file paths, line numbers | Are excerpts stored or fetched on demand? |
| Account data | Names, work emails, roles, SSO attributes | Is it limited to what login and audit need? |
| Operational data | Access logs, API logs, support tickets, backups | What do they contain, and do they follow the same retention as the rest? |
Ask for the answer as a table the vendor can sign off on, not as a sales call summary.
Follow each class through four questions
For every row, get a plain answer to these.
- Where is it stored? Region and provider, including any copy used for search, analytics or caching.
- How long is it kept? A number of days or a rule, such as "until the integration is removed plus N days".
- Who can read it? Roles, not departments. Is support access logged and time limited?
- How is it removed? On request, at contract end, or automatically.
If the vendor uses sub-processors for any class, see how to review a sub-processor list.
Why storage minimisation is a fair thing to ask
The GDPR sets a storage limitation principle: personal data should be kept in a form that identifies people for no longer than necessary for the purposes of processing. Account data and commit author details are personal data, so a vendor serving EU customers should be able to explain why each field exists and when it goes. The same discipline is a good test for non personal data too. If a vendor cannot say why it keeps something, it probably keeps it by default.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how much an inventory shows: component names, versions and where they run. That is the kind of metadata your vendor holds once it has scanned you.
How Safeguard fits
Safeguard offers SaaS, private VPC, on-prem and air-gapped deployment, so the answer to "where does it live" can be your own environment. You can also run the free scan to see what a result looks like before you share a repository.
Quick check
Is a vulnerability list really confidential?
Yes. A current list of unfixed weaknesses in your software shows an attacker where to start. Ask for it to be treated as confidential customer data in the contract.
Should the vendor give this inventory before or after signing?
Before. Ask during security review and attach the signed table to the order paperwork so later changes are visible.
Sources
Last reviewed: 19 October 2026.
