Yes, treat vulnerability findings as confidential. They show which weaknesses exist, where, and often how old they are. Some also include file paths or code excerpts. Give them an internal classification label, limit who can read them, and set rules for sharing with auditors, customers and vendors.
Why a list of weaknesses is confidential
A finding says "this component, in this application, has this unfixed flaw". That is a short path to an attack plan. The risk grows when findings include exploit status, internal hostnames or snippets of code. It does not matter that nobody wrote a password in the report. The content is sensitive because of what it implies.
Findings also land in many places: the scanner, pull request comments, ticket systems, chat, slide decks and email attachments. Each copy needs the same care as the original.
A three level scheme
| Level | What it covers | Handling |
|---|---|---|
| Restricted | Findings with code excerpts, exploit details, internal hostnames, unfixed critical issues on public systems | Named people only, no email attachments, shared through the platform |
| Confidential | Findings per application, SBOMs with internal component names | Engineering and security, shared externally under NDA |
| Internal summary | Counts, trends, percentages, no names | Wider internal audiences, customer summaries after review |
Adjust to your own policy. The point is to avoid one flat label that is either too strict to use or too loose to protect.
Rules that make it work
- Link, do not paste. Put a link to the finding in tickets and chat, not the finding text and code.
- Strip excerpts from summaries. Reports for leadership need counts and risk, not code.
- Expire shared links. Anything sent outside should come through a link with an end date.
- Redact for customers. Share a scoped summary, not raw exports. See a customer asks for your vulnerability scan report: what to share.
- Label the exports. A file that left the platform should carry its classification in the name or header.
What to ask your scanner vendor
- Can findings be restricted by project or team?
- Are code excerpts stored, or fetched live from your source system?
- Can we turn excerpts off?
- Do integrations send full finding text to tickets and chat, or only links?
- Are exports logged?
The second and third questions matter most. If excerpts are fetched on demand, the vendor holds less.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a single finding row reveals about a system, then decide which label it deserves.
How Safeguard fits
Safeguard provides policies, gates and guardrails plus vulnerability and dependency scanning. Where findings must never leave your network, it can be deployed on-prem or air-gapped. Try the free scan to see what a finding looks like.
Quick check
Do scan findings count as personal data?
Mostly no, but assignee names and commit authors in them can be personal data. Treat that part under your privacy rules.
Is it fine to post findings in a team chat?
A link is safer than the content. Chat history is searched, retained and often shared with more people than you intend.
Last reviewed: 19 October 2026.
