Send a triaged report instead of raw scanner output: findings grouped by severity, with exploitability, fix status and dates. Raw exports are noisy, hard to interpret and can expose unpatched detail. Share them only when a named reviewer has a real need, under confidentiality terms and with expiry.
Why raw results cause trouble
A raw scan dump lists everything a tool noticed. Many entries are not exploitable in your product, some are duplicates, and some are false positives. A customer who runs down that list item by item will send you hundreds of questions, most of which you can answer with one sentence of context that the raw file lacks.
Raw output also contains detail you may not want to circulate: exact versions, internal paths and findings you have not yet fixed.
What a triaged report looks like
A useful report answers the questions a customer actually has:
| Column | Purpose |
|---|---|
| Finding or advisory ID | So they can look it up |
| Component and version | What is affected |
| Severity | Standard rating, with the source named |
| Exploitability in your product | Reachable or not, with a one line reason |
| Status | Fixed, mitigated, not affected, in progress |
| Date and target | When it was assessed and when it will be fixed |
Add a short summary at the top: how many findings, how many fixed, how many open and when you will fix them. Include the scan date and tool category, so the reader knows how fresh it is.
Exploitability statements
The step that removes most noise is stating whether a vulnerable component is actually used in a way an attacker can reach. A machine readable exploitability statement, such as VEX, can carry that. See the anatomy of an OpenVEX document for an example, and remember to attach evidence for each "not affected" claim so it can be checked.
When to share the raw export
Raw data is legitimate in a few cases: a customer's security team wants to reproduce your results, a contract requires it, or an auditor asks for evidence of scan coverage. In those cases:
- Confirm who will receive it and why.
- Filter out anything outside the product they use.
- Remove sensitive detail they do not need.
- Share by named, expiring link. See how long a share link should last.
- Add a cover note explaining how to read it and how you triage.
If the customer runs their own scanner on your SBOM and sends findings back, the same principle applies in reverse. See customer scanned your SBOM and sent findings, how to reply.
Try it yourself
This demo shows a vulnerability list being managed and prioritised. Look at how severity and status columns turn a raw list into something a customer can act on.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's reachability analysis helps separate findings that can actually be hit from those that cannot, which is the core of a triaged report. You can see it on a free scan.
Quick check
Does refusing raw results look evasive?
Not if you offer a clear alternative. A triaged report with dates and statuses is usually more useful, and you can add a supervised walkthrough.
Should the report include false positives?
List them as "not affected" with a short reason if they appeared in a customer's scan. Otherwise leave them out of the summary.
Last reviewed: 19 October 2026.
