Monday, August 8, 2022

9 ½ years!


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 141 vulnerable components found in the product, out of 699 total components.
  • There were 77 unique vulnerabilities in the product, which of course is a lot (this means the average vulnerability was identified in a little less than two different components).
  • What’s worse is the fact that the average time since the disclosure of the vulnerabilities was 2,978 days, which is more than 8 years.[1]
  • Vulnerabilities were grouped by severity, based on their CVSS score category: low, medium, high or critical. The analysis found:

1.      There were 5 low-severity vulnerabilities. Their average age was 2801 days or 7.67 years.

2.      There were 61 medium-severity vulnerabilities, whose average age was 2,987 days or 8.18 years.

3.      There were 9 high-severity vulnerabilities, whose average age was 3,058 days or 8.37 years.

4.      There were 2 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 some informal conclusions from this data (drawn by the author, not the service provider that performed the analysis of the SBOM):

1.      It is very hard to understand how a supplier can allow 77 vulnerabilities of any severity, let alone high or critical severity, to remain unpatched after even 7 ½ years (as is true for the 5 low-severity vulnerabilities), let alone for 9 ½ years (which is the case for the 2 critical vulnerabilities). If the organization doing a procurement is seriously considering purchasing a product from the supplier that compiled this record, they should have a serious discussion with them about the maximum time they will allow any vulnerability to remain in a product.

2.      It is odd, to say the least, that, in this analysis, the length of time that a vulnerable component has been left in a product increased with the severity of the vulnerability. The organization needs to discuss this with the supplier as well.

3.      Of course, it is possible that some or all of the vulnerable components were obtained only recently, for example in the last year. In other words, a supplier might defend themselves by pointing out that a critical vulnerability was in the component for 8 ½ years, before they introduced the component into their product a year ago. However, then the question becomes why the supplier even included such a component in their product in the first place. More generally, a discussion of this problem should lead to a broader discussion of the supplier’s own supply chain risk management policies. Do they even check for vulnerabilities in components before they include them in their products?

In other words, just the above data from an SBOM should lead to the acquiring organization having a serious talk with this supplier before they finalize the procurement. They need to discuss the supplier’s component acquisition policies, as well as their component vulnerability management policies. Moreover, the procurement contract might well include the requirement that the supplier patch certain component vulnerabilities (at least the critical and high ones), or even replace the vulnerable components altogether.


[1] The analysis didn’t address the question of exploitability of vulnerabilities. It is certain that at least some of these vulnerabilities are not actually exploitable in the product, meaning it might not be important to patch them initially. However, they author’s opinion is that no component vulnerability should be left unpatched for more than say three years, whether or not it is initially deemed not to be exploitable by the supplier. The reason for this is that a future code change in the product might inadvertently change the vulnerability’s status in the product from not exploitable to exploitable.

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.

1 comment:

  1. In my years at Sonatype, I saw hundreds of stories just like this one. Every so often wed scan something that was clean but what you've described was about 80% of all the scan I saw.

    ReplyDelete