0x12-V7-Code_quality_and_build_setting_requirements

[sushi2k]

Following comment:

7.2: Does this requirement refer to local logging? If so, why should the app log detailed error messages locally? If they are stored locally they are more or less useless. If there are errors it should be sent directly to the endpoint for investigation.

One general question: Should we include a requirement into "V7: Code quality and build setting requirements" that is suggesting to use tools that do:

• Static source code analysis,
• Dynamic source code analysis, or
• Tools like SecureAssist to scan the code while developing?

Or do we only suggest to use these kind of tools in one of the introduction chapters of MASVS and explain to configure the tools appropriately so that as many requirements as possible can be addressed when using these tools? I think it would make sense to put a separate requirement for the usage of these tools into V7, as this would also show a higher degree of security in the development.

[anantshri]

"I think it would make sense to put a separate requirement for the usage of these tools into V7, as this would also show a higher degree of security in the development. " <- I would personally prefer if we do not put commercial tools in the listing as then it appears like an endorsement from our side. also tools will keep on changing and any configuration that we might have or setup we might have suggested might get outdated by the time we write it to the time its published publically. how do you propose we tackle that as a problem.

[sushi2k]

Hey Anant,

There are open source solutions and pricy enterprise solutions. I am not talking about recommending any specific of those tools (e.g. use Fortify for SAST), but if you are developing software and you do not have any automated checks (can be a script you write on your own, can be a small open source tool or an enterprise tool) that are running on every commit or at least in an regularly intervals security vulnerabilities might only be found in the penetration test, which is the end of the SDLC. And that is definitely too late. We also can only write a requirement on a high level that the configuration is according to best practices and is tailed to the application, as a static source code scan with default settings might not even find all the low-hanging fruits. So maybe we can do requirements like this:

+| 7.8 | Verify that Static Application Security Testing (SAST) is part of the development lifecycle. | | ✓ | ✓ | ✓ | +| 7.9 | Verify that Dynamic Application Security Testing (DAST) is part of the development lifecylce. | | ✓ | ✓ | ✓ | +| 7.10 | Verify that Static Application Security Testing (SAST) configuration is tailored to the application(s) in scope and aligned with current best practices. | | | ✓ | ✓ | +| 7.11 | Verify that Dynamic Application Security Testing (DAST) configuration is tailored to the application(s) in scope and aligned with current best practices. | | | ✓ | ✓ |

There should also be a chapter in the MSTG that is talking about agile development and how these tools like SAST and DAST can be integrated and give some general guidance. Again no recommendation for specific tools, but explaining what you can expect from these tools and what not. Then we can link from these requirements to the MSTG chapter that is talking about agile.

What do you think?

[anantshri]

+1 to the approach i suppose that should workout.

"security vulnerabilities might only be found in the penetration test, which is the end of the SDLC. And that is definitely too late." <- reminds me have we added a chapter in MSTG around Secure SDLC integration yet. if not can we add a note that this should be something going in.

[muellerberndt]

We currently have this here:

7.8 Verify that quality is reassured using either a peer-to-peer review system, or a set of quality tools such as Checkstyle, findbugs, pmd, etc.

So if we have a SAST and DAST requirement we can remove this one?

Also, I'd merge your for requirements to one:

7.8 Verify that Static and Dynamic Application Security Testing (SAST and DAST) are part of the development lifecycle, and that the configuration is tailored to the app.

And make it a requirement from level 2?

[sushi2k]

Agree. We should describe this in the OMTG in more detail, but for the MASVS it makes sense to merge it into one requirement, you are right. Having four different requirements for SAST and DAST is too much. Also agree with Level 2.

[muellerberndt]

All right, I added it.