I need to discuss how to mitigate the risk of services which are vulnerable despite being patched (typically because they are not maintained by the vendor anymore, or because the vendor does not want to issue a patch, or for other reasons beyond control).

  • I know how to check if a machine is vulnerable (via a patch inventory system, a vulnerability scanner, ...)
  • I know where to look for details regarding vulnerabilities (OVAL, CVE, NVD, ...)

What I don't know is where to check if a given OS, service or application will be vulnerable despite being patched and hardened, because of a vendor's decision.

An example would be Windows Server 2003 which is not maintained by Microsoft anymore and may be vulnerable to Windows-wide vulnerabilities discovered after the EOS. Having this knowledge, it is easier to prioritize the contingency in order to mitigate the risk.

Is there such a resource available?

2 Answers 2


It depends upon the vendor, and it may rely upon inference. That is why we use vulnerability scanners, and why vulnerability scanners err on the side of assuming guilt given unclear evidence.


At least one vendor, Red Hat, maintains a vulnerability-to-CVE mapping database, where they list all CVEs that apply to software in their distribution. The detail pages will discuss what the status of their software with respect to that vulnerability is:

  • Not vulnerable in the configuration distributed by RedHat (see CVE-2015-0202)
  • Addressed by Red Hat Security Errata (RHSA) (see CVE-2015-0192)
  • Not considered significant enough to patch by Red Hat (see CVE-2014-2532 for RHEL 5)

So, if you're running Red Hat, you're good. Take the CVEs you're worried about and you can look them up and see what they've done. Most vendors are not this organized, however. (See also Life-cycle of a Security Vulnerability).

Some vendors also have a habit of releasing certain fixes to paying support customers only, sometimes even only upon specific request. You can imagine how that complicates this research.


Because MITRE tries to track vendor announcements related to CVEs, it may be possible to determine which issues a vendor has addressed by looking at the "External Source" references within a CVE. For example, reading the details for CVE-2015-0202, we can see that OpenSuSE and Mandriva have links. The OpenSuSE link describes their patched update version (and the Mandriva link is broken). Red Hat is not linked in here; as we saw above, they are not vulnerable, so absence from this list isn't proof of vulnerability.

MITRE also maintains CVE Reference Key/Maps. For example, the Map for Source MS, provides a very neat and organized map of CVE to Microsoft patches. But, as with everything else,

Note that the list of references may not be complete.

Vulnerability Scanners

Trusting people to keep databases updated and published is, shall we way, fallible. Which is why we use vulnerability scanners to verify. Vulnerability scanners are also fallible - most specifically, tests that are keyed off of limited information (like service banner version announcements) will often fail. Let's say OpenSSH-2.3.4 is vulnerable to CVE-2002-1234, which is patched in OpenSSH-3.4.5. Red Hat may take the security patch specific to that vulnerability and backport it, creating OpenSSH-2.3.4p2, which will still announce itself as OpenSSH-2.3.4 in the service banner. Since the scanner is keying off the version and not actually exercising the bug to prove it's there, it will consider the system vulnerable.

When the scanner does that, we have to go research the issue with all the items found above and prove that it's not actually vulnerable.


For the obvious reasons, Vendors don't provide a neat list of stuff they chose not to patch. Honestly, if they cared enough to track that for you, they'd probably care enough to fix the issues, too. But, by itself, all such a list would do is explicitly make them look bad, so there's not much motivation to do so.

We can make do with what they do provide, and we can infer things when we research and are unable to find proof of patch availability. These are not exact solutions. That being said, I remember life before the CVE database got started, and we're a lot better off than we used to be.

  • I will give up then (and accept your answer) :) I use vulnerability scanners for years and am also from the pre-CVE era - so I get all your points. All this assumes that I will have a server to scan (which will show that it is vulnerable) but won't help to answer the question in principle (without actually assessing the server, but by merely looking up if, for a given version, it is invariably vulnerable). Thanks.
    – WoJ
    Jul 22, 2015 at 13:36
  • I feel your pain @WoJ - I've used custom databases to track vulnerable software issues, I used to go to SecurityFocus for drilldowns on software, but it all comes down to how much time you can sink into something that isn't useful unless someone is sinking near-infinite time into it :). It's just hard to maintain a database of negative inferences.
    – gowenfawr
    Jul 22, 2015 at 13:39

This is exactly what vulnerability scanners do. They just aren't great at it (none I've ever seen detect ALL unsupported software, and I doubt they will any time soon!).

Generally all vendors have their own way of disseminating this information - if they do at all - which is a major pain for asset owners and security specialists. For vulnerabilities themselves I find CVE's to be a great resource (through the NVD website for example) but it does not cover support. I'm not aware of a central repository for this information.

the CVE Details website is great resource for searching specific version numbers for known vulnerabilities. However in this context "unsupported" is not one of them.

One example I can think of here about "vendor decision" is CVE-2015-0008/MS15-011 which remains unpatched on Server 2003 even though it was supported at the time.

  • I mentioned vulnerability scanners in my question, as well as sources for information on vulns. I do not want to scan for vulnerabilities, I want to know, in principle, which services will be vulnerable.
    – WoJ
    Jul 22, 2015 at 13:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .