Item Removal Request - 14.1.2

[ImanSharaf]

#	Description	L1	L2	L3	CWE
14.1.2	Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.		✓	✓	120

As discussed previously in item #803, we established that anything outside the realm of web applications is considered out of scope. This aligns with the fact that modern application development rarely, if ever, involves languages like C or C++ for web applications, where such low-level memory protections are relevant.

Given the current landscape of web development, where higher-level languages and managed frameworks are typically employed, this item seems outdated and unnecessary. Removing it will streamline ASVS to better reflect current industry standards and practices.

[randomstuff]

Even if the application language is safe, you might have some native code for some hot paths. Moreover when using WebAssembly, you might have client-side C or C++ code and this requirement might be partially relevant in this case.

On the other hand, if find the requirement too strict ("all available buffer overflow protections and warnings".)

Could be say something such as:

Verify that some mitigations are in place to protect against memory corruption such as buffer overflows or use-after-free if memory unsafe code is used.

[elarlang]

Maybe it is a bit niche? Verifiable?

If we still want to have a requirement about that, it does not seem to be configuration issue and maybe something in V10.

[jmanico]

This is just a dev issue and not a must for secure software. Also, buffer overflow is a very rare issue in web languages.

ASVS is getting beefy, I really suggest we go with @ImanSharaf and delete it.

[ImanSharaf]

For sure, buffer overflow is a very rare issue in web languages.

[tghosth]

@ryarmst what do you think about this?

[ryarmst]

A few notes:

• @randomstuff is right that there are relevant outlier instances (how pervasive, unknown)
• I searched for recent and impactful CVEs that affected web apps and the cases I identified would overwhelmingly fall out of ASVS scope
• This is a defense in depth practice (though an effective one in some contexts)
• Does the build process fall within ASVS scope?

Ultimately, based on the above, my opinion is to remove.

[tghosth]

In principle it is in scope because it is not so much the build process but rather a characteristic that is built into the application by the build process, i.e. it becomes a part of the way the compiled application works.

We do have requirements related to unsafe code here: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md#v54-memory-string-and-unmanaged-code

[tghosth]

I think we should keep this but make it L3