Developers update their software, sometimes they patch vulnerabilities.
Is it realistically possible to analyze the updated code (even if it's closed source) to find the vulnerability that has been fixed (and still exist on all unpatched versions)?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
Is it realistically possible ...
Yes. And it is also done in practice for many years. The term "1day exploit" (on contrast to 0day) is sometimes used in this context when the attacker manages to exploit a vulnerability after the patch was released but before it got installed - often by reverse engineering what vulnerability the patch has fixed.
From a few searches on the internet:
Is it possible at all? Generally yes, almost everything can be reverse-engineered, with difficulty varying with both the ecosystem and any obfuscating measures done by the developer. For example, for .NET application, it is much easier than for plain C binaries.
Is it realistic: Depends on what threat actors and which ecosystem we are talking about. In most cases, it is not very realistic. If we consider nation-state actors like intelligence agencies then it is realistic. Whether they actually want to spend effort on something that has a fix available is another story. Un-obfuscated .NET binaries (or similar) are also on the more realistic side, depending on the financial advantage an attacker expects from it (again considering a fix is available)
For database there is also the option of schema data comparisons tools, these could be used to compare environments & make sure there isn't anything unexpected missing in the change scripts - could also generate the change scripts.
I don't think you'll find a fail-safe mechanism.
I recommend that, when possible, you take into account compatibility with the current published source.