Software and Sisyphus

A friend who is knowledgeable about software security recently sent me an article that has created a lot of waves in the software community (it is available here, but you’ll have to pay $15 to download it. If you want to email me, I’ll send you my copy).

You can read the paper on your own, although the authors are careful to summarize their conclusions in the first three pages. They set out to answer a particular question: “Is the security of software releases increasing over time?” This is an important question, because there’s a generally accepted view that, as a software offering matures and offers new versions, each version will fix problems that have been found in previous versions. This means that the overall level of security of a software package will increase over time.

However, they found the opposite to be the case, after studying various software releases in the Debian Linux “ecosystem”. They say “Even in popular and ‘stable’ releases, the fixing of bugs does not seem to reduce the rate of newly identified vulnerabilities.” Does this mean we should stop trying to fix software vulnerabilities? Obviously not, since then the problem would keep growing until finally most software was unsafe to use. We need to keep fixing vulnerabilities, but we shouldn’t expect the need for this work to decrease.

There is a reason why the title of the article refers to the tip of the iceberg. Since about nine tenths of an iceberg is underwater, no matter how much ice you chip off the part that’s above water, it won’t help at all. More of the underwater part of the iceberg will emerge from the water, so the total amount above water will remain about one tenth. It’s like the ancient Greek myth of Sisyphus, who was doomed for eternity to roll a huge rock up a hill, only to have it roll to the bottom every time.

What I found most interesting about this article were the two examples the authors used of serious vulnerabilities that caused a huge amount of consternation worldwide, and which were exploited to cause damage: Shellshock and Heartbleed. The main reason both of these were so serious is that they were found in lots of software components – and organizations were faced with the task of trying to figure out, for almost every piece of software they owned, whether it had vulnerable components, whether those components had vulnerable components, etc. Just like the Ripple 20 vulnerabilities more recently.

What does this show? It shows we need SBoMs!

 

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