MASVS-CODE Refactoring (till 26.05.22)

[cpholguera]

Hello everybody,

as part of the refactoring process we decided to publish our draft of every section of the MASVS that we (@cpholguera, @TheDauntless and @sushi2k) worked on.

This is based on the MASVS category "V7: Code Quality and Build Setting Requirements" (from the MASVS Version 1.4.2): https://github.com/OWASP/owasp-masvs/blob/v1.4.2/Document/0x12-V7-Code_quality_and_build_setting_requirements.md

Here you can find a summary of the proposed new requirements (more details below):

In the following link we include a nice visualization as a diff spreadsheet including:

• Reason for removal/change.
• Idea behind the new requirement/formulation.
• More context thanks to related Test Cases.
• Filter in column F1 to see
  • the previous version only
  • the new version only
  • or the diff

MASVS-CODE is open for comments till the 26th of May 2022. Please comment directly in the Google Spreadsheet (you can comment on each of the cells) or in this GitHub Discussion.

MASVS-CODE Refactoring Diff

[grigorescu]

MASVS-CODE-1:

I think the details lie in how the tests are specified, and if we're considering the security impact. For instance, for checking that there are no non-production URLs, is it considered a failure if there are references to a staging environment that's only accessible via a VPN? Should specific checks be broken up between L1, L2, and Resilience? For instance, a failed check which is not adversely impacting the security of the app/data would prohibit acceptance at L2, but would allow acceptance at L1.

MASVS-CODE-3:

It'd be nice to see some additional guidance on what an "up-to-date platform version" is. While there is a nod to the fact that the threat model of the application should define what an acceptable recent version is, some more specific options would include:

• "Stable" or "N-1" major versions,
• The Apple App Store and Google Play Store Policies which have a similar N-1 approach,
• The app is relying on a security protection but has a minimum OS/SDK version that has vulnerabilities or limitations in that security protection.

MASVS-CODE-5:

This should be much more clearly defined as Medium+ vulnerability that is actually impacting the security of the app being evaluated.

[cpholguera]

Thanks a lot @grigorescu, we'll definitely take that into consideration!

[cpholguera]

Potential new control:

MASVS-CODE-7: The app uses platform provided implementations for security critical code, unless independently security vetted.

See #559 (reply in thread)

[MR-KH21]

I agree with @grigorescu regarding the MASVS-CODE-3. My suggestion is to have more actionable item because its hard to define what is up-to-date platform version . For example having a blocklist for vulnerable OS versions (for android the list should have security patch levels).

MASVS-CODE-3: The app has a mechanism to block the app on certain platform versions

Thank you 👍

[cpholguera]

Hi @MR-KH21, thanks for the feedback! The RFC closed 26.05.2022 and you can access the final control here: https://mas.owasp.org/MASVS/controls/MASVS-CODE-1/

The control is intentionally broad as the specificities will be addressed by the OWASP MASTG. We'll be creating specific tests for things like the one you're mentioning.