R158. Use a secure programming language


System source code must be implemented in a stable, updated, tested and free of known vulnerabilities version of the chosen programming language.


  1. CAPEC-123: Buffer Manipulation. An adversary manipulates an application’s interaction with a buffer in an attempt to read or modify data they shouldn’t have access to. Buffer attacks are distinguished in that it is the buffer space itself that is the target of the attack rather than any code responsible for interpreting the content of the buffer.

  2. CAPEC-129: Pointer Manipulation. This attack pattern involves an adversary manipulating a pointer within a target application resulting in the application accessing an unintended memory location. This can result in the crashing of the application or, for certain pointer values, access to data that would not normally be possible or the execution of arbitrary code.

  3. CAPEC-131: Resource Leak Exposure. An adversary utilizes a resource leak on the target to deplete the quantity of the resource available to service legitimate requests. Resource leaks most often come in the form of memory leaks where memory is allocated but never released after it has served its purpose, however, theoretically, any other resource that can be reserved can be targeted if the target fails to release the reservation when the reserved resource block is no longer needed.

  4. CIS Controls. 18.1 Establish Secure Coding Practices. Establish secure coding practices appropriate to the programming language and development environment being used.

  5. CWE-120: Classic Buffer Overflow. The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.

  6. OWASP Top 10 A9:2017-Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

  7. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.11) Verify that any use of banned C functions are replaced with the appropriate safe equivalent functions.

  8. OWASP-ASVS v4.0.1 V5.4 Memory, String, and Unmanaged Code Requirements.(5.4.1) Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.

  9. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.1) Verify that all components are up to date, preferably using a dependency checker during build or compile time.

  10. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.4) Verify that third party components come from pre-defined, trusted and continually maintained repositories.

  11. PCI DSS v3.2.1 - Requirement 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.

Service status - Terms of Use - Privacy Policy - Cookie Policy

Copyright © 2021 Fluid Attacks, We hack your software. All rights reserved.