Gurur Yetiskin >Homepage

Source Code Review I - Enterprise Issues and Security

Hello, I'm Gurur Yetişkin. I've decided to start writing a series of articles, and I've chosen source code review as the topic. I don't know how long this article series will last, but we will interpret it by referencing the OWASP Code Review Guide v2. Hopefully, it will be a useful resource for readers.

Firstly, we should discuss why we have chosen OWASP Code Review Guide v2 as our reference. This choice is primarily based on the fact that it is one of the OWASP standards commonly referenced by individuals working in the field of Application Security. Additionally, it is led by Eoin Keary, who is one of the most successful individuals in the field. These reasons alone are quite sufficient to answer this question.

Secure code review is arguably one of the most effective techniques for early detection of security vulnerabilities. When used in conjunction with automated and manual penetration testing, code review can significantly enhance the cost-effectiveness of an application security verification effort. Especially if your company has a bug bounty program, deploying a scope without conducting source code review can result in significant financial harm.

MITRE, in the CWE project, has cataloged approximately 1000 different types of software weaknesses. There are hundreds of different ways in which software developers can introduce security vulnerabilities. Each of these weaknesses is intricate, and many of them are quite challenging. Software developers are not typically taught about these vulnerabilities, and most do not receive on-the-job training regarding these issues. This is, in fact, the biggest problem that arises. Often, Product Owners assume that developers' sole goal is to make a button click open a page and list products when we consider a project, thinking about tasks like 'when you click button x, page y should open, and the task should be marked as complete.' For developers, it's not just about the architectural priorities that work in the background. Personally, in all the companies I have worked as a manager so far, I have conducted penetration testing by obtaining permission from the company that develops all 3rd-party software. Since software is essentially a black box, it is extremely difficult for a customer to understand the difference between good code and insecure code. Therefore, I proceed in this way to keep the company at the maximum security level.

By the way, I recommend reading Mert Sarıca's articles on Treadmill and Smart Grill. If I were a manufacturer, I personally wouldn't want my product to be featured in such an article.

Returning to our topic, apart from developers who do not prioritize or ignore security, another common situation is when people make excuses like 'We haven't been hacked so far,' 'We have annual security products that cost millions,' or 'We trust our employees.' These are some of the common excuses for not taking security seriously.

Secure code review not only ensures that a company's application developers are following secure development practices but also enables us to identify security vulnerabilities related to the features and design of the application during development.

We conduct penetration testing every year; isn't this sufficient? Penetration testing is typically a black-box point-in-time test and should be repeated for each release. There are also privacy, compliance, and stability, as well as usability concerns that may not be covered by penetration tests but can be addressed through code reviews.

It should not be forgotten that a single method cannot detect all security vulnerabilities that a software project may encounter. However, the following processes are essential requirements for software development; Automatic Source Code Scanning, Automated Security Vulnerability Scanning, Manual Penetration Testing, Source Code Analysis. Nevertheless, taking a comprehensive defense approach will reduce the risk of unknown issues as well.

We have reached the end of my first article. It was a content piece where we interpreted OWASP Code Review Guide v2 and discussed the common corporate challenges and the reasons for its necessity. For my next article, I plan to have a piece where we will delve into the technical aspects and methodologies, thanks.