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

10:00 AM
Walter Capitani
Walter Capitani
Connect Directly
E-Mail vvv

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
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-22
This affects all versions of package jquery-ui; all versions of package org.fujion.webjars:jquery-ui. When the "dialog" is injected into an HTML tag more than once, the browser and the application may crash.
PUBLISHED: 2021-01-22
Hyweb HyCMS-J1's API fail to filter POST request parameters. Remote attackers can inject SQL syntax and execute commands without privilege.
PUBLISHED: 2021-01-22
Hyweb HyCMS-J1 backend editing function does not filter special characters. Users after log-in can inject JavaScript syntax to perform a stored XSS (Stored Cross-site scripting) attack.
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver Vault Plugin prior to v0.0.6, Azure Plugin prior to v0.0.10, and GCP Plugin prior to v0.2.0 allow an attacker who can create specially-crafted SecretProviderClass objects to write to arbitrary file paths on the host filesystem, including /var/lib/kubelet/pods.
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver versions v0.0.15 and v0.0.16 allow an attacker who can modify a SecretProviderClassPodStatus/Status resource the ability to write content to the host filesystem and sync file contents to Kubernetes Secrets. This includes paths under var/lib/kubelet/pods that conta...