Source: Unsplash (Markus Spiske)
Testing is an important part of the software development lifecycle. There are many types of testing, each of which solves its own problem. Today I want to talk about finding security issues in code.
Obviously, in the modern realities of software development, it is important to ensure process safety. At one time, the special term DevSecOps was even introduced. This term refers to a number of procedures aimed at identifying and eliminating vulnerabilities in an application. There are specialized open source solutions for checking vulnerabilities in accordance with standards OWASP, which describe the different types and behavior of vulnerabilities in the source code.
There are different approaches to solving security problems, for example, static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), software component analysis (Software Composition Analysis), and so on.
Static application security testing detects bugs in already written code. This approach does not require running the application, which is why it is called static analysis.
I will focus on static code analysis and use a simple open source tool to demonstrate everything in practice.
Why I chose an open source static code security analysis tool
There are a number of reasons for this: first, it’s free, because you are using a tool developed by a community of like-minded people who want to help other developers. If you have a small team or startup, you have a great opportunity to save money by using open source software to test the security of your codebase. Second, it saves you the hassle of hiring a separate DevSecOps team, further reducing your costs.
Good open source tools are always built with increased flexibility in mind. Therefore, they can be used in almost any environment, covering a wide range of tasks. It is much easier for developers to make such tools friends with the system that they have already built while working on their projects.
But there may be situations where you need a feature that is not available in your chosen tool. In this case, you have the opportunity to fork its code and develop on its basis your own tool with the functionality you need.
Since in most cases the development of open source software is actively influenced by the community, the decision to make changes is made quite quickly and to the point: the developers of the open source project rely on user feedback and suggestions, on their reports of bugs and other problems.
Using Graudit to Analyze Code Security
For static code analysis, you can use various open source tools, there is no universal tool for all programming languages. Some of them follow OWASP guidelines and try to cover as many languages as possible.
Here we will use Graudit, a simple command line utility that will allow us to find vulnerabilities in our codebase. It supports different languages, but still their set is limited. Graudit is developed on the basis of the grep utility utility, which was released under the GNU license.
There are similar tools for static code analysis – Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder, and so on. But Graudit is very flexible and has minimal technical requirements. However, you may have problems that Graudit cannot solve. Then you can look for other options here on this list…
We can integrate this tool into a specific project, or make it available to a selected user, or use it simultaneously in all our projects. This is also where Graudit is flexible. So let’s clone the repo first:
$ git clone https://github.com/wireghoul/graudit
Now let’s create a symlink for Graudit to use it in command format
$ cd ~/bin && mkdir graudit $ ln --symbolic ~/graudit/graudit ~/bin/graudit
Add an alias to .bashrc (or whatever config file you are using):
#------ .bashrc ------ alias graudit="~/bin/graudit"
$ source ~/.bashrc # OR $ exex $SHELL
Let’s check if the installation was successful:
$ graudit -h
If you see something similar, then everything is fine.
I will be testing one of my existing projects. Before running the tool, it needs to pass the database corresponding to the language in which my project is written. The databases are located in the ~ / gradit / signatures folder:
$ graudit -d ~/gradit/signatures/js.db
So, I tested two js files from my project, and Graudit dumped information about vulnerabilities in my code to the console:
You can try to test your projects in the same way. The list of databases for different programming languages can be viewed here…
The advantages and disadvantages of Graudit
Graudit supports many programming languages. Therefore, it is suitable for a wide range of users. It can compete with any free or paid counterparts. And it is very important that improvements are still being made to the project, and the community not only helps the developers, but also other users who are trying to figure out the tool.
This is a handy tool, but so far it is not always able to indicate exactly what the problem is, associated with a suspicious piece of code. The developers continue to refine Graudit.
But in any case, it is useful to pay attention to potential security problems in your code using such tools.
In this article, I have considered only one of many ways to find vulnerabilities – static application security testing. Static code analysis is easy, but this is just the beginning. To learn more about the security of your codebase, you need to integrate other types of testing into the software development lifecycle.
Reliable VPS and the correct choice of a tariff plan will allow you to be less distracted from development by unpleasant problems – everything will work without failures and with a very high uptime!