A SAST tool should let you show, for a chosen period, that scans ran on the in scope repositories, what they found, who decided what to do, and when it was fixed. Check before buying that results, dismissals with reasons and policy settings export in a durable form with timestamps.
What auditors tend to want
Requirements differ between frameworks and between auditors, so ask yours what they will accept. In general they look for the same four things.
- Coverage. Which systems are in scope, and proof they were scanned.
- Cadence. Evidence that scans happen on a regular basis or on each change.
- Handling. What happened to findings: fixed, accepted, dismissed, and by whom.
- Governance. The policy that says what must be fixed, and evidence it was followed.
A screenshot of a dashboard on the audit day is weak. A dated export with consistent fields is better. A set of exports covering the whole audit window is strongest.
What to ask the tool to export
- A list of scanned repositories with the date of the last scan for each.
- Scan history with timestamps, tool version and rule set version.
- All findings with status, first seen date and resolution date.
- Dismissals and accepted risks with the reason, the approver and the date.
- Pull request check results for a sample of merged changes.
- Policy and gate configuration, with change history.
- Audit logs of who changed settings or rules.
Ask how long the tool keeps this data. If the retention window is shorter than your audit period plus a margin, export to your own storage on a schedule.
Evidence quality questions
Can a person change a past record? Evidence that can be edited without a trace is worth less. Does the tool record who dismissed a finding? Are exports complete, or sampled? Can you produce the same report again next quarter in the same format?
Also ask about format. A machine readable export in a standard format such as SARIF travels well, while a PDF only report is hard to check or combine.
Mapping to frameworks
Many teams keep a simple table linking each control or requirement to the evidence that supports it. Your static analysis exports will usually support a secure development or vulnerability handling item. Do not claim more than the evidence shows. A tool run on half your repositories supports a statement about half your repositories.
Be honest in the gaps
If some repositories are excluded, say so, with the reason. Auditors generally react better to a known and documented gap than to one they find themselves.
Avoid overclaiming
A scanning tool is evidence of testing, not proof that code is secure. Phrase statements accurately: we run static analysis on every pull request for these repositories, and findings above a stated level are fixed or formally accepted. Do not write that scans guarantee absence of flaws.
Try it yourself
Click through it at your own pace, or open it full screen. See how one piece of evidence can support several framework requirements.
Quick check
Is a dashboard screenshot enough?
Rarely. Prefer dated exports covering the whole audit period, with approvers recorded for dismissals.
How long should I keep scan evidence?
At least your audit period plus a margin. Ask your auditor, and export on a schedule if the tool's retention is shorter.
Safeguard's compliance and evidence automation is generally available, as are policies and gates. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
