Should SaaS providers report vulnerabilities?
As you may know, the overwhelming majority of vulnerabilities in CVE records are reported by the developer of the vulnerable software. Developers do this because it’s the right thing to do, but also because they are concerned that not reporting what turns out to be a serious vulnerability might land them in legal jeopardy, if one or more of their customers is attacked through that vulnerability.
When a developer of software used on premises (i.e., software not delivered through the cloud) discovers a new vulnerability in their product, they usually first develop a patch and then report the vulnerability to the CVE program, where a CVE Numbering Authority (CNA) assigns a CVE number to it and describes it in a new CVE Record (in most cases, the developer itself is the CNA).
However, one group of software developers has almost never been reporting vulnerabilities: developers who make their software available to customers in the cloud. They are also known as SaaS (software-as-a-service) providers. Their reason for not reporting is simple: Since the first thing a SaaS provider does when they have discovered a vulnerability is patch it, this means the vulnerability is no longer found in their product and the customer doesn’t have to take any action like applying a patch. Why bother their customers about something that doesn’t affect them, and which they don’t need to take action on?
But the purpose of reporting a vulnerability to the CVE program isn’t just to let customers know they need to apply a patch. Since a new vulnerability by definition has never been identified before, the whole software world needs to learn about it. This is because that same vulnerability might be present in many other products, but was never noticed before (after the log4shell vulnerability was discovered by a researcher in China, think of how many products it was found in).
More importantly, vulnerability scanner vendors need to learn about new vulnerabilities, even though they’ve been patched in the products in which they were first discovered. The vendor needs to add the “signature” for the new vulnerability to their product, so their users will be able to discover it in products they scan. By not reporting a new vulnerability because their customers aren’t affected by it, SaaS providers are doing the worldwide software community a disservice.
Then, why don’t SaaS providers report a new vulnerability and at the same time let their customers know they don’t have to worry about it? In fact, in 2024 Microsoft took this approach when they announced they had revised their Security Update Guide to display whether “customer action” (such as applying a patch) is required. Of course, few end user organizations will even bother to download a security notification that doesn’t apply to them, which is fine. However, some software developers, security researchers and others will want to learn about this new vulnerability, especially if it is a serious one.
But there’s still a problem with Microsoft’s solution: Many customers won’t even look at the Security Upgrade Guide. They will just read that there’s a new CVE that affects a Microsoft SaaS product they use (such as Office 365) and call Microsoft to find out when the patch will be available. No matter what answer they receive, their opinion of Microsoft will drop a notch or two because their product has a serious vulnerability. This is probably the real reason why SaaS providers don’t report vulnerabilities: most customers will blame them for having a vulnerability, rather than praise them for reporting it in the first place (which they should do, if they knew the full story).
And now, a word from our sponsor
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for one month after they come out by becoming a free subscriber. You can also access my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can donate more than that!).
However, in December 2024, at the CVE program’s quarterly CNA workshop, someone proposed a much better solution to this problem than the one Microsoft had implemented six months earlier. A woman named Lisa Olson, who is highly respected in the CVE program, proposed that the CVE Record Format (aka the CVE schema) – the format that CNAs use to report new vulnerabilities – should be revised to include a third option for the “status” field. Currently, status is either “not affected” (not vulnerable) or “affected” (vulnerable).
Lisa proposed that there be a new status that indicates that, while the product is vulnerable to the new CVE, no action by users is required. I can’t remember the exact term she proposed. It was something like “Just FYI”. My own suggestion is “Don’t worry, be happy! 😊”, but that may be too long for the field. BTW, what organization does Lisa Olson represent? Why, Microsoft![i]
Microsoft’s suggestion will need to be approved by the CVE Board and then implemented in the CVE schema, which of course will take a while – since I’m sure there are already other changes in the queue ahead of it. And even when that happens, vulnerability databases and others that report CVE data will have to make changes to their display formats, so this new status option will be visible; many will decide there’s no need to change anything, since their users have better things to do than learn about vulnerabilities that have already been fixed.
However, the main purpose of making this change isn’t to display new information for CVE consumers, but to make SaaS providers more inclined to report vulnerabilities, since vulnerabilities that have already been fixed will no longer be treated the same as unpatched ones. Just making the new reporting option available to SaaS providers will hopefully make them much more inclined to report vulnerabilities.
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at tom@tomalrich.com.
[i] Lisa is now the Executive Director of the CVE Foundation, an organization that I’ve written about multiple times, including recently.