Programmer's Day: A day to celebrate and evaluate how to audit your code

Programmer’s Day: Resources to audit your code

Taking advantage of the celebration of the Day of the Programmer, we share some audit tools to evaluate the security of your code

Taking advantage of the celebration of the Day of the Programmer, we share some audit tools to evaluate the security of your code

September 13 is the 256th day of the year. These three digits may not mean anything to many people, but for those of us who work in different areas of computing it represents the number of whole numbers — integers starting at and increasing from zero — that can be represented with one 8-bit byte (from 0 to 255). Since this unit of measurement is fundamental in computing, this value is taken to define the Day of the Programmer, which generally falls on September 13.

With this in mind, we feel now is as good a time as any to recognize the work of people who create solutions through code that allow us to continue to enjoy many of the technologies that we use every day. In previous articles we have addressed related topics, such as the basic principles and controls that should be implemented for safe development, associated myths related to safe development, and we have even shared recommendations for the tips for safe development in iOS. And given that in all these deliveries we have always tried to emphasize the importance of auditing the code,  we’ll take this opportunity to delve into some very useful tools for this stage.

Know the vulnerabilities: Key to safe development

Although new vulnerabilities are discovered and published all the time, in the case of application development, the top ten most common vulnerabilities have remained the same over the last five years. This can be seen in the report published by OWASP by comparing the sheer number of vulnerabilities reported in 2017 with that of 2013. This makes us believe that many developers still make the same mistakes, either because they do not know these vulnerabilities exist or because they do not take the time to check their code for such flaws/weaknesses/vulnerabilities.

If you want your application to be secure, you should start by understanding the vulnerabilities that may affect it, or at least the most common ones. On the OWASP site, you will not only find detailed information about each vulnerability, but also a large number of tools and projects that will allow you to improve your development based on good practices.

Audit your code while you write it

There are many and varied source code analysis tools that can be used in Static Application Security Testing (SAST). SAST technologies are designed to analyze the source code in order to identify vulnerabilities before compile time.

SAST solutions can be integrated directly into the development environment and use static code analysis techniques to alert the developer of all types of errors and vulnerabilities that may exist in the code. This immediate feedback is very useful, especially when compared to discovering a vulnerability  later on  the development cycle.

These analyses allow developers to monitor their code constantly and identify problems early. In addition, code review provides detailed information that helps rapid mitigation and greater code integrity.

While these tools are very useful when identifying known vulnerabilities, such as SQL injections or buffer overflows, the truth is that there are many other types of vulnerabilities that are more difficult to detect automatically, such as configuration errors, authentication problems or errors in software logic. In addition, since SAST tools do not actually execute the code, another major problem is usually false positives, which can generate distractions or waste of time in your review. It is important to choose the right tools, taking into account the programming language, the development environment, the type of code that is going to be analyzed and the vulnerabilities it detects.

If you want to start using these tools, we recommend that you review the list published by OWASP, which includes both your own projects and other open source options. You can also check the list published in Wikipedia, ordered by programming language and with some options to audit compiled code.

Include security in your tests

All software must be tested before being put into production. At this stage, in addition to verifying that the application has the desired behavior and that there are no unexpected errors, it is also important to do your best to try to ensure that it is safe and has no vulnerabilities. For this, Dynamic Analysis Security Testing (DAST) tools can be used. DAST tools, instead of examining the source code, run outside the application and launch malicious requests against it in order to discover vulnerabilities by analyzing the responses they receive.

Since the application is tested in DAST at run time, it is not necessary to have the source code to audit it. In addition, at this stage other types of vulnerabilities that have not been detected previously with SAST may be detected, such as bad configurations, insecure protocols or logical problems. Unlike the static analysis that can be used immediately, however, in this analysis it is necessary to customize the rules against these possible scenarios (bad configurations, insecure protocols, etc.) make and adapt the requests covering all possible entries according to the application to be analyzed.

There are numerous dynamic analysis tools that you can use, although unfortunately most of them are paid licenses, given the high maintenance they require. Anyway, if you want to review a complete list, which includes both commercial and open source options, we recommend that you review the OWASP list of Vulnerabilities Scanners.

Finally, always apply good practices of safe development, since no automated tool will do it for you. Remember to always keep your tools updated, both the IDE and the plugins, plus other additional applications that you manage, and it always eliminate the modules and files that are not used. Do not forget to record all the events in security logs and avoid showing the error messages as they are shown by the system.

Remember: quality software must also be secure software!

Discussion