You want answers about software security? No problem! Oh, you want reliable answers?…Why didn’t you tell me?

Note from Tom:

If this is my first post that you have read on my Substack blog, welcome! To continue to provide the quality of posts my readers on Blogspot have come to expect, I am now putting up all my new posts for paid subscribers only on Substack. All of the 1200+ posts I have written since 2013 are also now available on Substack.

A paid subscription to this blog costs only $30 per year or $5 per month (you can pay for just one month as a trial subscription. I’m putting up 2-4 posts every week). However, anyone who really can’t pay that much should email me and I’ll give you a free subscription. Enjoy!

This week, a friend of mine, Bill Jacqmein, sent me a link to this article by Adam Isles, a cybersecurity consultant with the Chertoff Group. While it’s a good article and I don’t find any factual problems with it, the problem I do find is one that I’ve found in a lot of articles and blog posts by consultants, including more than a few of my posts: a failure to disclose that the fancy tools and services you’re recommending for the readers have about a snowball’s chance in hell of being successfully used by any but a few readers or, even worse, are simply unusable.

Of course, the reason why consultants do this is because they think their readers, after they realize the recommendations don’t work, will immediately contract them to provide those same services. However, ask the man who knows: It almost never works that way. I have identified multiple examples of this problem in Adam’s article. I will describe the first example in this post and other examples in subsequent posts.

Here's my first example. The last sentence of the paragraph that begins with “Legacy code…” points out that modern software contains many components written by third parties; those components in turn contain many components, etc. The paragraph concludes with the sentence, “That means the software supply chain security problem goes back dozens or even hundreds of upstream software suppliers, requiring each of the next-hop upstream suppliers to manage this risk.”

The implicit message of this sentence is, “With all these upstream tiers of suppliers, you shouldn’t even think of trying to learn about vulnerabilities in the software you use on your own. Just think of all the upstream components, components of components, etc. To get a realistic inventory of all the vulnerabilities in just one software product that you use, you will probably need to learn about the vulnerabilities found in thousands of components.”