Software is never free of bugs. Some bugs introduce vulnerabilities that can be exploited by attackers and bring your system down, lead to data loss, etc. When vendors fix such bugs, patches are issued and should be installed asap. Nothing new so far. As you know, my core experience in software security, this article partly focuses an SAP related patches.
SAP started handling security things more systematically back in 2011. Since then, a lot has happened at SAP. There’s threat modelling everywhere, secure coding guidelines, tool support, Q-Gates, etc. etc. And there are still things found by researchers reported to SAP and fixed diligently. Patches (called Security Notes in SAP-slang) are released on the second Tuesday of every month. The track record showing the latest patches is publicly available (with no credentials needed at the time of writing this).
On the customer end of this story, processes need to be in place to apply the patches. Per se, this is not rocket science, but a question of know-how, resources, processes and most importantly priorities. A few years ago a study mentioned that only 30% of customers apply patches within 3 months. I assume that this number is better now but still far away from meeting a best-practise level.
During my PhD time (around year 2000), I stumbled of the Window of Exposure as described by the security guru Bruce Schneier. And I think it perfectly applies to the SAP world. As you can see in the figure, the risk increases the more a vulnerability is known to the public. Ironically, this is somewhat boosted when a patch is released. And it makes timely patching even more important.
I have seen many researchers and organisations contributing to the security of the SAP standard by submitting the findings about vulnerabilities. And the SAP Security Response process in place helps us to get the patches out. Some sort of a Catch 22: we can observe that after patch days, exploits are made available, for example on Github, since the blueprint of the weakness is in the patch itself. This makes timely patching even more important.
Sometimes I have seen that some researchers or organisations literally orchestrate a global marketing campaign which is fired by the day of the patch release. While transparency about patches is a good thing, this is not. Because it a) increases the exposure of a vulnerability dramatically b) it puts even more risk and pressure on customers to literally apply a patch at the day of the release.
In short: SAP patches are the result of a well established process and timely application is key. Also: reasonable handling (versus ego or sales numbers) of researchers and organisations is key, too, Looking forward to your comments.