Manage risks and money
"...the pragmatic risk management of these things"
I.e. it costs money so ignore it.
Britain's Telecoms Security Bill will be accompanied by a detailed code of practice containing 70 specific security requirements for telcos and their suppliers to meet, The Register can reveal. The Telecom Security Bill (TSB), which is near the end of its journey through Parliament, has been rather unpopular with some ISPs who …
"There's always that risk that customers come to you and say, I can't possibly buy your product, because you've got maybe one version out of date of OpenSSL. "
Are you trying to make me believe that you have customers that actually check out the technical aspects of your product before buying it ?
Because that would be a first, in my experience. Generally, the customer buys the product, then finds out what doesn't work and IT has to spend time (and possibly money) to solve the issue. Then the manager responsible can strutt his stuff in front of the Board and boast about how he made incredible gains for the company.
It's a long shot to say any of them would even understand (the consequences of) the statement:
"The Chinese firm was, among other things, using "70 full copies of 4 different OpenSSL versions" which contained 10 "publicly disclosed" vulns, some "dating back to 2006".
And said in a tone, as though Cisco itself doesn't have any dirty laundry.
We've actually had quite a number of customers who ask us to complete security inquiries that include numerous technical details, and more than a few who scan product installations for third-party components with known vulnerabilities. It's becoming common in the enterprise-software market.
So we should ignore updating, because there's no difference between a version with both published and unpublished vulnerabilities, and a version with only unpublished ones?
If refraining from using computers at all fits your needs and threat model, then by all means feel free to do so. Otherwise your objection has no practical value.
SBOMs as a security management concept have come in for some criticism recently because they could create the illusion that picking (for example) one specific software library and saying "job done, it's secure" doesn't set the expectation that the library will need updating in future.
This kind of problem was endemic in Huawei's mobile network equipment firmware, as NCSC's Huawei examination cell revealed in 2019. The Chinese firm was, among other things, using "70 full copies of 4 different OpenSSL versions" which contained 10 "publicly disclosed" vulns, some "dating back to 2006".
Referring to the TSB, Cisco's Jackson illustrated the SBOM problem from the vendor's perspective:
There's always that risk that customers come to you and say, I can't possibly buy your product, because you've got maybe one version out of date of OpenSSL. It might not be vulnerable, but... it's out of date, therefore it must be bad. And you then end up with a really difficult conversation from a commercial perspective as to how you manage those things and get down to the pragmatic risk management of these things.
So because the conversation might be difficult they choose to ensure its not even contemplated buy steering conversations away from it.
if they have some super duper mitigation that makes it safe to include vulnerable libraries then they should speak up.
Quote: '.....there are "no undocumented administrative mechanisms"...'
Logic failure: how do I test for "the absence of a feature" within some huge binary image?
Oh....I see now....Cisco will give me a letter saying that "the product complies"......with a matching certificate from the NSA!!!!
I need to take a look at the Snowden papers again!!