You can learn a surprising amount from public sources before sending a single question: the vendor's security and trust pages, published advisories, any listing in CISA's exploited vulnerabilities catalog, its status history, its public terms and how it communicates. These show posture and habits, not proof.
Where to look
| Source | What it shows | Limit |
|---|---|---|
| Security or trust page | What the vendor chooses to state | Claims, not proof |
| Published advisories | How it discloses and fixes flaws | Only what it publishes |
| CISA KEV catalog | Confirmed exploitation of its products | Misses unexploited flaws |
| Status page history | Availability and incident communication | Self reported |
| Public terms and privacy policy | Data handling commitments | Can differ from the contract |
| Subprocessor list | Who else touches your data | Often not dated |
| Vulnerability disclosure page | Whether researchers have a way to report | Existence is not responsiveness |
Steps
- Read the security page and note which statements are specific, such as named reports with dates, and which are generic.
- Look up advisories. Compare dates of disclosure and fixes where both are shown. Fast, clear advisories are a good sign.
- Check the CISA catalog for the vendor and product. See how to check a vendor against the KEV list.
- Scan the status history for outages and how they were explained.
- Read the privacy policy and terms for retention, transfers and subprocessor handling.
- Look for a disclosure contact. Many organizations publish a security contact file at a standard location, as described in the specification for security.txt. Its absence is not a failure, but its presence helps.
- Note ownership and age. Recent acquisition or very new companies change how much weight to give claims.
What the signals can tell you
A vendor that explains incidents plainly, publishes advisories with fix versions and states its commitments in specific terms is usually easier to work with. A vendor with no public security information is not necessarily weak, but you will need to ask for more.
What they cannot tell you
Public signals will not show how the vendor handles your data day to day, whether its controls work, or how it will treat you in a crisis. They help you decide what to ask and how deep to go. They do not replace evidence.
Use the findings
Write the results into the vendor's register row with the date. Use gaps to shape your evidence request: if there is no subprocessor list, ask for one. If the status page shows repeated outages, ask about resilience. Combine with the plan in reviewing a vendor in a week.
Try it yourself
Open the vulnerability management demo and see how findings, severity and fix status are presented, which is the information you hope a vendor's advisories make easy to find.
Click through it at your own pace, or open it full screen.
Quick check
Is it fair to check a vendor before telling them?
Yes, reading public pages is normal due diligence. Do not probe their systems. Testing a vendor's infrastructure without permission is a different matter and is not appropriate.
Does a missing security page mean a vendor is insecure?
No, but it means you need to ask more questions and collect more evidence before you decide.
Safeguard's SBOM and dependency scanning can show what the software you run is made of, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
