Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/8/2021
10:00 AM
Walter Capitani
Walter Capitani
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Top 5 'Need to Know' Coding Defects for DevSecOps

Integrating static analysis into the development cycle can prevent coding defects and deliver secure software faster.

Security practitioners are accustomed to intervening at the end of the software development process to identify security vulnerabilities, many of which could have been prevented with earlier intervention. To address this problem, developers who are already under pressure to deliver increasingly complex software faster and less expensively are being recruited to implement security earlier in the development cycle under the "shift-left" movement.

To understand the obstacles facing developers in meeting new security requirements, consider the five most common coding defects and how to address them.

Related Content:

Why the Weakest Links Matter

Building an Effective Cybersecurity Incident Response Team

New From The Edge: 7 Infamous Moments in Adobe Flash's Security History

1. Memory Errors
Errors in reading memory can potentially impact confidentiality and integrity by leaking sensitive information, while errors in writing memory can potentially subvert the flow of execution, which can affect all three components of the security triad: confidentiality, integrity, and availability. Common examples include buffer overrun/underrun and use-after-free (UAF) errors. Even the most skilled programmers can inadvertently generate these underlying flaws, which are difficult to detect and can be found even in well-tested, safety-certified code. While coding standards are often employed to reduce memory errors, they are not sufficient. Deep static analysis, data flow analysis, and symbolic execution are absolutely required to detect memory errors early in the development cycle.

2. Programming Errors
This class of errors is primarily 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 can be exploitable, may not manifest during functional and regression testing, even if they result in corrupt program state. Nevertheless, they can lead to serious problems in deployed systems. Static analysis can identify coding errors and misunderstandings in programming language semantics.

3. Dangerous Function Calls
Certain API functions are considered potentially harmful and unsecure. The gets() function in C/C++ is a good example, as it can easily produce destination buffer overflow conditions that can impact integrity. Other function calls may have implementation-specific behaviors that make them dangerous. Dangerous function calls are easily identified using static analysis that can search for a list of dangerous functions.

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

5. Tainted Data Issues
Tainted data presents one of the most challenging issues for developers, and it, too, can impact integrity and confidentiality. At its core, tainted data is a condition where data that flows into a system is not validated to eliminate malicious elements and ensure it is within the expected value range. Detecting data-injection vulnerabilities is very hard using human inspection after the fact.

In order to detect tainted data issues, data that flows into the system through any form of input (e.g., users, devices, or sockets) needs to be traced from its source (where it enters the software) to its sink (where it's used). And before this data is used in API calls, to access data structures, or in any part of the 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 compute through these flows 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 evaluate which execution flows are possible.

Static Analysis for Detecting Vulnerabilities
Static analysis, also known as static application security testing (SAST), inspects an application's source and binary code to detect possible security vulnerabilities, including the top five coding errors above. Since SAST can be used within developers' continuous integration/continuous development (CI/CD) workflows, it supports and does not slow down agile development processes. In fact, it can accelerate software development and reduce costs by discovering flaws while a developer is writing code, so they can be fixed before testing and well before an application goes into production. As such, SAST serves a critical function for improving code security and should be part of any "shift left" DevSecOps effort.

Walter Capitani, Director, Technical Product Management for GrammaTech, is a recognized expert in embedded and enterprise software security. He has led global product development teams focused on safety-critical and secure software, SaaS application performance, file ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31476
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 10.1.3.37598. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the han...
CVE-2021-31477
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of GE Reason RPV311 14A03. Authentication is not required to exploit this vulnerability. The specific flaw exists within the firmware and filesystem of the device. The firmware and filesystem contain hard-...
CVE-2021-32690
PUBLISHED: 2021-06-16
Helm is a tool for managing Charts (packages of pre-configured Kubernetes resources). In versions of helm prior to 3.6.1, a vulnerability exists where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository. This...
CVE-2021-32691
PUBLISHED: 2021-06-16
Apollos Apps is an open source platform for launching church-related apps. In Apollos Apps versions prior to 2.20.0, new user registrations are able to access anyone's account by only knowing their basic profile information (name, birthday, gender, etc). This includes all app functionality within th...
CVE-2021-32243
PUBLISHED: 2021-06-16
FOGProject v1.5.9 is affected by a File Upload RCE (Authenticated).