Secure Coding Guidelines
When software applications have vulnerabilities, it means high costs for the application maker. Some organizations pay more than $500,000 per security incident. The efforts used for the elimination of vulnerabilities in a software application should focus
- PDF / 235,537 Bytes
- 16 Pages / 504 x 720 pts Page_size
- 59 Downloads / 235 Views
Secure Coding Guidelines Introduction When software applications have vulnerabilities, it means high costs for the application maker. Some organizations pay more than $500,000 per security incident. The efforts used for the elimination of vulnerabilities in a software application should focus on secure coding, avoiding deploying any vulnerabilities in the production phase. Writing secure source code is a difficult task. It is very important to understand the implications of the code that is being written and to have a checklist of things that need to be checked. The checklist will help the developers pursue a fast verification of their code for well-known security problems. Usually, the verification is done by a security team and not by software developers or engineers. A software developer cannot be objective with their own code. The idea of a checklist should start from the following idea: verifying the source code that will process data outside of its domain and take into consideration the user input, the network communication, the process of the binary files, receiving output from database management systems or servers, and so on. When we work with a software application (doesn’t matter whether the application is a desktop, web, or mobile one), the idea that the application is secure because it was developed by a well-known company is just a myth. Don’t trust this notion. Companies that rely on this idea end up spending a huge amount of the budget on security incidents, maintenance, consultancy, and audit sessions. There are two environments in which a software application works, and its behavior is different in each environment. The software application that is in the analysis and development process within a company represents its circle of trust (at least, most companies think in this way and they enjoy considering their infrastructure very resistant to security attacks). The behavior of the software application in that circle of
© Marius Iulian Mihailescu and Stefania Loredana Nita 2021 M. I. Mihailescu and S. L. Nita, Pro Cryptography and Cryptanalysis, https://doi.org/10.1007/978-1-4842-6367-9_6
165
Chapter 6
Secure Coding Guidelines
trust represents the most critical environment in which an application can be developed and tested. No developer, IT security officer, or software analyst will hack his own code. For this purpose, some companies such as Microsoft used to have software development engineers in test (SDETs) who were tasked with breaking or attempting to break the code written by the software development engineers (SDEs). This environment is the comfort one. Once the application leaves that comfort zone and enters the real environment, the issues start happening. The trust boundary is hard and easy at the same time to be drawn and to create a delimitation between the comfort zone and the real zone. It’s not an easy task to achieve, especially if those applications are running in a virtualized infrastructure, cloud, or big data environments. In the comfort zone, a security threat is repres
Data Loading...
