Safeguard
Security Guides•

Will your software vendor tell you when its product has a flaw?

How to make sure a vendor tells you about vulnerabilities in what you bought: advisory channels, CVE quality, a disclosure policy and contract wording.

Safeguard Security Team
3 min read

Only if you arrange it. A vendor is not automatically obliged to warn customers about a flaw. Ask which channel carries security advisories, whether it files accurate CVE records, whether it runs a disclosure policy, and add a contract clause that names a notice period and a contact on your side.

The three channels you want

1. A direct security notice. An email list or portal alert that goes to a named security contact at your organization. Not the invoice contact, not a general support queue.

2. A public advisory. A page the vendor keeps current, with affected versions, fixed versions and workarounds. This is what your scanners and your own analysts will read later.

3. A CVE record. A standard identifier lets every tool and every analyst talk about the same flaw. CISA's Secure by Demand guide asks whether the manufacturer files timely and correct CVE records, with accurate weakness (CWE) and platform (CPE) fields. Wrong platform data means your scanner may never match the flaw to the product you run.

Why disclosure policy is a buying signal

The same guide asks whether the vendor publishes a vulnerability disclosure policy that authorizes public testing of its products. A vendor with such a policy gives researchers a legal route to report flaws. A vendor without one often learns about problems from the news.

You can check this before purchase in a few minutes. Look for a security contact page, a disclosure policy and a history of advisories. An empty history is not necessarily good news. It may mean the product is small, or that flaws are fixed silently.

Clause checklist

  1. Name a security contact on your side and a way to change it.
  2. Require notice of any vulnerability affecting the version you run, with a stated deadline from the vendor becoming aware.
  3. Require the notice to include affected and fixed versions, a severity statement and any mitigation.
  4. Require notice if the vendor has evidence the flaw is being exploited, even before a fix exists.
  5. Require advisories to name the dates of report, fix and disclosure, so that you can audit the vendor later.
  6. Say that notices go out whether or not a CVE is assigned.

The notice period in the clause is your call. Pick one that your team can act on, and have your counsel check the wording.

What to do when the notice arrives

A notice is the start of your work. Check the affected versions against your inventory. Check whether the flaw is on a known exploited list. Decide on a mitigation if no fix exists. Our patch SLA clause guide covers how to rank it.

Try it yourself

Click through it at your own pace, or open it full screen. See how new advisories surface and what you would check first.

Safeguard offers zero-day discovery and continuous monitoring on your own estate, so you are not relying on a vendor email alone. It does not replace the vendor's duty to notify you.

Quick check

Is a public advisory enough?

No. Public pages are easy to miss. Ask for a direct notice to a named contact as well.

Why do CVE fields matter?

Scanners match flaws to products using those fields. Inaccurate entries can hide a flaw from your tools.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.