https://www.bleepingcomputer.com/news/security/google-play-a... :

Specifically, that standard is MASA (Mobile App Security Assessment), which was introduced last year as an initiative of the App Defense Alliance (ADA) to define a concrete set of requirements for mobile app security.

The requirements concern data storage and data privacy practices, cryptography, authentication and session management, network communication, platform interaction, and code quality.

App Defense Alliance > Mobile Application Security Assessment: https://appdefensealliance.dev/masa

OWASP Mobile Application Security: https://mas.owasp.org/ :

The OWASP Mobile Application Security (MAS) flagship project provides a security standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP MASTG) that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases

OWASP MAS Checklist .xlsx: https://github.com/OWASP/owasp-mastg/releases/latest/downloa...

OWASP/owasp-mastg: https://github.com/OWASP/owasp-mastg :

The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).

OWASP/owasp-masvs: https://github.com/OWASP/owasp-masvs :

The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security.

In the context of Linux distros like Fedora -- How does having separated debug symbols improve the security posture, though? Sure, it adds another step to exploitation, but not an insurmountable one.

(It seems like that DebuginfodByDefault FAQ is discussing the security implications of the debugger's parsing of debug symbols itself, rather that of the security of shipping debug symbols in the first place)

I found a more detailed explanation of it: 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?