Do you keep your third-party codebase up to date?
Surveys show that software developers almost never update third-party libraries once they are included in the code base, even though in most cases these libraries are easily updated and do not break application functionality. As a result, the risk to the enterprise increases and the complexity of system repair increases.
The security firm recently analyzed 13 million test results from about 860,000 customer code repositories, containing more than 301,000 unique software repositories. It also surveyed about 2,000 developers about their use of third-party software.
The analysis shows that 79% of developers do not update the third-party libraries they use in their code base. Although third-party libraries are constantly changing — both secure and insecure are changing just as fast — developers are largely not updating. Even among the more mature and actively maintained code repositories, 73% of developers who added third-party libraries never updated them. Overall, 50% of code repositories took more than 21 months to update, and 25% were not updated for as long as 4 years.
While some developers were told that they were using a code stock that acted quickly in the event of a bug and that 25% of bugs were resolved within a week, half of all security vulnerabilities were not fixed within seven months of the fix being released.
It is not a workflow problem that third-party libraries are not updated or update slowly, but rather a lack of more information about how vulnerable libraries affect applications, concerns about potential application outages, and cultural issues such as not understanding the severity or impact of the vulnerability.
For example, if developers do not understand that SQL injection is dangerous, they may think it is not important. Explain the code path that connects first-party code to a third-party vulnerability to help developers understand where their applications are vulnerable and why they are being attacked.
In addition, developers often worry that updating a code base to fix bugs will end up breaking something else. Although 69% of vulnerabilities in third-party libraries involve a small number of small patches that cause damage, developers are often unaware of this fact.
Code security is ignored
Managers should allow time to deal with vulnerabilities and other security-related matters. When adding a new code base, developers often regard functionality and licensing as important considerations, rather than security. 63% said they always consider licensing when evaluating new code bases, and 84.2% of developers do not always consider security when evaluating third-party code bases.
Numerous investigations have shown that vulnerable third-party code libraries and open source code exist to varying degrees in almost all modern enterprise applications. The average enterprise application today contains a whopping 528 open source components, and an average of 158 bugs are found in each code base, many of them critical.
Therefore, when a third code base in an application is not kept up to date, the consequences for the enterprise can be severe. First, the risk of violation may be higher, and second, the complexity of the patch is increased. The longer the vulnerability, the more complex it is to fix, the longer it takes to patch, and the greater the risk of breaking the application.
For libraries that are both directly dependent and transitive, patching can take up to 2.5 times longer. The same goes for complex bugs, such as arbitrary code execution flaws, which can take twice as long to fix compared to typical problems. Remote code execution and denial of service errors also take longer to resolve.
advice
In today’s agile development, more and more open source code and components are introduced into applications by developers. Code security is related to system security and affects network security. With the practice of DevsecOps, security has moved from a proprietary inspection department into the entire development process, and the failure to update third-party libraries poses a significant risk to code security. On the one hand, in the stage of static code, we should timely monitor the code by static code security detection tools and open source code security detection tools; on the other hand, we should strengthen the attention of developers to security, and formulate certain security specifications can reduce the generation of problematic codes to a certain extent.
Reference link:
www.woocoom.com/b021.html?i…
www.securityweek.com/most-develo…