I found a more detailed explanation of it: https://github.com/julepka/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md#testing-f

I found a more detailed explanation of it: https://github.com/julepka/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md#testing-for-debugging-symbols-mstg-code-3 https://github.com/julepka/owasp-mstg/blob/master/Document/0... > Generally, you should provide compiled code with as little explanation as possible. Some metadata, such as debugging information, line numbers, and descriptive function or method names, make the binary or bytecode easier for the reverse engineer to understand, but these aren't needed in a release build and can therefore be safely omitted without impacting the app's functionality. I'm not a big fan of the reasoning, as it's security through obscurity. Which is not the worst tradeoff, as many vulnerable systems hold up for years thanks to machine code obfsucation, but these days it just makes public bug bounties (and other public auditing) end up being less of an interesting prospect for improving security. Many bug bounties nowadays help participants by, for example, leaving an entire web API's documentation open to view. It's the same sort of thing as leaving source code public -- should that be a disqualifier under such guidelines?