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

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, https://tomalrichblog.blogspot.com/. 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 SBOMenergyPOC@inl.gov.

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 tom@tomalrich.com.