Secure Code Review is the process of auditing the source code to verify that proper security controls are in place. It’s always better to write secure code than fixing the production application security vulnerabilities. The best way to achieve this goal is to implement security in the complete application development process. To start with it, Secure Code Review comes into picture starting from development all the way to deployment.

We can categorize secure code review into two types: Manual and Automated.

Manual

Manual Code review involves reading the source code line-by-line in an attempt to identify potential vulnerabilities in software architecture, design and modules, which could be missed by automation tools.

Automated

Automated Code review involves the use of static code analysis tools which detect common vulnerabilities like SQL injection, Cross Site Scripting (XSS) etc. This is like low hanging fruits for hackers. You can also integrate these tools into your CI/CD pipeline. Whenever a developer checks in new code to source control, the automated static code analysis tool runs and provides a report of its assessment. Automated tools use specific coding rules to find security issues and may vary in different languages.

Automating coding standards

There is a way to automate certain (application specific) coding standards by creating custom coding rules in the automated tools. Sonarqube is an excellent opensource Static Code Analyzer which helps you to build custom rules.

Let’s examine where we can use a custom security rule with the below sample java code which creates a new file in the application:

In this sample code, fileName string value is returned by FileProcess.getFilename() method and if it returns a value from client-side input (attacker may have the control). Then the application is vulnerable to file injection attacks where the attacker can change the file extension to .exe, .bat, .sh etc. Therefore, you need to validate the fileName string against its extension and name the file according to the application standards. Here, FileValidator.validate() method takes care of that security validation. If any developer forgets to add this validation during file processing, then it’s a security risk. Automated tools may not be able to find these kinds of issues.

Custom rules in automated tools come in handy in these kinds of scenarios where we can create it with the definition of, “if there is any file processing in the code, then check for validation method, which is called or not called, if not called then report a vulnerability”.

You can create custom rules depending on the application requirements. We can also define custom rules to improve the code quality as well.

By integrating an automatic static code analyzer tool, together with custom rules in your CI/CD pipeline, you could find the vulnerabilities early and thus achieve Continuous Secure Coding as a practice in your development process/lifecycle.

 

References

Here are the resources that could help you to create custom rules for different programming languages:

Sample custom rules developed for the above languages are available in Github:

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*