Are device makers reporting vulnerabilities? Not usually. Should they be? Of course!

One of my biggest eye-opening experiences of 2022 was when Tom Pace of NetRise described to the SBOM Forum (a group I lead) a maker of networking devices used by the military and critical infrastructure, which has never reported a single vulnerability for any of their devices – so naturally, a search on one of their devices in the NVD will leave many users with the impression that their devices are all vulnerability-free!

Unfortunately, the reality is different: Just a single device that Tom’s company examined likely had at least 40,000 unpatched vulnerabilities in components included in the device’s firmware. Of course, I was full of righteous indignation at this supplier (whose website doesn’t even mention “security” or “vulnerability”). How dare they shirk their obligation to report vulnerabilities to CVE.org (which is where the NVD, as well as any other database that uses CVEs, learns about its vulnerabilities)? After all, I’m sure (or was sure at the time) that all major intelligent device manufacturers (and software developers) diligently report all their vulnerabilities to CVE.org.  

Since a lot of people who work with vulnerabilities all the time don’t understand how they get into a vulnerability database (and I didn’t, until about a year ago), I’ll give a brief summary:

1.      CVE.org is part of DHS and is funded by CISA. It is staffed by the MITRE Corporation and used to be known just as “MITRE”. However, it is now run by an independent board which includes representatives of private organizations, CISA, NIST (which runs the NVD), and MITRE.

2.      New vulnerabilities are usually identified by the developer of a software product in their own software. If the developer is what’s known as a CNA (see the CVE.org website for a discussion of CNAs), they will be able to write up the CVE report and submit it to CVE.org. If they aren’t a CNA – and only about 200 organizations are CNAs; becoming a CNA requires training – they can go to a CNA for help if the CNA’s “scope” includes them. For example, Red Hat (a longstanding CNA) will help any open source project (I believe); GitHub will help any GitHub project; there are country- and industry-specific CNAs; etc.

3.      If a developer that wants to report a new vulnerability doesn’t think that their organization can be served by any of the CNAs, they can always approach MITRE directly (through CVE.org, of course), since they are the “CNA of last resort”. The CNA will help the developer (or device manufacturer) create the CVE report. The report will include information on the affected product, but not a CPE name; that name will be assigned by the NIST people later.

4.      The report is submitted to CVE.org and if approved, it will be passed to the NVD, where it automatically becomes part of the database. Around 20,000 new CVEs were identified in 2022.

5.      When the CVE report reaches the NVD, someone on the NIST team that runs the NVD will assign a CPE name to the product. Unfortunately, they don’t always do it correctly and the product becomes hard (if not impossible) to find in the NVD; the developer is left to apologize to their customers for NIST’s mistake. One of the changes the SBOM Forum has discussed with NIST is allowing the developer to assign the CPE name themselves.

Currently, there won’t be a CPE name for any product for which a CVE report hasn’t been submitted; that is, NIST currently only creates a CPE name when a vulnerability is reported for the product. This in itself wouldn’t be terrible were it not for the fact that, when a user creates a CPE name (following the specification) for a product they want to learn about and enters it on the search bar, they will receive the same message - “There are 0 matching records” - if no CPE exists with that name (which will be the case if the manufacturer has never reported a vulnerability for it, or if the NIST person made a mistake when they created it) as they will if the name is valid, but there are no vulnerabilities reported for it.

In other words, the user will have no way of knowing whether the product really has no vulnerabilities (and has a correct CPE name) or whether it has 40,000 vulnerabilities, but was entered under an incorrect CPE name.

(now, back to our regular programming) When I heard Tom Pace’s presentation last year, I initially thought that intelligent device manufacturers – at least the larger ones (including manufacturers of IoT, IIoT, medical devices, networking devices, etc.) - generally do a decent job reporting vulnerabilities in their devices, since I believe that’s the case for software developers. The main evidence that software developers are doing a good job is the number of software vulnerabilities that can be found in the NVD. Aren’t device manufacturers doing the same thing?

Some are. For example, when I just searched the NVD for “Cisco ASA” (Cisco’s firewall appliance), I received 581 CPE names for different models, different versions, etc. This means that Cisco™ has reported at least one vulnerability against each of these CPE names. Of course, the CPE name refers to “adaptive security appliance software”, not the device itself.

And this is how I think vulnerabilities should be reported for devices. They should be reported for the device’s software (and firmware) as a whole, not according to the individual software or firmware products installed in the device (since most devices include at least some third-party software, not just software developed by the manufacturer itself). If instead, vulnerabilities are only reported for the individual third-party products, then the only way someone will be able to learn about vulnerabilities in a particular device is to a) be a customer, b) receive a current SBOM that lists all the software in the device (and I know of no device manufacturer that is regularly releasing SBOMs to its customers. BTW, the new FDA requirement is unlikely to change that), and c) go through the work of looking up each of the third party products in the NVD – based on the infinitesimal-to-faint hope that the supplier of each of those third party products is diligently reporting its vulnerabilities.

This week, I was quite happy when I got a chance to have a one-on-one conversation with someone I’ve known for three years, who is involved with product security for medical devices made by one of the largest medical device makers (known as “MDMs” in the industry). One of the many questions I asked him was how often they report a vulnerability for one of their devices.

I wasn’t expecting him to say they report vulnerabilities all the time, but I didn’t expect the answer I received: that they have never reported a vulnerability for any of their devices, and he isn’t even sure how to report one.

He justified that answer by saying – and I believe him – that they have never found a vulnerability that they didn’t patch, so their products haven’t had vulnerabilities. But here he was simply wrong. Few if any software developers or device manufacturers would ever report a vulnerability unless they had a patch for it. The normal procedure is that the developer discovers the vulnerability, develops the patch, then submits a CVE report (and usually a report to their customers) that lists the vulnerability but also provides information that allows the user to find the patch and apply it. If the MDM doesn’t submit anything to CVE.org, nobody will be able to learn of the vulnerability.

If this were a standalone software product, not a device, there would be no question that the developer needs to report the vulnerability (as well as the patch), both to CVE.org and to their customers, since the customers need to apply the patch ASAP. However, usually there is no way for the customer to patch a device they utilize; instead, the supplier needs to do that.

Of course, if suppliers patched vulnerabilities as soon as they appeared in the device (or at least the serious vulnerabilities), there wouldn’t be any problem. I realized that this idea is unrealistic, since device manufacturers can’t be expected to push out each patch the day they create it. I assumed they push out monthly updates – which is probably frequent enough to catch all but the most severely exploited vulnerabilities before the bad guys can get into the device.

However, I asked my friend how often they update their devices, and was amazed to hear it was usually once a year. In other words, even if the manufacturer develops a patch for a vulnerability the minute after they learn of it, their users will never benefit from that patch for an average of six months. Even worse, since the manufacturer doesn’t report the vulnerability to the NVD (and presumably not to their customers either), I’m betting that the customers wouldn’t be pleased as punch to learn there was an important vulnerability in the device they rely on, but it won’t be fixed for six months (and remember: the devices my friend secures are used for sometimes life-sustaining patient care. They’re not baby monitors). In addition, no organization considering buying the product will be able to learn about this unpatched vulnerability before they buy it.

I’ll stop here and let you contemplate this situation. By the way, do you or a loved one have any surgery scheduled? Just wondering.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.