Identifying and correcting security vulnerabilities in applications has become more increasingly vital with Static Code Analysis tools in conjunction with manual code reviews. Static Code Analysis includes an automated software tool that examines a program’s source code without actually executing it. This type of analysis is used to identify different kinds of security issues, obscure logic problems, bugs and defects, and more. Even more importantly, it is becoming common to have an organizational policy that includes the requirement. It is already a compliance requirement for organizations that must comply with Payment Application Data Security Standard (PCI PADSS).
There are a plethora of vendors with static code analysis tools that we won’t be comparing here but rest assured the most common development languages are supported. These tools can be very helpful in determining adherence to secure coding standards. But one of the biggest challenges to getting started is the shock of a report after an initial codebase is analyzed. There could be tens of thousands of issues found when an analysis is completed for a large codebase that has never been scanned before. Going through the static code analysis report can be beneficial in helping to identify high risk security areas but can also be time consuming to research what may result in false alarms. Either way, the effort must be made to review such a report as it helps demonstrate due diligence by documenting the review of potential vulnerabilities. For the software engineer being asked to address issues found in a large legacy code base, it can present more stress added on to the workload for developing the next release.
If a threat model was completed during the design phase of the application development, it can help to describe the security objectives or privacy requirements for the application and how those objectives mitigate threats in possible misuse or abuse cases. The main focus should have been on protecting the system and the information being processed. Furthermore, an attack surface analysis helps with defining how an external adversary may attempt to attack the application and focuses more on the high risk areas where there may be more exposure such as Internet connected interfaces. If these tools were not used during the development phase, maybe other types of risk based approaches provided the same result. But if not, it’s advisable to start having these conversations with all stakeholders so that the security objectives and attack surface mitigations can be well defined. It’s likely that an Advance Persistent Threat (APT), albeit with limited knowledge of the system, would use similar tools when attempting to identify an application’s potential weaknesses for the purpose of exploiting them.
Requirement for static code analysis has become more commonly integrated into an organizations secure application development processes and it helps with adherence to ISO 27034. It’s also advisable to integrate Threat Modeling and Attack Surface Analysis into the lifecycle as well. These tools are helpful in prioritization efforts so that identified issues in static code analysis reports can be focused on the most important security features of an application first. This will undoubtedly help the security reviewer gain traction on an effort that may seem overwhelming at first.
Find Andy on LinkedIn
See previous content from Andy_Good
Start a conversation with Andy on Twitter