Fortress Information Security (a company with which I have a consulting relationship) has been analyzing a lot of SBOMs lately. They recently showed me the results of their analysis of the components in a particular security product (which one hopes would have better security than most software products). They were careful not to tell me that these results are somehow typical of the “average” software product, since determining that would require a much larger, controlled study. But they did say they’d examined a number of other products whose analysis yields similar results.
They had other statistics in their report, but what struck me most were the figures for “vulnerability age” – i.e., the number of days since the vulnerability was published (which I assume means when a CVE number was assigned to the vulnerability). The report said:
- There were 19 vulnerable components in the product (i.e., they had at least one open vulnerability. I didn’t see the total number of components, but I’m assuming it’s a lot larger than that). Since there were 141 total vulnerabilities, this means there were about 13 unpatched vulnerabilities per component. That’s a lot.
- Since the top 10 vulnerable components each had 5 open vulnerabilities, this means the 141 vulnerabilities must have been fairly evenly distributed among the components, with a lot of 5s, 4s, etc. It’s not like one or two bad actors were making the other 17 or 18 components look like slouchers. They were all bad actors, or at least not good ones.
- Vulnerabilities were grouped by severity, based on their CVSS score category: low, medium, high or critical.
- There were five low-severity vulnerabilities. Their average age was 2801 days or 7.67 years.
- There were 61 medium-severity vulnerabilities, whose average age was 2,987 days or 8.18 years.
- There were 2 high-severity vulnerabilities, whose average age was 3,058 days or 8.37 years.
- There were 9 critical vulnerabilities, whose average age was 3,447 days or 9.44 years. In other words, the most serious vulnerabilities were the oldest, with the average serious vulnerability having been identified 9 ½ years ago.
Here are my conclusions from this data:
- Keep in mind that, if a vulnerability has been outstanding for 8 years but the component that contains the vulnerability wasn’t included in the product until yesterday, then the vulnerability in that product is one day old. Of course, unless this is a brand new product (which it’s not), at least some of the vulnerable components must have been in it for years.
- Also, keep in mind that these numbers probably haven’t been adjusted to remove non-exploitable vulnerabilities. Thus, the number of exploitable vulnerabilities could be expected to be much smaller than the 141 figure for instances of component vulnerabilities. It’s possible that, if Fortress had asked the product supplier about those 141 instances of vulnerabilities, they might have said something like, “We knew all along that (e.g.) only two instances of component vulnerabilities were exploitable and we immediately patched those, so the 141 that you see are all not exploitable.” It’s possible they’d say this, but I doubt it.
- If a component vulnerability has been around for more than say a year, one would hope the supplier would patch it, even though they still don’t believe it’s exploitable. After all, there are ways in which a component vulnerability that has been deemed non-exploitable by the product supplier might suddenly become exploitable, such as a code change that inadvertently made the vulnerability exploitable. So even if those 9 ½ critical vulnerability instances aren’t exploitable, they should have been patched long ago anyway.
- I don’t understand why the age goes up with component severity. One would generally think that the highest-severity vulnerabilities would be patched as soon as possible, not left to molder for years.
- Since it’s unlikely that the supplier acquired most of their components around 8 years ago, this means the creator of the component (and most were probably open source projects, since 90 percent of components are open source) probably sat on open vulnerabilities for years, before the supplier of the product that Fortress analyzed acquired or downloaded it. Hmm… that doesn’t say a lot for component suppliers, does it?
- However, since the supplier of the product hopefully didn’t acquire all their components yesterday, the fact that at least some of these vulnerable components were sitting in the product for years doesn’t say much for the supplier either, does it? Remember, this supplier makes a security product (in fact, one that’s advertised a lot in the ICS space). Who cares whether or not a security product is itself secure? It seems this supplier doesn’t…
- What I found most amazing is that the lowest average age for a component vulnerability is more than 7 ½ years. I would have guessed it would be, say, no more than one year – and even that seems like a lot to me.
Bottom line: If I were a user of this product and I learned that the majority of component vulnerabilities were known at least 8 years ago yet still hadn’t been patched, I would ask, “Does this supplier even look at component vulnerabilities, let alone patch them?” My conclusion would be, “Probably not.”
In 2017, Veracode performed a study[i] in which they found that “A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.”
I’ve always thought that this was a nice “before” quote, to be contrasted with the much-improved “after” quote from say last month. Certainly (I told myself), software suppliers’ practices would have improved a lot since 2017. I guess I was wrong.
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 [email protected].