I've only noticed this in L4D2 but any game where you can compile in HDR would likely be vulnerable, too.

As a form of "protection" against decompiles, you can use VBSPINFO to extract 07_LUMP_FACES, create a *.lmp file for it, then zero the data there and the map will still work perfectly. You can also apply this directly to the BSP file and the map will still work perfectly.

Why the map still works:

BSPSource only checks 07_LUMP_FACES. This lump is always created, regardless of compile settings.

If the map is compiled with VRAD+HDR, then 53_LUMP_LIGHTING_HDR becomes non-0, which means 58_LUMP_FACES_HDR is then used by the engine instead.

At least in L4D2, 58_LUMP_FACES_HDR is always prioritized -- if it's empty, it falls back to 07_LUMP_FACES. If both are empty, the map will fail to load.

End result: 07_LUMP_FACES can be zeroed, BSPSource decompiles break, but the engine reads from 58_LUMP_FACES_HDR as if nothing had happened.

Background info: https://github.com/Tsuey/L4D2-BSP-Lump-Editing