Shulou(Shulou.com)06/03 Report--

This article mainly explains "what are the coding problems of DevSecOps". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the coding problems of DevSecOps".

Memory error

Memory read errors pose a potential threat to confidentiality and integrity due to disclosure of sensitive information, while memory write errors affect confidentiality, integrity, and availability because they change workflows. The more common memory problems are buffer overflow, insufficient buffer and release reuse. These problems are difficult to detect and even exist in code that has been repeatedly tested and considered safe, so they are inevitable for even the most experienced programmers. Although it is said that some code standards are enabled in an attempt to reduce memory errors, it is obviously not so effective. Therefore, in the early stage of the development cycle, memory errors need to be detected by means of deep static analysis, data flow analysis, symbol execution and so on.

Programming error

Such errors are mainly caused by the misuse of CCompact +, such as uninitialized variables, repeatedly releasing pointers, and indirect changes between symptomatic and non-symptomatic data. Some of the programming errors are exploited to attack, and even if they cause the program to crash, they may not show up in functional and regression tests. However, they do cause serious problems in deployed systems. Static quota analysis can identify code errors and ambiguities in programming semantics.

Risky function calls

There are some API functions that are considered to be dangerous and unsafe. For example, the gets () function in C _ blank + can easily cause cache overflow of the target address. Other function calls may also cause harm due to some behavior. Such risky function calls are easily identified in static analysis through a list of risk functions.

Cryptography abuse

Cryptography is particularly important in an environment that ensures data confidentiality. However, few developers are experts at the cryptographic level; to make matters worse, the abuse of cryptographic functions in the C language's own library can lead to security problems, such as encryption using weak algorithms such as DES and MD5, or using hard-coded keys and hashing salt data. Misuse of cryptography can affect confidentiality and integrity, but they can also be easily identified by static analysis.

Pollution data

Contaminated data means that the data is not verified and harmful content is removed when it enters the system, so it is impossible to guarantee that the data value is in the legal range. Polluting data is one of the biggest challenges for developers, as well as affecting confidentiality and integrity. It is difficult to detect data injection problems by manual inspection.

If you want to solve the problem of polluting data, you need to track the data that enters the system in any form (such as users, devices, sockets, etc.) from source to target. Data needs to be validated before it can be called by API, accessed into data structures, or entered into any programming logic. Otherwise, the attack threat of data injection may arise. Static analysis can be calculated in the workflow, providing simple and easy-to-understand alarms to keep programmers away from these dangerous situations.

Static analysis detects vulnerabilities

Static analysis, or static analysis security testing (SAST), detects possible security issues-- such as the five code issues mentioned above-- by examining the source code. Because SAST can be used in developers' CI/CD workflows, it does not slow down the agile development process. In fact, because it can find vulnerabilities when developers write code, thus reducing the cost of finding problems and fixing them before the application is launched-or even before testing, ultimately speeding up software development. Therefore, SAST plays a key role in improving code security and needs to be part of the secure left shift of DevSecOps.

Comment

In the process of moving security to the left, the real-time analysis, testing and discovery of vulnerabilities in the code is a major focus. This paper mentions some code problems that SAST can solve in DevSecOps, but SAST is not the only tool in the DevSecOps process. It also needs to combine IAST, software supply chain management and other tools to improve the DevSecOps tool chain and gradually increase the security of its own software development cycle.

Thank you for your reading, these are the contents of "what are the coding problems of DevSecOps?" after the study of this article, I believe you have a deeper understanding of what the coding problems of DevSecOps have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.