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