Myths and Realities of Code Security Review

This article consists of observations and notes on the process of code security review. We are not talking here about peer-to-peer reviews, where fellow programmers analyse each other’s code, including a focus on meeting secure coding requirements. This article focuses on code reviews conducted by independent consultants. Additionally, we leave beyond the scope of this article the question of why independent consultants are needed for code reviews and concentrate on the practice and internal aspects of conducting such reviews.

1. Handing over code for external review is not unsafe. In reality, it is no more dangerous than bringing a young specialist into development who may not be fully aware of the company’s security policies and the requirements placed on someone working with personal or payment data. In both cases, it is essential to ensure that information security management systems are implemented, representatives from both the client and the service provider are trained, and secure methods of code and report transmission are discussed.
2. Code auditors know your application’s technologies perfectly. Unfortunately, this is rarely the case. Code reviews often involve projects with mobile apps, web apps, APIs, backends, and auxiliary applications. Over the past year, we’ve reviewed code in Java, Kotlin, Ruby on Rails, Swift, PHP, 1C, and Elixir—no developer excels in all these stacks simultaneously at a high level. Hiring a separate auditor for each application is challenging organizationally and financially. Therefore, code auditors specialize in security vulnerabilities and develop expertise in that direction.
3. Developers and penetration testers view code differently. Indeed, developers wouldn’t think of intercepting user data by overlaying another screen. The best results come from a symbiosis of code auditors analysing the code and penetration testers guiding what to look for.
4. Using many different automatic code scanners is necessary. More often than not, applications provided for code review are not fully compiled/buildable, missing libraries or entire modules. In such cases, most automatic scanners don’t work.
5. Using automatic code scanners during development is pointless. Contrary to this belief, scanning code for potential vulnerabilities within the CI/CD process is effective and convenient during development. Combined with secure development practices and periodic external penetration tests, code scanning yields good results.
6. Code reviews can be done quickly. Understanding how an application works takes extra time. It involves searching for all user-inputted data, tracking data flow paths through applications, and sometimes creating UML process diagrams if available. A single UML diagram can save 2-3 days of code analysis. Additionally, code reviews are usually sustainable for 4-5 hours a day.
7. Auditors often seek the absence of certain functionality rather than vulnerable code. Auditors commonly look for missing features like lack of user data validation, absence of two-factor authentication, failure to check document ownership, etc. Manual code analysis is crucial in such cases, where automatic scanning is entirely ineffective.
8. Artificial intelligence can perform code security analysis. Not quite. Due to security concerns, AI can only analyse parts of the code. AI has its security limitations, and sometimes, the response is: “For security reasons, this information cannot be shown”. However, AI is useful for asking about method functionality or requesting vulnerability examples in specific technology stacks.
9. Learning how to do security code reviews on your own is impossible. The resource https://portal.securecodewarrior.com/ is excellent, though pricey. It allows practising on specific stacks. After mastering basic vulnerabilities, the OWASP Testing Guide and ASVS are valuable.
10. Code from OWASP TOP TEN examples is rare in modern projects. Developers in large modern projects regularly encounter security requirements, undergo training, and follow development blogs discussing security issues in their stack. Examples from OWASP TOP TEN are scarce in actively developed projects, but are more common in legacy projects.
11. Knowing ALL programming languages is necessary for code review. No. Understanding one system-level language at a senior developer level, one or two functional languages, having a moderate proficiency in JavaScript, working with databases, and having a grasp of application architecture is sufficient. Knowledge of cloud services is also beneficial.

In simple terms, ensuring effective code security is about being practical. This approach streamlines the process of protecting our digital environments. By dispelling myths and facing realities, these insights can guide us toward a future where code security isn’t just a task but a fundamental part of our mindset.