How do I answer: do you have any known exploitable vulnerabilities?

Do not answer yes or no. Define the terms, give a dated statement, and offer evidence. Say how often you scan, which known flaws are present, which of them an attacker could actually use in your product, and how fast you fix those. A claim of "zero vulnerabilities" is almost never true and hard to defend.

TL;DR

• The question hides three different questions: known, exploitable and exploited.
• A good answer defines each word, gives a date, and states a process and a result.
• Never claim "zero vulnerabilities." Say what you check, what you found, and how you decide.
• Keep evidence ready: scan dates, exploitability decisions and fix times.

Definition: known exploitable vulnerability. A flaw that is publicly documented (known) and that an attacker could use against your product as it is set up and run today (exploitable). It is different from a flaw that is merely present in a software package, and different from one that is confirmed to be used in real attacks (exploited).

Why is this question hard to answer?

Customer security questionnaires often include a line like "Do you have any known exploitable vulnerabilities in your production environment?" It looks like a yes or no question. It is three questions in a trench coat.

"Known" could mean any flaw with a public record. Any real product has some. A modern software product can include hundreds of packages, and scanners may list flaws against many of them, including flaws that cannot affect you.

"Exploitable" could mean "an attacker could use it against us today." That depends on your code and setup. A flaw in a function you never call is present but not exploitable in your product. The group behind the OpenVEX format says the same from the scanner side: software is often not affected even when a scanner flags it, because the component may be already patched, may not be present, or may not be able to run.

"Exploited" could mean "attackers have used it in the real world." The US agency CISA keeps a Known Exploited Vulnerabilities (KEV) catalog of flaws it has seen exploited in the wild, and asks organizations to use it as an input to prioritization.

If you answer "no" and a scanner later finds a flaw, you may be seen as having misstated. If you answer "yes" without context, the buyer may think you are careless. Both answers lose useful information.

What does a good answer contain?

A good answer has five parts, in plain words.

1. A definition. State how you read the terms. "We read 'exploitable' as a flaw an attacker could use against our product as it is deployed today."
2. A process. Say how often you scan, what you scan, and how you decide what is exploitable. A scan of your dependencies on every build and a rescan on a schedule is a typical statement, if true.
3. A result with a date. "As of 19 October 2026, our latest scan listed 212 known flaws. Of these, 9 were judged exploitable in our product, 0 were on the CISA KEV catalog." Dates matter because the answer will be stale within weeks.
4. A response commitment. "We fix exploitable critical flaws within our internal target of X days." Write a time you actually meet. Do not copy a number from a standard unless it is your own policy.
5. An offer of evidence. "We can share a summary of our scan and our exploitability decisions under the terms of our agreement."

The numbers in step 3 are invented for illustration. Use your own.

How do you work out the real numbers?

Before you write a word, collect four facts. The first three come from a scan and the last from your decisions.

Fact 1: the count of known flaws. This is the raw number from your latest scan of the production build. It is the largest number and the least meaningful.

Fact 2: how many are exploitable in your product. This is the number after you apply your own checks: is the vulnerable function called, can outside input reach it, are the needed settings on. Reachability analysis is a method for the first of these checks. Record the decision for each flaw you exclude, with a reason.

Fact 3: how many are on the KEV catalog. Check each flaw against the catalog, which is available as a downloadable file. A listed flaw gets special care. If a KEV flaw is present, you should be ready to say what you did about it.

Fact 4: how long fixes take. Look at your own history. How many days passed between a finding and a fix for exploitable flaws over the last quarter? Use the real figure, or a range, not a target you have not met.

Here is a worked example with invented numbers.

From these, the written answer might read: "We scan our production dependencies on every build and rescan weekly. As of 19 October 2026 the latest scan listed 212 known flaws. We judged 188 not exploitable in our product, each with a recorded reason, and 15 are under review. Nine are judged exploitable and are scheduled with owners. None is on the CISA Known Exploited Vulnerabilities catalog. Over the last quarter our median time to fix exploitable flaws was 6 days. We can share a summary of our exploitability decisions under our agreement."

That answer is honest, specific, and checkable. It does not claim perfection. It shows control.

What mistakes should you avoid?

• Do not claim zero. If a scanner lists any flaw, "zero" will be tested and may fail.
• Do not hide the "under review" group. An honest "in progress" is better than a surprise later.
• Do not claim a certification or a standard you do not hold. Describe your process instead.
• Do not copy a deadline you do not meet. A promise you break is worse than a longer promise you keep.
• Do not let the date go stale. Add "as of" and update the answer on your next review.
• Do not send raw scan output. It is long, noisy and may reveal details you do not want to share. Send a summary and offer more under your agreement.

For contract wording, have your own security lead and legal counsel review the final text. This post is general information and not legal advice.

How do you keep the answer ready?

Create a one page "vulnerability statement" that you update after each scan. It has the date, the four facts, and links to your evidence. When a questionnaire arrives, copy from the statement. When a customer asks a follow-up, the evidence is already there.

Some suppliers go a step further and publish status statements for particular flaws, saying whether a product is affected. OpenVEX is one format created for this purpose. It is designed so a supplier can tell users about the applicability of a flaw to a product. You do not need to adopt it to give a good questionnaire answer, but it shows the direction: decisions that others can read.

What can Safeguard do to help?

Safeguard scans your dependencies, builds an SBOM, and runs reachability analysis, which traces your call paths into vulnerable functions, so the count of flaws that can be reached is a real measured number. Its vulnerability management view gives one queue per product, with signals such as known exploitation and a status for each finding, and zero-day discovery matches new advisories to your versions. Compliance and evidence automation can help you collect and organize the evidence you share, though it does not make any claim of certification for you.

Autonomous remediation with fix pull requests exists, off by default with every category on Manual. You can try a free scan at gold.safeguard.sh/scan.

For related reading, see how to read a scan report and reachability analysis questions and answers.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how findings for a product sit in one queue with the signals that set priority and a status for each, which is the kind of view that feeds a dated answer.

Quick check

Sources

• OpenVEX specification repository
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: CVSS v3.1 user guide

Last reviewed: 19 October 2026.