Everything is vulnerable – there is no such thing as an “unhackable” or completely secure product. In fact, companies that make that claim for themselves, or their products, often invite an attack.
It doesn’t matter if you are a giant like Microsoft, or a startup with the latest app, there will always be vulnerabilities affecting software. Here are some reasons as to why you can’t say a product is 100% secure:
- Commonly used scanning and security tools are likely missing over 88,000 vulnerabilities
- Different products attract different levels of attention by vulnerability researchers
- Reliance on third-party libraries and dependencies may introduce vulnerabilities you aren’t aware of
Missing Over 88,000 Vulnerabilities
Keeping in mind our previous discussions about vulnerability myths involving CVE/NVD and its missing metadata, can you be sure that you’re aware of all the vulnerabilities actually affecting you?
If your current scanning or security tool is showing no issues, you may want to check where your data is coming from. Is it from CVE/NVD? If yes, your tool is likely to be missing over 88,000 vulnerabilities. Therefore, vulnerability reports generated by that tool aren’t able to provide a complete picture of your risk. You may be missing real vulnerabilities that CVE doesn’t include.
Different Levels of Attention
In our Vulnerability QuickView Reports we dedicate a section to “The Most Vulnerable Product/Vendor”. It’s popular, but in every report we provide labored disclaimers explaining the caveats and pitfalls of associating the number of known vulnerabilities with the level of security a product or vendor has.
The most popular products may appear to be the least secure, since they tend to have the most documented vulnerabilities. That might imply that organizations would be safer if they swapped them with another vendor. In reality, that isn’t feasible with a large amount of software, and it may not even be the correct risk management decision.
We still see many people in the media and outside the security space (and some within) use total vulnerability count as a proxy for overall security. The most common example we used to see was MacOS vs. Windows. “MacOS has ‘x’ fewer vulnerabilities than Windows, so it must be more secure. Therefore, let’s choose their operating system”.
However, the total vulnerability count is influenced by a wide range of factors which includes popularity. The widespread adoption of certain vendors and products can influence the number of vulnerabilities disclosed, since the chances of vulnerability researchers scrutinizing popular products is higher than them favoring lesser-known ones. Resources also have an impact, since larger organizations are more likely to routinely release advisories and patches. So it makes sense that certain products will have more disclosed vulnerabilities.
So is a lesser-known product more, or even 100%, secure if there are no disclosed vulnerabilities that can be found for it in CVE? No, not really. Vulnerabilities for that product may be included in the missing 88,000+ vulnerabilities, tucked away in a researcher’s blog post, or buried in a fixing commit. Another possibility could be that the vendor or product in question belongs to a niche industry, and researchers don’t have much of an incentive to probe the software to test it. They may not even have access to it. Regardless, just because you can’t immediately see red flags doesn’t mean that issues aren’t there.
Third-Party Libraries and Dependencies
Another thing to consider is the reliance on Open Sourced Software (OSS) and third-party libraries. This has become the norm in product development, and it isn’t uncommon for one software to contain over a hundred bundled third-party libraries. It is convenient, but organizations still need to be aware that these libraries can introduce vulnerabilities into code.
Not all third-party libraries are vetted, and malicious attackers frequently employ tricks to get unsuspecting developers to utilize compromised code. To make things even more difficult, third-party vulnerabilities can be hard to find as CVE/NVD doesn’t reliably track them.
So before you assume a product is 100% secure you need to ask yourself, “Am I missing any vulnerabilities?” “Am I forgetting any factors that are giving me a false sense of security?” “Do I know all the third-party libraries and dependencies in what I’m using?”
If you’re not confident in your answers, you may need better data. Organizations looking for a complete risk picture will benefit from the most comprehensive, detailed, and actionable source of vulnerability intelligence covering IT, OT, IoT, and third-party libraries and dependencies.