Share a redacted summary rather than the raw scanner output: scope, date, method, counts by severity, how you triaged findings and your plan for open items. Keep hostnames, internal paths, package names that reveal unreleased work, and anything exploitable out. Offer a call for detail if the customer needs it.
Why not send the raw file
A raw report often lists internal repository names, file paths, endpoints and the exact versions of components with open issues. In the wrong hands that is a map. It may also contain findings you have already judged unreachable, which can read as alarming without context. A summary controls both problems.
What the summary should contain
| Section | Content |
|---|---|
| Scope | Which products, repositories and environments were scanned, and what was not |
| Date and method | When it ran, what kind of scan, how often it repeats |
| Result counts | Findings by severity, with open and closed numbers |
| Triage | How you decided what matters: exposure, reachability, fix availability |
| Open items | A short list, anonymised, each with an owner and target date |
| Closed items | A few examples showing fix dates, to prove the loop works |
Step by step
- Run a fresh scan so the date is recent. Do not send a three month old file.
- Export the results and strip anything internal: hostnames, paths, secrets, ticket links.
- Re-label findings by category and severity instead of by internal names.
- Add your triage notes. For each high severity item, say whether it is reachable and what you are doing.
- Have the technical verifier check the numbers against the source.
- Have an approver read it for overclaims before it leaves.
- Send through a controlled channel and log the recipient.
Be honest about open findings
A report with zero findings makes reviewers suspicious, because nearly every real project has something. A report that shows a managed backlog, with owners and dates, demonstrates the thing the customer actually wants to see: that you notice and act. Never edit a finding out of the summary to look cleaner.
Scope statements prevent trouble
Say plainly what was covered. "Dependency scan of the production web application and API repositories as of this date" is accurate. "Our software is free of known vulnerabilities" is not, and it will not be true next week when new advisories land.
If they ask for a penetration test report
That is a different document with different sensitivity. Share a summary letter or an executive summary if you have one, under your confidentiality terms, and do not improvise. This article is not legal advice, so check contract language with counsel.
Refresh rhythm
Rerun and refresh the summary on a regular schedule, and keep the last few versions. Your next customer will ask for the same thing.
Try it yourself
Open the vulnerability management demo and look at how findings are grouped, prioritised and tracked to closure. Notice which fields you would put in a customer summary.
Click through it at your own pace, or open it full screen.
Safeguard can run dependency scanning and export results with dates, and you can see a sample result with the free scan at https://gold.safeguard.sh/scan.
Quick check
Is it ok to send the vendor PDF directly?
Usually not without redaction. Check it for internal names, paths and anything that could help an attacker.
What if we have critical findings open?
Share them in anonymised form with the mitigation and target date. Hiding them is the larger risk.
How recent should the scan be?
Recent enough that you would stand behind it today. A scan from the last few weeks is a sensible default.
Last reviewed: 19 October 2026.
