Ask where the scanner runs, what it stores, who can read it, how long it keeps it and how you delete it. A DAST scan holds login credentials and real responses from your app, so data handling deserves the same scrutiny as the findings.
Why this matters
A scan is not just a list of bugs. To test behind a login, the tool needs working credentials or tokens. To prove a finding, it records full requests and responses, which may include session cookies, personal data in test accounts, and error pages with internal paths. Where that material goes, and for how long, is a vendor decision unless you ask.
What the tool can see
| Item | Why it is sensitive |
|---|---|
| Test account credentials and tokens | Grants access to the app |
| Full HTTP request and response bodies | May contain personal data or secrets |
| Site structure and hidden endpoints | A map of your attack surface |
| Findings with proof of exploit | Instructions for abusing a flaw |
Questions to ask
Where it runs
- Does the scanner run in your network, the vendor's cloud, or both? Which regions?
- If it runs in the vendor's cloud, what source addresses does it use, so you can allow them?
What it stores
- Which parts of scan traffic are stored: headers, bodies, screenshots, cookies?
- Can you mask or exclude sensitive fields before storage?
- How are credentials stored, and can you use short-lived tokens instead of passwords?
Who can read it
- Which vendor staff can see your scan data, and under what conditions?
- Can you restrict access inside your own team by project or role?
- Does any scan data feed a model or analytics? If so, can you opt out?
How long and how to delete
- What is the retention period, and can you set it?
- Can you delete a scan and its stored traffic on request, and how do you confirm it?
- What happens to your data when the contract ends?
Evidence and trust
- What independent audits or reports does the vendor have, and what do they cover? Ask for the document, read its scope and dates, and do not assume a badge on a web page means more than it says.
- How are you told if there is an incident involving your data?
How to use the answers
Write answers in a table with a column for the vendor's response and one for your risk rating. Anything you cannot get in writing counts as unknown. Unknown on credentials or retention is a reason to pause the trial, not to push ahead.
Reduce exposure in any case
- Use a dedicated test account with minimal rights, never a real user.
- Use test data only, with no real customer records.
- Prefer short-lived tokens that you revoke after the scan.
- Keep the scan inside a named scope, so traffic to third parties is not recorded.
- Delete scans you no longer need.
A worked example
A team is choosing between two DAST services for a customer-facing app. They send the same question list to both and score the replies.
| Question area | Vendor A reply | Vendor B reply | Team's rating |
|---|---|---|---|
| Where scanning runs | Vendor cloud, two regions | Customer network option and cloud | B stronger for private apps |
| Credential storage | Encrypted at rest, long-lived passwords | Short-lived tokens supported | B stronger |
| Stored traffic | Full bodies kept for the retention period | Bodies can be masked | B stronger |
| Retention | Fixed period | Configurable | B stronger |
| Deletion on request | Via support ticket | Self-service with confirmation | B stronger |
| Use of data for model training | Unclear | Written statement, opt out | A unknown, so a gap |
| Independent reports | Shared on request | Shared on request | Tie, read both |
This table is a made-up illustration of the scoring method. The team does not name winners from it. They record that Vendor A left one answer unclear and ask for it in writing before the trial. Unknown answers on credentials and retention pause the trial.
Practical protections during a trial
- Use a dedicated scan account with the lowest rights that still reach the pages being tested.
- Use short-lived tokens where the app supports them, and revoke them after the run.
- Test only environments with synthetic data.
- Keep a list of every scan run during the trial, so you can ask for deletion afterward.
- At the end of the trial, ask the vendor to confirm in writing that your data has been deleted.
Reading a vendor's assurance documents
Vendors often offer an independent audit report or a trust page. When you receive one, check the following.
| Check | Why |
|---|---|
| Who issued it | An independent assessor, not the vendor itself |
| What it covers | The product you will use, not just the company |
| The period or date | Whether it is current |
| Exceptions noted | Findings the assessor recorded |
| Complementary controls | Things your side is expected to do |
A report is evidence about what was examined. It does not promise that your data is safe. Do not describe a vendor as holding an attestation unless the document says so in those words, and do not copy a vendor's claims into your own materials without checking them.
Questions for your own side
The vendor is half the picture. Ask yourself who inside your company can view scan results, whether results are shared by email, and whether screenshots of proof-of-exploit end up in chat. Scan reports are sensitive material and need access control like any other security document.
Where Safeguard fits
These questions apply to any security tool, ours included, and you should ask them of us too. For open source dependencies, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings are tracked from detection to closure and relate it to the steps above.
Quick check
Do scan reports contain secrets?
They can. Stored requests may include tokens, cookies and personal data from test accounts.
Is a vendor's security badge enough?
No. Ask for the report, read what it covers and its dates, and compare with your data flows.
Should I ask the same questions of an open source scanner I run myself?
Yes, but the answers are about your own setup: where it runs, where reports are stored, who can read them and when they are deleted.
Last reviewed: 19 October 2026.
