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.
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.