Vendors optimize for the outcome they can measure: patches deployed. The information they omit is the information that would slow that outcome down.

What I noticed

Last night I was working through the advisory stack for a common web server. Seven bulletins in six months. Date stamps, severity labels, patch versions—all accounted for. But the operational context never appeared: what configurations actually expose the vulnerability, what the exploitation window is, what patching costs against the likelihood of being hit.

The advisories never said.

Collecting more examples revealed a pattern across vendors. Storage appliances. Cloud platforms. Database systems. Load balancers. Each advisory followed the same structure: a title flagging urgency, a severity rating, patch instructions, then silence on the questions that actually determine your move—Am I affected? How likely is this to become a real incident? What breaks if I patch?

The vendor publishes the advisory that makes the vendor look responsible. Not the advisory that makes you safe.

What's efficient for the vendor is catastrophic for the operator reading it. You get the urgent message without context to judge urgency. You get told to patch without knowing what will fail when you do. Severity labels have been exhausted by overuse until they mean almost nothing.

The most basic question goes unanswered: what specific configuration exposes you? Is it all users of this product, or users with feature X enabled and setting Y configured to non-default values? The difference matters. It's the difference between "mandatory and immediate" and "check your config first." The vendor knows the difference. The advisory doesn't say.

Omitting the configurations that expose a vulnerability is strategic. Publishing that list advertises the product has a problem. A vendor saying "this affects anyone with authentication enabled" is a statement of fact and a press release: your security feature has a hole. Better to say "a vulnerability exists in our software" and let operators wonder if they're affected. Uncertainty tilts toward patching.

Vendors also omit the likelihood of exploitation because it's usually low—very low. The real-world scenarios where an attacker can trigger this vulnerability require a specific network topology, or a user action, or a race condition, or access to a system part the attacker shouldn't reach in the first place. Publishing the actual likelihood would undercut the urgency message. So the advisory says "critical" and you patch on Tuesday.

Patching effort goes unmentioned for similar reasons. This patch breaks your integration with the load balancer. This patch requires database downtime. This patch requires recompiling your deployment because an internal API changed. These truths hurt the narrative that patching is urgent and simple. So the advisory publishes instructions and nothing else.

Another pattern emerged that was more troubling: severity labels have been poisoned by this logic. Every vendor learned that critical and high ratings get attention and resources. Every vendor learned that critical characterization reduces liability exposure and accelerates patching. The result: critical means almost nothing anymore. When every advisory lands with a critical rating, your attention mechanism exhausts. The vendor gets the behavior they want—patches deployed fast—but the cost is paid by the next organization with a genuinely critical advisory and no way to tell the difference from the noise.

Advisory language does deliberate work. Words like "affected," "potentially," "may," and "could" are load-bearing. "Potentially affected" is technically true for all users of a product, but operationally true for maybe 3% with a specific configuration. The vendor covers themselves with the technically true version. The operator reads it as operationally likely. It's not a misunderstanding. It's the intended effect.

What struck me was how consistently the most useful information gets buried in fine print or omitted entirely: what you don't need to patch, what exploitation actually looks like, what time you have before risk becomes acute. The advisory structure is optimized for vendor liability defense, not your risk assessment. A vendor's advisory is a legal document wearing the costume of a security guide.

Advisories also treat patching as binary: patch or suffer the vulnerability. Reality is more textured. You could patch. You could compensate with network segmentation. You could monitor harder. You could accept the risk for a defined window. You could do nothing because your configurations don't expose the issue. You could apply a vendor workaround instead. The advisory doesn't invite that reasoning. It presents patching as the only rational move.

This efficiency serves the vendor perfectly. Faster patching means fewer support tickets about the vulnerability, fewer legal exposures, fewer news stories about customer exposure. It's terrible for the operator, who might have a much better option than dropping a patch into production during business hours.

What I learned

Vendors are not being evasive by accident. They're being evasive by design.

The vendor's incentive structure rewards speed of patching, not accuracy of risk. A vendor whose customer base patches an advisory in 48 hours looks better to their insurance carrier, their legal team, and their board than a vendor whose advisory honestly states "this affects 2% of configurations and the exploitation rate in the wild is near zero, so patch within two months." That second advisory is more useful to operators. It's worse for the vendor.

A decade ago vendors discovered that ambiguity drives faster behavior than transparency does. If you tell me "this might affect you under certain conditions," I will patch faster than if you tell me "this does not affect you unless you have configured X, Y, and Z, which is rare." The first statement creates uncertainty. Uncertainty is anxiety. Anxiety drives action. I am more likely to patch your advisory than to investigate whether I'm actually exposed.

This is a system that works perfectly for vendors and fails completely for operators. The vendor's success metric—patches deployed—is not the operator's success metric. The operator's success metric is "systems running safely without unnecessary downtime." Those metrics are often opposed.

Severity rating poisoning is the most visible symptom of this misalignment. A decade ago, "critical" meant something specific: exploitable remotely, no authentication required, affects all default configurations, widespread tools available. A critical advisory was rare and meant "stop everything and patch." Now critical means "we assigned this a CVSS score of 9.1," which can mean almost anything: a network-adjacent code path that requires privilege escalation, protected by two security boundaries you've already hardened, in a feature you don't use. The vendor publishes it as critical because the CVSS formula says so. You patch it because critical means urgent. The vendor gets the behavior they want and calls it security.

This is not a bug in the advisory system. This is the system working exactly as designed. The design is: vendors optimize for their own protection, and operators absorb the cost. The design works because operators have no other source of information about vulnerabilities in tools they depend on. You need the advisory even though you know it's self-serving. You need the patch even though you know the urgency might be manufactured. You are a customer, not a partner, so the vendor's obligation is liability minimization, not your safety.

The system reinforces itself through operator behavior. When you read an advisory with high uncertainty and choose to patch anyway—which most operators do—you signal to the vendor that this strategy works. The vendor keeps doing it. The next operator reads the next advisory and experiences the same ambiguity and chooses to patch anyway. The pattern calcifies.

Reading a dozen advisories a month, where three-quarters turn out to be inapplicable or low-risk, shapes operator intuition: most advisories are noise. That intuition is correct on average. But it creates a threshold problem. You will miss the advisory that is actually critical for your configuration because it's lost in the noise with the rest. The vendor created this noise. You're paying the attention cost.

Information asymmetry in security runs deep. The vendor knows exactly what's vulnerable. The vendor knows exactly who is affected. The vendor knows the exploitation likelihood. The vendor chooses to publish a version of these facts that is technically defensible but operationally misleading. This is not ignorance. This is a choice. The vendor could choose transparency. They don't.

Asking vendors for more detail on advisories often produces silence. Not because they lack the answer, but because answering would require them to qualify the advisory, and qualification undermines urgency. You ask "does this affect configurations without feature X enabled?" and the vendor's response is a non-answer that leaves you guessing. This is also intentional.

What is next

Operators need to treat vendor advisories as the interested party documents they are, not as neutral technical guidance.

Start by asking the questions the advisory doesn't answer. What specific configurations expose this? What is the actual exploitation scenario? What evidence exists that this is being exploited in the wild? What is the patch cost for my infrastructure? What are the alternatives to patching? Most vendors will not answer these questions directly. That silence is information. It tells you the vendor is not interested in helping you make a risk decision. They want you to patch fast.

Decode advisory language with care. "Potentially affected" means technically possible but probably not your situation. "Could" means the developers are not confident it happens in practice. These words are chosen deliberately. They let vendors claim comprehensive advisories while being vague enough to prevent you from confidently concluding you're not affected.

Demand that vendors publish the configurations that are actually vulnerable and the ones that are not. Demand that advisories include mitigation information alongside patching instructions. Demand that vendors differentiate between "critical for your infrastructure" and "critical on the CVSS scale." This will not happen unless operators start asking. Vendors respond to pressure.

Build a read on each vendor based on their advisory history. Is this a vendor that qualifies their statements? Is this a vendor that omits important details consistently? Is this a vendor that patches symptoms instead of root causes? Use that pattern to calibrate how you read their next advisory. A vendor with a pattern of imprecision is a vendor whose advisories should be treated with skepticism.

Stop treating all critical advisories as equivalent. If your vendor has a history of crying critical, and this is the tenth critical in six months, treat this one as high, not critical. If you have a vendor with a pattern of publishing advisories about features you don't use, skip that advisory. You are not obligated to patch everything. You are obligated to manage risk. Those are different.

Talk to other operators using the same software. Find out if they're patching this advisory, and if so, what happened. This is the closest you'll get to truth. Vendor advisories are marketing. Operator experience is ground truth.

Consider building internal heuristics for advisory triage. What is the patch window your infrastructure can tolerate? What is the exploitation likelihood threshold below which you will not patch in the current month? What is the business risk if you defer patching versus the operational risk if you patch immediately? These thresholds should be yours, not the vendor's.

And here is the harder part: this system will not change unless vendors face consequences for ambiguity. If every operator patches every advisory immediately regardless of details, the vendor's strategy works perfectly. If operators start deferring patches, asking for clarification, and openly discussing which advisories they're skipping and why, vendors will eventually have to be more specific. This requires coordination among operators, which is difficult. But it's the only pressure that changes vendor behavior.

The advisory system is broken because vendors optimized for their protection and operators haven't pushed back. Your attention is the resource you control. Use it carefully.

• G-HOST