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.
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
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).
It could be that it's easier to reverse (closed source) apps (with unreviewed code after each DevSecOps Pull Request with Changelog entry) with debugging symbols.
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)
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?
https://www.bleepingcomputer.com/news/security/google-play-a... :
App Defense Alliance > Mobile Application Security Assessment: https://appdefensealliance.dev/masa
OWASP Mobile Application Security: https://mas.owasp.org/ :
OWASP MAS Checklist .xlsx: https://github.com/OWASP/owasp-mastg/releases/latest/downloa...
OWASP/owasp-mastg: https://github.com/OWASP/owasp-mastg :
OWASP/owasp-masvs: https://github.com/OWASP/owasp-masvs :
What's wrong with debugging symbols, from a security perspective? What if you desire maximum inspectability of the internals?
Other than that, these guidelines seem great.
It could be that it's easier to reverse (closed source) apps (with unreviewed code after each DevSecOps Pull Request with Changelog entry) with debugging symbols.
gdb on Fedora auto-installs signed debuginfo packages with debug symbols; Fedora hosts a debuginfod server for their packages (which are built by Koji) and sets `DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ ` : https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#S...
Without debug symbols, a debugger has to read unlabeled ASM instructions (or VM opcodes (or an LL IR)).
From "Show HN: Tetris, but the blocks are ARM instructions that execute in the browser" https://news.ycombinator.com/item?id=37086102 :
"Show HN: Ghidra Plays Mario" the NES ROM. https://news.ycombinator.com/item?id=37475761
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...
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?