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. 


No good deed goes unpunished

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
  • 373 items added with 120,996 views
  • Jun 24, 2022


In my most recent post, I pointed out that it’s literally counterproductive to buy only software products for which no vulnerabilities have ever been reported – especially if the product doesn’t have a CPE name, so it’s not listed in the NVD at all. This is because not reporting any vulnerabilities is almost certainly not a sign that the product is perfect, but that the supplier doesn’t think it’s worthwhile to even look for vulnerabilities. After all, if you’re sure your software is perfect, why even bother to look? I provided a vivid example of a device that’s not even listed in the NVD, but probably has about 40,000 vulnerabilities (2,000 of which are probably exploitable) in its software and firmware, according to Tom Pace of NetRise.

However, I also pointed out that Steve Springett had mentioned that, in his day job, they not only don’t get fooled by products with zero vulnerabilities, but they literally favor products for which a lot of vulnerabilities have been reported. The reasoning is simple: There are a ___-load (excuse me, “a large quantity”) of vulnerabilities in just about any software or firmware product. Since most vulnerabilities are reported by the supplier of the vulnerable product, they can exercise discretion in the ones they report and the ones they don’t report.

In the post, I did point to one type of vulnerability that probably doesn’t need to be reported: vulnerabilities that the supplier discovers and immediately fixes. Since these vulnerabilities never even have the chance to be found in a shipped product from the supplier, I don’t see why they would need to be reported. The whole reason for reporting is to inform software-using organizations of vulnerabilities in software they use, not as a form of public flagellation of the supplier for not being perfect in all circumstances, even if there’s no possibility of harm to anyone.

On the other hand, a supplier definitely should report any vulnerability that is found in a product they have already shipped. And Steve is saying it’s inevitable there will be a lot of vulnerabilities that meet this condition (of course, the biggest reason for this is that new vulnerabilities are always being discovered, so a few lines of code that seemed totally innocuous when the software was written suddenly are identified as a vulnerability). So, if a product has a CPE name, but only a few vulnerabilities have ever been reported for it, this is usually an indication that the supplier isn’t looking very hard for vulnerabilities (the fact that there’s a CPE name means they’ve at least looked once, but that’s not much better than never having looked in the first place).

This brings me to an excellent blog post I just read, by Walter Haydock. Walter is quite an interesting fellow. I connected with him on LinkedIn last year, and a couple of months ago, he mentioned me in a list of five people that his LinkedIn followers should connect to. I was of course pleased with that, but I wasn’t expecting what came next: within two days, about 300 people requested to be connected with me, all due to Walter (whereas I’d probably never had more than two or three requests in one day, and most days none at all). I found this almost scary; I asked Walter what would happen if he told all of his followers to drink poisoned Kool-Aid™. He didn’t know, but also added that he didn’t plan to try that. Good thing! With great power comes great responsibility.

You get the point: This guy’s blog is really good. I highly recommend you subscribe (although I don’t think my recommendation will bring Walter 300 new subscribers in two days!). His latest post makes a point something like my point in my previous post: that the number of vulnerabilities itself isn’t a very meaningful metric (he writes both for suppliers and end users, so you get both perspectives on this question).

What struck me most in Walter’s post was this paragraph:

Some compliance regimes, such as the federal government’s FedRAMP standard…(establish) clear perverse incentives with respect to how organizations look at the total number of findings. For example, after initial authorization, organizations that identify an increase of 20% or more from the baseline, or 10 unique vulnerabilities, whichever is greater, are subject to a “Detailed Finding Review.” By punishing companies who identify more than an arbitrary number of vulnerabilities - regardless of their severity - during a given time frame, the government disincentivizes its vendors from looking too closely for these vulnerabilities in the first place.

This was a real eye-opener to me: The fact that, not only would a supplier not get credit for reporting a healthy number of vulnerabilities, but they would get penalized for doing so. We clearly need to re-think how we treat software vulnerabilities.

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


Jim Stack's picture
Jim Stack on Jun 28, 2022

That makes sense. Having the Fox guard and report on easy access to the hen house. So how do we get a neutral company to check and report weaknesses? I like how Tesla pays anyone who finds a back door and has paid out and a few times hired the helpful hacker. 

Tom Alrich's picture
Tom Alrich on Jun 28, 2022

Jim, I see no alternative to getting the suppliers to do it. All the big ones are now, and a lot of the smaller ones. Their customers need to make it clear that they're not going to buy products if the developers themselves don't know about the vulnerabilities. That's not hard to do.

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 »