Are peripheral issues and systems normally considered in a white box penetration testing scope?
As Wikipedia defines:
White-box testing is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing).
When the code is a target of its own, this is not (only) a penetration test but a source code security audit (or security review).
... "white-box" originally meant using the source code ...
While this is narrowly defined and quite specific and could be defined to a specific repository and branch to be tested. What do we do with peripheral issues or peripheral systems that (could indirectly) affect the intended scope? For example:
- Behavior. Walking around the target office and finding post-its with passwords of developers?
- Organizational. Not having a cooperate information security policy?
- Developer devices being unmanaged, not having EXR/XDR/SIEM/full disk encryption in place?
- The developer office having an open or WEP-protected WiFi-network with a weak password and no network isolation?
- Relevant cloud services not having multi-factor authentication (MFA)?
- All employees having root or global administrator permissions?
These are just a few random examples that could (severely) impact the security of the production systems that run on the source-code that's intended to be tested. When to consider such "indirect" risk, or lack of systems in a white box test, if at all? Should those type of findings be reported in a white box penetration testing report as well or not? Are there any open (white box) penetration testing standards that define how to deal with this?
