The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


This might be what it takes to make me finally give up my BlackBerry. But dang, I love that keyboard…

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents, Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 426 items added with 154,702 views
  • Aug 20, 2021


Two days ago, Politico published a really chilling article about how BlackBerry - which is now a software company, after earlier being a pioneer (in fact, the pioneer, in my opinion) in internet-connected personal devices - gravely mishandled reports of serious flaws in its QNX operating system. QNX is found in all sorts of devices like cars (200 million of them, according to the article) and the International Space Station. This was called to my attention by Eric Byres of aDolus, who wrote an excellent blog post that elaborated on Politico’s point about how having SBOMs could have made this a much easier problem to deal with, whether or not BlackBerry had cooperated.

Because the fact is that they didn’t cooperate. Microsoft first discovered this vulnerability in April in a whole host of device operating systems, not just QNX. The article continues, “In May, many of those companies worked with the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency to publicly reveal the flaws and urge users to patch their devices. BlackBerry wasn’t among them.”

At first, BlackBerry denied that QNX even had the problem, even though CISA showed them it did (in some versions). Finally, they admitted the problem, but said they weren’t going to publicly announce the vulnerability. Rather, they were going to work with their direct customers privately to fix the problem.

Of course, on the surface, BlackBerry’s desire to limit disclosure to their direct customers was reasonable. Software companies do that all the time, especially if they haven’t yet distributed a patch for a vulnerability. After all, if they announce an important vulnerability to the whole world before their customers have been able to patch it, they’re inviting ruin on those customers.

But it turns out that BlackBerry doesn’t have any idea who are all the customers of QNX. BlackBerry sells it to large organizations that incorporate it into products that they sell to other organizations, who embed those products into their own products, etc. Once you get down below at least the second tier of this, users of devices that run QNX almost certainly have no idea that they have it – since it doesn’t appear on any invoice they’ve ever received.

Just as in the case of the Ripple 20 vulnerabilities, the right course of action in this case was to first prepare the patch, then let the whole world know about it. That way, in principle all users would be able to figure out if they have a product that contains QNX, and if they do,  get a patch from whoever sold them that product. The good news is BlackBerry finally took this course of action. The bad news is they took it two days ago, after Microsoft had revealed the vulnerability in April.

Of course, Microsoft deliberately didn’t name names in their April announcement, in order to give the O/S vendors a chance to patch their systems and then announce the vulnerability and the patch at the same time. It seems that BlackBerry missed that memo.

You may have noticed that I italicized “in principle” two paragraphs above. When you hear that X is true in principle, what do you normally think? I normally think, “There isn’t a snowball’s chance in hell that X is actually true in real life.” Indeed that’s the case here. In principle, every company could take an inventory of all the devices they operate, check the current software bill of materials (SBOM) for each device type, and instantly know which ones are running QNX.

And even if the device they own doesn’t run QNX, the O/S might be running inside a component within that device (take your car. Even if it’s one of the 200 million cars running QNX, in most cases QNX is probably running inside some device that’s a component of another device, etc). But in principle that’s not a problem either, since you’ll not only have an SBOM for your car, but you’ll have an SBOM for the entertainment system, the transmission system, the passive safety system, etc. So if one of those systems is running QNX, you’ll learn that.

Now, I won’t say that principles are worthless. But I will say that all these “in principles” aren’t going to get you very far, because without a doubt you don’t now have SBOMs for all of these devices – in fact, it’s very unlikely you have a single SBOM for anything in your car, let alone the car itself. Or just about any other software or device that you operate.

But this is changing, of course. Federal agencies are going to be required to get SBOMs from their software (and device) suppliers as of around August 12, 2021 – according to an OMB memo that came out last week, based of course on the May 12 Executive Order on software security. And it’s highly unlikely that this will end with the Feds – it will spread to the private sector, even though it’s not mandatory for them (and besides, the federal government buys lots of cars!).

If you’d like to learn more about SBOMs, I believe I’ve mentioned them once or twice in previous posts (he says while smirking). You can find some of them by searching on SBOM in the search bar that you see when you go to the main page of my blog, And you might want to join the Energy SBOM Proof of Concept meetings that I help coordinate. We’ll meet next Wednesday from noon to 1 ET. To get the URL, drop an email to

I do wish to point out that we do have strict criteria for attending these meetings. You must be a user of electric energy. If you’re an off-the-grid kind of guy, and you’re reading this in a dark cabin in the mountains of East Nowhere, you probably won’t find the meeting appropriate. In fact, I don’t think you’ll be able to attend it, anyway (plus I don’t know how you’re reading this post in the first place).

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at


Matt Chester's picture
Matt Chester on Aug 20, 2021

But this is changing, of course. Federal agencies are going to be required to get SBOMs from their software (and device) suppliers as of around August 12, 2021 – according to an OMB memo that came out last week, based of course on the May 12 Executive Order on software security. And it’s highly unlikely that this will end with the Feds – it will spread to the private sector, even though it’s not mandatory for them (and besides, the federal government buys lots of cars!).

Is there international precedence for this? Software companies are so frequently international in nature that it makes me think of the GDPR rule from the EU that sent many U.S. companies scrambling to comply both abroad and at home; would the SBOM requirements become an international trend or are they already required in some other corners of the globe?  

Tom Alrich's picture
Tom Alrich on Aug 22, 2021

The NTIA/Dept. of Commerce effort is an international effort - we have people from Europe and Japan at most of the meetings. What has been developed there will without much doubt be what the whole world follows. The only question is when it will be mandatory. The US is the first country that's said SBOMs will be required, although I'm sure others will follow as well. They may decided to look at exactly what we require here, before requiring anything on their own.

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network® is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »