300 million!

Note from Tom 4/27/2023: I haven't received any updates on these numbers since I wrote the post below, but it's safe to say that the number is well over 300 million now. 

Last April, I put up a post about the fact that Steve Springett’s Dependency-Track was being used 200 million times a month to look up components listed on an SBOM in the OSS Index open source vulnerability database; last fall, I updated that number to 270 million. So I was quite pleased today to hear from Steve that the number is now a nice round 300 million per month. In other words, use of Dependency-Track is growing more than 50% a year.

Of course, the point of my post wasn’t so much to laud Dependency-Track (although I do want to point out that D-T just celebrated its tenth birthday. This is quite interesting, because just about nobody was talking about SBOMs ten years ago). Rather, it was to show that SBOMs, even though they’re currently being used almost exclusively by software developers for product vulnerability management purposes (and there are many other tools like Dependency-Track, that are also being heavily used), clearly are needed just as much by their customers.

But the customers aren’t asking for them. Why aren’t they?

Good question…

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.

Do we need regulations to have SBOMs?

In the SBOM Forum meeting last Friday, we had a lively discussion – nay, argument – on a question that frankly surprised me: Will it take regulation to make SBOMs widely distributed and widely used by private and government al organizations whose main business isn’t software?

It’s quite clear that SBOMs are being widely used by software developers for their own product security purposes. However, it’s also clear that SBOMs are not being widely – or even narrowly – distributed to non-developers[i]. And, while there are certainly a lot of suppliers who don’t want to distribute SBOMs, there are also a lot of users who would like to utilize the information that SBOMs provide, but have no idea how they will be able to get that information from an SBOM when they receive it. This is because there aren’t any low-cost, commercially supported tools (or really any tools at all) that ingest both SBOMs and VEX information and output lists of exploitable component vulnerabilities in a particular product and version.

In the meeting on Friday, a number of well-known, very experienced people in the SBOM space were telling me that SBOMs won’t really be distributed until suppliers are forced to do that by regulations. However, those people say that regulations are right around the corner, so SBOMs are also surely right around the corner.

I frankly don’t know what these people are talking about. I’m optimistic that within two years there will be substantial distribution and use of SBOMs. However, it won’t be due to regulation. It will be due to – dare I say it? – the operation of the free market. Simply put, it will be due to organizations that use SBOMs deciding that a) they want to have the information that can be gained from SBOMs, and b) the tools and/or services needed to obtain that information are readily available to them (which they aren’t now).

Here is why regulations aren’t coming (or at least not in anywhere near the volume or strength required to make a difference), and also why they wouldn’t be needed, even if they were coming:

1.      I, like everyone else involved with SBOMs, thought Executive Order 14028 would be a game changer; it certainly did change the game in terms of awareness of SBOMs. But the date for compliance with Section 4(e) of the EO (which includes the SBOM provisions) was set by OMB for August 10, 2022. On that date, government agencies were supposed to start requiring SBOMs from their suppliers. I haven’t heard of any flood of SBOMs after that date, have you?

2.      After that date passed, expectation grew for OMB’s EO implementation memo in September. But that memo, when it appeared, required every agency to…decide for themselves what if anything to do about SBOMs. Not exactly a game-changer, IMHO.

3.      The memo does require an attestation from the supplier about their software development practices (including SBOMs), but if the supplier attests that they will produce an SBOM and don’t do it, or if they just attest that they won’t produce one at all, there’s no mechanism for an agency to force the supplier to do this. And if an agency were to even consider terminating a relationship with a supplier due to failure to produce an SBOM, the supplier will simply say, “Please show me where in our current contract it says we’re required to produce SBOMs.”

4.      Indeed, the EO did call for changes in the Federal Acquisition Regulation (FAR), which would be required in order to change new contracts. I haven’t heard anything about any changes in FAR being implemented (and I don’t know whether they require Congressional approval if so). And even when the FAR is changed, remember that would only apply to new acquisitions, not to any current contracts. Of course, federal contracts with suppliers are usually multiyear, meaning it will be years before any changes will be implemented due to the EO.

5.      So – and I should have realized this initially – there’s simply no way that the EO is going to make any real difference in SBOMs, unless federal agencies decide they really need SBOMs (or at least data from them) and do more than just ask meekly for an SBOM – then move to the next topic when the supplier says no. In other words, it will be demand from consumers – the agencies – that will drive federal use of SBOM data. The EO certainly will have played a big role in inspiring that demand, but it won’t be the reason that SBOMs are being distributed and used.

6.      If not from the EO, where is federal regulation going to come from, which will force suppliers to provide SBOMs to their users? Of course, there’s the FDA, which was empowered by Congress in December to require medical device manufacturers to meet cybersecurity requirements – including one for SBOMs – in order to be approved to market their devices in the US. In the SBOM Forum meeting, several people pointed to this as a reason why there would soon be a lot of regulations – i.e., other agencies would rush to jump on the FDA’s bandwagon.

7.      But this development isn’t new news. In 2017, the FDA put out a memo saying they intended to require SBOMs (and other cybersecurity measures, to be sure) in the future, without giving a date. The December Omnibus bill finally gave them the authorization to do that. But if other agencies were going to jump on that bandwagon, they would have done it years ago.

8.      However, what other government agency could jump on this bandwagon? It would have to be one that currently has the power to regulate suppliers, for anything other than product safety. The Nuclear Regulatory Commission (or one of the other nuclear power agencies – there are a few) is one. The military and intelligence agencies are certainly another. Is there any other? Not that I know of. In other words, currently there’s no authority for any government agency to require anything besides product safety of the suppliers of any industry outside of nuclear power or the military/three-letter agencies. Where are all these requirements for SBOMs going to come from?

9.      A supplier to critical infrastructure brought up that sector (or sectors) as a likely subject of mandatory SBOM requirements soon. But what agency is going to promulgate those requirements? Remember, the agency would need to have responsibility for the suppliers to an industry, not just the members of the industry itself. A good illustration is the NERC CIP-013 supply chain cybersecurity standard, which came into effect in 2021 and is the only supply chain security standard that I know of outside of the FDA, military and nuclear power. But CIP-013 doesn’t regulate power industry suppliers, since FERC (which provides the enforcement power behind NERC standards) has no authority at all over suppliers. The utilities are supposed to develop supply chain cyber risk management plans, a big component of which is managing vendor risk, and they can face penalties if they develop a slapdash plan, or if they don’t follow the plan they developed.

10.   Sure, the power industry suppliers have felt a lot of pressure from their utility customers due to CIP-013, and are getting their collective cybersecurity acts together; but they don’t face any direct penalties if they refuse to cooperate at all, unless the utilities take action against them like dropping them as suppliers. As with the EO, CIP-013 will only be effective if the regulated entities (government agencies in the case of the EO, and electric utilities in the case of CIP-013) demand security measures of the suppliers (of course, CIP-013 doesn’t say anything directly about SBOMs, but a utility can certainly require them if they think they’re important. To be honest, I doubt too many are doing that now, although the Edison Electric Institute did put out model contract language recently that includes a modest SBOM provision).

11.   Bottom line: If there’s going to be regulation of suppliers in the US – other than safety regulations – it will have to be from some new agency still to be created by Congress. I haven’t heard the slightest peep about that happening, have you?

However, I am quite optimistic that SBOMs will be widely used (or more importantly, that the data to be derived from SBOMs and VEX information will be widely used) within the next two years - although “widely” is relative. The total “market” for SBOMs is every organization, public or private, on the planet. Ultimately, that’s what “widely” will mean, but I won’t even guess on when that will come into existence. Fortunately, there’s lots of growth opportunity long before that outcome is realized.

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.

---

[i] The one exception being the German auto industry, whose device suppliers (the average German car now has about 50 computing devices in it) are distributing SBOMs in large quantities to the car manufacturers (known as OEMs in industry parlance). But the primary use case is license management for open source components, not software or firmware security.

“NOASSERTION”? No problem!

The NTIA Minimum Elements document contains this short paragraph (on page 12, for those keeping score at home):

An SBOM should contain all primary (top level) components, with all their transitive dependencies listed. At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.

Translated into English, this says that an SBOM “must” list all the “first level” components – meaning those that are direct dependencies of the product itself (although remember, this document is just supposed to contain suggested guidelines[i] for the federal government. Exactly what status the word “must” has in that context is debatable).

However, if we can now step into the real world, let me ask how many readers are currently receiving SBOMs from even one of their software or intelligent device suppliers, which list every one of the “first level” components (I put that phrase in quotes, since technically there’s no such thing as levels in an SBOM, but in practice everybody talks about them, including me)? And, even if the supplier swears on a stack of Bibles that every first-level component is listed, are you sure they’re telling the truth?

I didn’t think I’d see any hands, although I’ll point out that’s a trick question. After all, how many users are going to audit their suppliers to make sure they’re including all the “first-level” components in an SBOM? That’s right, nobody is – nor would it make any sense to do that. The only way you could audit the supplier would be to ask them to produce another SBOM – and then you’d have to audit that one, and then…turtles, all the way down.

But the biggest problem with this suggestion (or whatever it is), is that it’s likely to prevent many suppliers from producing SBOMs for their customers at all. After all there are some perfectly good reasons why the suppliers won’t be able to “comply” with this suggestion. Perhaps the three most important are:

First, the contents of the SBOM – including the number and identities of components - will vary depending on when the SBOM is produced: whether it comes from the source code, whether it was created during the build process, whether it was created with the final build, whether it was developed from the actual binary files distributed with the software, etc.

Because components are added, replaced or removed at each stage – and since the components in the SBOM on one day will often be different from the components you’d find the next day, if the software were still being built – the only way the suggestion could possibly have any rigorous (i.e. auditable) meaning would be if it specified exactly the circumstances under which the SBOM was created. And, if there were some way to come back and recreate those exact circumstances later during an audit, which of course there isn’t.

Second, components are notoriously hard to identify with any certainty, because of the naming problem. For vulnerability management purposes, it does the software user no good to learn that a component is found in a product they use, but at the same time not know of an identifier with which they can find that component in a vulnerability database like the NVD.

If the supplier decides to leave that component out of the SBOM (or more correctly, leave it in, but just enter “NOASSERTION” for each field describing the component. NOASSERTION is the SPDX term meaning “I have nothing to say about this field for this component”. In CycloneDX, it’s just a blank line), IMO that is perfectly understandable, and shouldn’t be held against them.

Finally, there are some suppliers (I know auto industry suppliers are a good example of this) who regard the identities of some components (even open source components) in their products as their IP, which would be jeopardized if they revealed it.

Are they correct in holding this belief? Who knows, other than the suppliers themselves?  But here’s the punch line: Would you rather receive “incomplete” SBOMs from a few suppliers or receive exactly what you’re receiving currently - zero SBOMs from zero suppliers? If you prefer the latter, then I recommend you put ironclad language in your contracts requiring complete SBOMs, as described in the Minimum Elements. And give yourself the title, “Director of SBOM Prevention”.

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.

---

[i] From the Executive Summary: “…this report defines the scope of how to think about minimum elements…” This doesn’t sound like “must” to me. How about you?

The news from NERC and CycloneDX

In 2019, the NERC Supply Chain Working Group published six guidelines on supply chain cybersecurity for systems used for the reliable operation of the North American Bulk Electric System (BES). The papers were developed by separate working groups. I led two of those groups, which produced two of the guidelines.

Last year, we updated (or started to update) all six guidelines, and I led the groups that updated both of those documents. I’m pleased to announce that one of the two documents, Supply Chain Cyber Security Risk Management Lifecycle, was just published. The other one, Vendor Risk Management Lifecycle, is finished, but has to wait another three months before it’s officially approved. In the meantime, I will be glad to send anyone who wants to see it the final draft of the document; just email me.

Two other guidelines were just published: Supply Chain Secure Equipment Delivery, led by Wally Magda of WallyDotBiz LLC and Risk Considerations for Open Source Software, led by George Masters of Schweitzer Engineering Labs. I want to point out that George is a real master of the subject of securing open source software. I know the guidelines I led are applicable to many industries, not just electric power; I’m sure this applies to the other two documents as well. So you don’t have to work for say Duke Energy to find these helpful. I can assure you a lot of work went into them!

I also want to point out that Steve Springett, Chair of the CycloneDX Core Working Group and one of the most creative (and impactful) people in the world of software supply chain security (including SBOMs, but in no ways limited to them!), will be presenting a webinar on February 1 titled Understanding and Using the CycloneDX SBOM Standard. There’s a lot going on with CycloneDX nowadays, including support for both VEX and VDR (Vulnerability Disclosure Report) – with a new version of the format coming out very soon. I’m looking forward to the webinar!

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.

SBOMs for patched software versions

One of the fundamental tenets of the SBOM faith is that the developer must produce a new SBOM whenever anything in the code of the product has changed; even if the change is just a patch being applied, there needs to be a new SBOM. I myself have repeated this teaching many times. Of course, it’s also enshrined in the Minimum Elements document.

However, a recent conversation with the Director of Project Security of one of the largest software developers in the US has changed my thinking. There’s something special about patches that makes a new SBOM almost impossible in most cases. The only real solution to the problem is for the developer to do a complete version upgrade whenever there’s been a new patch issued (or even better, they don’t issue a patch; they just require all users to upgrade. But that would mean a lot more work for both the developer and their customers).

Of course, given that nowadays there are very few developers that are issuing a new SBOM with every major version upgrade, let alone with every patch, this isn’t currently a problem. When it becomes a problem, I’ll just count it as an indication that SBOMs have truly arrived – somewhat like the “problem” that too many wealth managers will call you if you just won the lottery. We should all have such problems.

Here is what my friend said:

1.      Typically, a developer will issue multiple patches between version upgrades. The patches usually aren’t cumulative. This means that, if there have been five patches since the last upgrade, applying the fifth patch won’t also get you the previous four patches. If you want all five, you need to apply each one. Of course, when the next version upgrade comes out, you’ll receive all five patches “baked in” to the upgrade. But it’s certainly not a good idea not to patch and to just wait for the next upgrade!

2.      If the developer wants to issue a new SBOM after say the fourth patch, they need to make an assumption about which of the previous three patches were applied by the user. Of course, assuming those patches weren’t automatically applied, it’s certain that different combinations of the previous three patches may have been applied by different customers (and some customers might not have applied any of them); moreover, it would be a huge waste of time for the developer to poll their customers whenever they release a new patch, to find out which of the previous patches they’ve applied.

3.      What should the developer assume when preparing the SBOM? The only thing they can assume is that all possible combinations of the three previous patches have been applied by at least one of their customers. So, completeness requires preparing an SBOM for each possible combination of patches that might have been applied.

4.      The number of SBOMs needed is equal to 2 raised to the number of independent patches that have been issued since the last update. If there have been three patches, this means the supplier needs to prepare 8 SBOMs (2 raised to the third power).

5.      Eight SBOMs might sound doable to some people. But how many SBOM’s does the developer need to prepare if there have been five previous patches? That’s 32 SBOMs. How about ten previous patches? That’s 1,024. When you consider that the supplier would have to prepare multiple SBOMs with almost every patch they released, trying to do this would create a major burden on the supplier.

Clearly, the developer can’t be expected to produce a new SBOM whenever they release a patch, except perhaps an SBOM that assumes all previous patches were applied. So, please don’t try to force your developer to follow SBOM dogma and produce a new SBOM whenever the software changes. To start, count yourself quite lucky if the developer promises to provide one SBOM with every major version upgrade. Just that will be a lot better than the number of SBOMs you receive now, which is most likely zero.

Note: The original version of this post listed much larger numbers of required SBOMs, because of a math mistake. However, the numbers above are unacceptable as they are now; it doesn't matter that they're less than before.

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.

The big problem with securing devices

Starting in 2017, the FDA has said they intend to require SBOMs for medical devices. Early this year, they released a draft requirement for comment, saying they planned to finalize a requirement and make it mandatory by the end of the year.

However, a few weeks ago, I heard in one of the bi-weekly meetings for the Healthcare SBOM Proof of Concept (which is now conducted under the auspices of the Healthcare ISAC) that the FDA had just announced they were going to postpone enforcement of the requirement until late next year (and moreover, that they weren’t going to allow any changes to the draft requirements, even though they…ahem!...left a lot to be desired). Of course, this was disappointing, since there was a lot of agreement (including among medical device makers) that it’s important to have the SBOM requirement.

But, in the CISA SBOM Onramps and Adoption workgroup meeting this week, Josh Corman announced that the Patch Act had been passed last week in the year-end rush of legislation. This is a piece of legislation that requires the FDA to mandate cyber protections for medical devices. It had initially shown promise of being passed, but was withdrawn without a vote earlier this year. The FDA has 30 days to complete the rulemaking for this (and I hope they’ll change what they proposed last April), which seems to indicate it’s on a fast track to implementation. While the Act doesn’t specifically mandate SBOMs, it lists them as one of the measures that might be required, and the word is they will be required.

This is important for two reasons. One is that this will be the first mandatory requirement for SBOMs anywhere in the world (at least as far as I know). Of course, nobody is advocating such a mandatory requirement for every software product and device in every industry, but there are certain cases where mandatory SBOMs are justified. I would say that medical devices, which literally keep people alive in hospitals, are one of the best of those cases.

However, in my opinion the second reason is even more compelling: It’s that intelligent devices in general, not just medical devices, pose a unique cybersecurity challenge; SBOMs can play a key role in addressing that challenge.

I had never stumbled upon that challenge before I and Isaac Dangana, who works for my client Red Alert Labs (a company based in Paris that focuses on security and compliance for IoT devices), published this article in the Journal of Innovation last summer. While that article was primarily intended to be an introduction to SBOMs for people in the IoT and IIoT worlds who weren’t familiar with the concept, Isaac and I ended up pointing to a serious issue that affects the ability of a user to secure an IoT or IIoT device, or even to learn about vulnerabilities that may affect it. In fact, we ended up making the case – without intending to – that IoT and IIoT devices may currently be less secure, and are certainly much less transparent to users, than are “user-managed” software products (i.e. standard software running on Intel-standard servers).

The problem begins with the fact that IoT and IIoT devices are intentionally sealed. The results of this include the fact that users can’t identify by themselves the software products installed in the device, and they can’t update or patch any of the individual software packages in the device.

Instead, all the software in the device is treated as a single “lump” (to quote a friend who manages cybersecurity for the thousands of medical devices installed at a large hospital chain). The device comes with all the required software installed, and patches or updates to individual software products in the device are held until the next scheduled device update – at which point the entire “lump” is replaced as a unit, often at night via an internet connection.

Of course, for a network administrator who runs him or herself ragged, trying to keep up with vulnerabilities found in the hodgepodge of software products running on the servers they’re responsible for - as well as trying to apply the never-ending stream of patches to software products installed on those servers - the idea that all responsibility for vulnerability management and patching would be completely taken out of their hands and assigned to some gremlins that expect neither pay nor recognition must seem like heaven on earth.

However, this is only heaven on earth if the device user has complete confidence that the device manufacturer will:

a)      Monitor each software product installed in the device for vulnerabilities and “coordinate with” (i.e. bug the hell out of) the software product’s supplier to make sure they expeditiously patch any serious vulnerabilities in it.

b)     Require the supplier of at least every “top level” software product installed in the device to provide an SBOM for their software and update the SBOM whenever they release an update or patch for that software.

c)      Using the SBOMs, track components in each of the software products installed in the device and identify vulnerabilities applicable to each component.

d)     Require each software supplier to provide VEX notifications, which will let them know about component vulnerabilities that aren’t in fact exploitable in the product and prevent their wasting a lot of time chasing down non-existent vulnerabilities.

e)     Whenever a serious vulnerability can’t be patched immediately, provide a notification to all the customers of the device regarding mitigations they should apply to make it less likely that the vulnerability will be used to compromise the device.

f)       If one of the software products installed in the device has proved to be a “problem child”, with multiple longstanding vulnerabilities and no commitment by the software’s supplier to fix those in anything less than the remaining life of the universe, commit to replacing that software within say three months.

g)      When a software product has reached end of life status, commit to replacing it within say six months.

h)     When an open source software product hasn’t been patched or updated for say six months, admit that the product is effectively in end of life status and commit to replacing it within six months - although sooner if there are one or more serious unpatched vulnerabilities in the product.

i)       Require that the supplier of each software product installed in the device either attest they have followed every provision of the NIST Secure Software Development Framework (SSDF), or identify any provisions they haven’t followed and provide an explanation of why they haven’t done so.

j)       Etc., etc.

Of course, the device manufacturer is likely to complain lustily that they can’t stay in business if they’re really forced to do all of the above, with respect to every software or firmware product that’s installed in their device. And believe it or not, I agree that this is too much to ask of them.

However, by the same token, I say it’s too much to ask of their customers that they stay in Fat, Dumb and Happy mode, in total ignorance of any security measures that the device manufacturer took or didn’t take to secure the software within their device. If the manufacturer isn’t willing to do literally everything possible to secure the device (i.e., all of the items listed above), they should at least give their customers the information they need to learn about the measures they have taken, and express willingness to have a discussion with any customer who thinks there are measures the manufacturer should take but hasn’t.

What is the information the end user should have about the device? First, they need at least a “one-level” SBOM, showing every software or firmware product installed directly in the device, along with whatever identifiers are required to look up the software in the NVD or another vulnerability database like OSS Index. If the customer has that much, they’ll be at the same point that most users of “user-managed” software find themselves at, with respect to the software installed on the servers they operate: They’ll know what software products are directly installed on each device (or on each server, in the case of user-managed software), and they’ll be able to investigate vulnerabilities found in those products.

But is that enough? After all, any server administrator today can identify every software product that’s installed on their servers using a tool like PowerShell or even Windows™ Explorer; then they can learn about vulnerabilities in those products by looking them up in the NVD or another vulnerability database. But they won’t learn about vulnerabilities caused by components of those software products if they don’t also have an SBOM for each product; then they can look up each component in the NVD, to learn about its vulnerabilities.

How will the server administrator get an SBOM for one of the user-managed software products? They’ll probably ask the software’s supplier for it, and they’re likely to get it, too (at least one SBOM, anyway). Why is the product’s supplier likely to give it to them? Because they’re a customer, of course.

However, if an IoT or IIoT device manufacturer gives a customer a first level SBOM for the device, the customer will just know the names of the software products installed in the device – the equivalent of what they could learn from running Windows Explorer on a standalone server. The IoT customer won’t know anything about components of those products, unless they have an SBOM from the supplier of each software product installed in the device.

At least, having a first level SBOM, the device customer will know the names of the software products installed in the device and their suppliers’ names. What will they hear when they contact those suppliers to ask for an SBOM? Most likely nothing at all, or perhaps “Get lost”. The problem is that the device customer isn’t a customer of the suppliers of the software installed in the device; the device manufacturer is. It’s very likely that only the manufacturer will be able to get the SBOMs, and perhaps not even them..

Thus, it isn’t likely that IoT or IIoT device customers will be able to obtain SBOMs for software products installed in intelligent devices they own or utilize. Of course, they can beg the device’s manufacturer to please, pretty please get the SBOMs for them – but I doubt that will be a very productive exercise.

But more generally, why should analysis of cyber risks found in intelligent devices be exclusively the responsibility of end users? After all, the manufacturer chose the “first level” software and firmware products that are installed in the device. It’s their job to make sure they’re secure; if they’re not, it’s the manufacturer’s responsibility either to get the supplier to fix vulnerabilities in their software, or to replace the software with a more reliable product.

But how can the device customer even “audit” the manufacturer’s performance in vulnerability management? If the customer receives an SBOM that lists the first-level software and firmware products installed in the device (which will hopefully start happening soon with medical devices), that at least puts the device customer on the same level as the server administrator that identifies each software product installed on their server using Windows Explorer: The device customer will usually be able to learn about vulnerabilities in those products, although they won’t learn about vulnerabilities found in the immediate components (dependencies) of those products.

However, why should the device customer even have to look up vulnerabilities in each of the “first-level” software and firmware products installed in the device? Each customer presumably has exactly the same set of software products installed in their device as any other customer does. If there are say 10,000 customers of a device, why should every one of them have to perform exactly the same set of steps to learn about vulnerabilities in the device, when the manufacturer can perform those steps for all 10,000 customers at once?

And not only can the manufacturer perform those steps themselves, but they should be performing them already. That is, they should be doing it, assuming they care about securing the devices they sell. For example, if there are say 15 software and firmware products directly installed in the device (there may be a lot more, of course), why can’t the manufacturer share with their customers every exploitable vulnerability associated with those products?

Besides reporting each vulnerability to their customers, the manufacturer also needs to register the device itself in the National Vulnerability Database (NVD) and report all exploitable vulnerabilities they identify in the device. This includes both vulnerabilities due to code written by the manufacturer and vulnerabilities due to code written by the suppliers of the third party software and firmware products installed in the device.

When device manufacturers start doing this, vulnerability management for intelligent devices, including medical devices, will be much easier. The customer will just have to search on the device’s CPE name in the NVD, in order to learn about all exploitable vulnerabilities in the device. This is what software users are supposed to be able to do now. Why shouldn’t device users be able to do the same thing?

I hope the FDA includes this in their device security requirements, along with requiring an SBOM for the device.

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.