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

Note from Tom:

Note from Tom: I am now putting up all my new posts in my Substack blog, but only select ones in Blogspot. If you would like to read the full version of the post below, please subscribe to my Substack blog on a paid ($30 per year) basis by clicking on the link for a 7-day free trial below. This will let you see all of my new posts. It will also let you see all 1200+ legacy posts that I originally put up in Blogspot, but which are now available to all Substack subscribers.

 

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.”

….

Keep reading with a 7-day free trial

Subscribe to Tom Alrich's Blog, too to keep reading this post and get 7 days of free access to the full post archives.

Start trial

A paid subscription gets you:

	Access to all posts starting in 2013
	Post comments and questions in the group chat for this blog
	Know you're helping Tom continue to write his posts