> Security by obscurity alone is discouraged and not recommended by standards bodies

A layer, not the only layer.

> System security should not depend on the secrecy of the implementation or its components.

It is not depending on it. It is just an additional layer to delay or reduce impact.

This was the proposed scenario that the GP put forward:

> If I was a state employee and I wrote the app, and I had to release the source code, then I'm making it very easy for a bad actor to find a vulnerability and exploit it to leak the data of citizens.

Which doesn't seem to suggest any mitigation other than the lack of published source code.

My post was already very long, didn't want to tangent into possible defenses which depend heavily on what exactly is in the code base...

Using log4jail as a recent example, I had a code base vulnerable to this attack, but it would not be expected that the application used a vulnerable version (we forked the popular code base), and it only was vulnerable in a specific way (which, to this day, no one has attempted to explot, as I have an alarm set up if that kind of input comes in in logs, and previously had the block at the WAF when we were vulnerable for the 4 hours it took to fix the issue.

Security by obscurity is not I good defense, it's a single layer, which buys you time. You need to have multiple layers of defense, and closed source might buy your team time to fix issues.. or make it viable to release the application while a third party takes a year on a security audit.