Resolve #2145 by reviewing problematic malicious code requirements (#…

…2218)

* Update 0x18-V10-Coding.md

Issue #2145

* Update 0x18-V10-Coding.md

* Update 0x18-V10-Coding.md

* Include in recommendations

---------

Co-authored-by: Elar Lang <[email protected]>
Co-authored-by: Josh Grossman <[email protected]>

5.0/en/0x18-V10-Coding.md

@@ -22,18 +22,14 @@ Lead developers should regularly review code check-ins, particularly those that
 
 ## V10.2 Malicious Code Search
 
-Malicious code is extremely rare and is difficult to detect. Manual line-by-line code review can assist with detecting logic bombs, but even the most experienced code reviewers will struggle to find malicious code even if they know it exists. As such, this section is mostly L3. Complying with this section is not possible without complete access to source code, including third-party libraries.
-
-Ultimately, finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.
-
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **10.2.1** | Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data. | | ✓ | ✓ | 359 |
+| **10.2.1** | [DELETED, NOT PRACTICAL] | | | | |
 | **10.2.2** | [MOVED TO 8.3.11] | | | | |
-| **10.2.3** | Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. | | | ✓ | 507 |
-| **10.2.4** | Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions. | | | ✓ | 511 |
-| **10.2.5** | Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | | | ✓ | 511 |
-| **10.2.6** | Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality. | | | ✓ | 507 |
+| **10.2.3** | [DELETED, NOT PRACTICAL] | | | | |
+| **10.2.4** | [DELETED, NOT PRACTICAL] | | | | |
+| **10.2.5** | [DELETED, NOT PRACTICAL] | | | | |
+| **10.2.6** | [DELETED, NOT PRACTICAL] | | | | |
 
 ## V10.3 Application Integrity
 

5.0/en/0x99-Appendix-X_Recommendations.md

@@ -31,3 +31,4 @@ There are a number of security processes which were removed from ASVS 5.0 but ar
 * Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing.
 * Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile"
 * Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.
+* Verify that an ongoing process exists to ensure that the application source code is free from backdoors, malicious code (e.g., salami attacks, logic bombs, time bombs), and undocumented or hidden features (e.g., Easter eggs, insecure debugging tools). Complying with this section is not possible without complete access to source code, including third-party libraries, and is therefore probably only suitable for applications requiring the very highest levels of security.