The 5 main coding flaws “you should know” for DevSecOps

Security professionals are accustomed to stepping in at the end of the software development process to identify security vulnerabilities, many of which could have been avoided with earlier intervention. To solve this problem, developers who are already under pressure to deliver increasingly complex software faster and more cheaply are recruited to implement security earlier in the development cycle as part of the “shift” movement. left ”.

To understand the hurdles developers face in meeting new security requirements, take a look at the five most common coding flaws and how to fix them.

1. Memory errors
Memory read errors can potentially affect confidentiality and integrity by disclosing sensitive information, while memory write errors can potentially disrupt the flow of execution, which can affect all three components of the memory. security triad: confidentiality, integrity and availability. Common examples include buffer overflow / underrun and after free use (UAF) errors. Even the most skilled programmers can inadvertently generate these underlying flaws, which are difficult to detect and can be found even in code that is well tested and certified to be safe. Although coding standards are often used to reduce memory errors, they are not sufficient. Thorough static analysis, data flow analysis, and symbolic execution are absolutely necessary to detect memory errors early in the development lifecycle.

2. Programming errors
This class of errors is mainly caused by incorrect use of C / C ++, such as uninitialized variables, double freeing of pointers, and implicit conversion between signed and unsigned variables. Programming errors, some of which may be exploitable, may not show up during functional and regression testing, even though they result in a corrupted program state. However, they can cause serious problems in deployed systems. Static analysis can identify coding errors and misunderstandings in the semantics of the programming language.

3. Dangerous function calls
Some API functions are considered potentially dangerous and insecure. The gets () function in C / C ++ is a good example, because it can easily produce destination buffer overflow conditions that can impact integrity. Other function calls can have implementation specific behaviors that make them unsafe. Unsafe function calls are easily identified using a static analysis which can search for a list of unsafe functions.

4. Misuse of cryptography
Cryptographic functions play an important role in the confidentiality of data, whether it is in motion or at rest. However, few developers are experts in cryptography, and the misuse of the cryptographic functions of the C library can lead to security issues, especially the use of weak algorithms, like Data Encryption Standard (DES) and MD5, or misuse of cryptography. Other examples include using hard-coded keys or salt data for hashes. The misuse of cryptography can impact confidentiality and integrity. Fortunately, these problems are easy to identify using static analysis.

5. Corrupted data issues
Contaminated data presents one of the most difficult problems for developers and can also impact integrity and confidentiality. Basically, contaminated data is a condition where data entering a system is not validated to remove malicious elements and ensure that it is within the expected range of values. It is very difficult to spot data injection vulnerabilities using human after-the-fact inspection.

In order to detect corrupted data issues, data that enters the system through any form of input (for example, users, devices, or sockets) should be traced from its source (where it enters the system). software) to their receiver (where they are used). And before that data is used in API calls, to access data structures, or any part of programming logic, it needs to be validated. Otherwise, it could lead to data injection exploits, such as format string injection, Lightweight Directory Access Protocol (LDAP) injection, or SQL injection. Static analysis can calculate across these streams and provide easy-to-understand warnings to help programmers prevent dangerous situations. To do this well, static analysis must perform data flow analysis and abstract execution to assess which execution flows are possible.

Static analysis to detect vulnerabilities
Static Analysis, also known as Static Application Security Testing (SAST), inspects an application’s source and binary code for possible security vulnerabilities, including the top five coding errors above. Because SAST can be used in developer continuous integration / continuous development (CI / CD) workflows, it supports and does not slow down agile development processes. In fact, it can speed up software development and reduce costs by uncovering flaws while a developer is writing code, so they can be fixed before testing and long before an application goes into production. As such, SAST performs a critical function in improving code security and should be part of any “shift left” DevSecOps effort.

Comments are closed.