When a buyer's scan flags your product, reply within a day with a triage summary: which findings are real, which are false positives or unreachable, which you will fix and when. Attach evidence for each claim. Do not dispute the whole report, and do not accept every line without checking.
Why this happens
Some enterprise teams scan the vendor's public surface or a trial environment before signing. The tool they use may not know your code. It sees versions and banners, and it reports every match it can find. Raw scanner output is often long, and a first reading by a startup can feel alarming.
The reviewer usually expects a response, not silence and not a fight. How you respond tells them more than the report does.
A triage method
- Group the findings. Merge duplicates, since one library can appear dozens of times.
- Verify each group. Is the component really present, and in the version stated?
- Check reachability. Is the vulnerable code path used in your product?
- Check for a fix. Is a patched version available and compatible?
- Decide the action. Fix, mitigate, accept with an exception record, or reject as false positive.
| Outcome | What to send |
|---|---|
| Confirmed, fix ready | Fix date, ticket reference |
| Confirmed, not reachable | Short analysis of why, plus a review date |
| False positive | Evidence, such as the actual version or a build artifact listing |
| Confirmed, no fix | Mitigation and exception record |
Wording the reply
Keep it factual and short. For example: "We reviewed the 62 findings. Nine map to the same library. Four are confirmed and scheduled for the next release. Thirty are in test only code that is not shipped. The remainder are false positives because the scanner read a banner, not the component. Evidence attached."
Avoid claims such as "none of these matter." Say what you checked and how.
Remember that an exploited vulnerability deserves faster treatment. CISA publishes a catalog of known exploited vulnerabilities and advises using it as an input when you prioritise. If a flagged item is listed there, treat it as the top of your list, whatever your usual severity order says.
What not to do
- Do not argue about severity labels without evidence.
- Do not claim a finding is fixed before it is deployed and rescanned.
- Do not hide the unflattering items. Reviewers sort by what you left out.
- Do not send your internal scan wholesale, which may expose unrelated detail.
Turn it into a process
Add a standing template for buyer scan replies and keep a record of past replies. After you reply, rescan and send a short confirmation when fixes ship. Also feed any false positive pattern back into your own scanner configuration so your internal results are cleaner.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out once reachability is considered, which is the step that makes a long buyer report manageable.
Safeguard provides reachability analysis and dependency scanning. A free scan lets you see your own list before a buyer does.
Quick check
Should we reply before we finish triage?
Yes, with an acknowledgement and a date for the full reply. Silence is read as avoidance.
Do we have to fix every finding?
No. Fix or mitigate what is real and reachable, record exceptions for the rest, and explain false positives with evidence.
Sources
Last reviewed: 19 October 2026.
