使用命令行工具 Graudit 来查找你代码中的安全漏洞
安全 静态审计

> 
> 凭借广泛的语言支持，Graudit 可以让你在开发过程中的审计你的代码安全。
> 
> 
> 


![](/data/attachment/album/202009/03/114037qhi2h282wghbp74n.jpg)


测试是软件开发生命周期（SDLC）的重要组成部分，它有几个阶段。今天，我想谈谈如何在代码中发现安全问题。


在开发软件的时候，你不能忽视安全问题。这就是为什么有一个术语叫 DevSecOps，它的基本职责是识别和解决应用中的安全漏洞。有一些用于检查 [OWASP 漏洞](https://owasp.org/www-community/vulnerabilities/)的开源解决方案，它将通过创建源代码的威胁模型来得出结果。


处理安全问题有不同的方法，如静态应用安全测试（SAST）、动态应用安全测试（DAST）、交互式应用安全测试（IAST）、软件组成分析等。


静态应用安全测试在代码层面运行，通过发现编写好的代码中的错误来分析应用。这种方法不需要运行代码，所以叫静态分析。


我将重点介绍静态代码分析，并使用一个开源工具进行实际体验。


### 为什么要使用开源工具检查代码安全？


选择开源软件、工具和项目作为开发的一部分有很多理由。它不会花费任何金钱，因为你使用的是一个由志趣相投的开发者社区开发的工具，而他们希望帮助其他开发者。如果你有一个小团队或一个初创公司，找到开源软件来检查你的代码安全是很好的。这样可以让你不必单独雇佣一个 DevSecOps 团队，让你的成本降低。


好的开源工具总是考虑到灵活性，它们应该能够在任何环境中使用，覆盖尽可能多的情况。这让开发人员更容易将该软件与他们现有的系统连接起来。


但是有的时候，你可能需要一个功能，而这个功能在你选择的工具中是不可用的。那么你就可以选择复刻其代码，在其上开发自己的功能，并在你的系统中使用。


因为，大多数时候，开源软件是由社区驱动的，开发的速度往往是该工具的用户的加分项，因为他们会根据用户的反馈、问题或 bug 报告来迭代项目。


### 使用 Graudit 来确保你的代码安全


有各种开源的静态代码分析工具可供选择，但正如你所知道的，工具分析的是代码本身，这就是为什么没有通用的工具适用于所有的编程语言。但其中一些遵循 OWASP 指南，尽量覆盖更多的语言。


在这里，我们将使用 [Graudit](https://github.com/wireghoul/graudit)，它是一个简单的命令行工具，可以让我们找到代码库中的安全缺陷。它支持不同的语言，但有一个固定的签名集。


Graudit 使用的 `grep` 是 GNU 许可证下的工具，类似的静态代码分析工具还有 Rough Auditing Tool for Security（RATS）、Securitycompass Web Application Analysis Tool（SWAAT）、flawfinder 等。但 Graudit 的技术要求是最低的，并且非常灵活。不过，你可能还是有 Graudit 无法满足的要求。如果是这样，你可以看看这个[列表](https://project-awesome.org/mre/awesome-static-analysis)的其他的选择。


我们可以将这个工具安装在特定的项目下，或者全局命名空间中，或者在特定的用户下，或者任何我们喜欢地方，它很灵活。我们先来克隆一下仓库。



```
$ git clone https://github.com/wireghoul/graudit

```

现在，我们需要创建一个 Graudit 的符号链接，以便我们可以将其作为一个命令使用。



```
$ cd ~/bin &amp;&amp; mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit

```

在 `.bashrc` （或者你使用的任何 shell 的配置文件）中添加一个别名。



```
#------ .bashrc ------

alias graudit="~/bin/graudit"

```

重新加载 shell：



```
$ source ~/.bashrc # 或
$ exex $SHELL

```

让我们通过运行这个来检查是否成功安装了这个工具。



```
$ graudit -h

```

如果你得到类似于这样的结果，那么就可以了。


![Graudit terminal screen showing help page](/data/attachment/album/202009/03/114101pd3zzp49p1jr9pmb.png "Graudit terminal screen showing help page")


*图 1 Graudit 帮助页面*


我正在使用我现有的一个项目来测试这个工具。要运行该工具，我们需要传递相应语言的数据库。你会在 signatures 文件夹下找到这些数据库。



```
$ graudit -d ~/gradit/signatures/js.db

```

我在现有项目中的两个 JavaScript 文件上运行了它，你可以看到它在控制台中抛出了易受攻击的代码。


![JavaScript file showing Graudit display of vulnerable code](/data/attachment/album/202009/03/114108snbmb62ok4neu9un.png "JavaScript file showing Graudit display of vulnerable code")


![JavaScript file showing Graudit display of vulnerable code](/data/attachment/album/202009/03/114116l1hhrev4hqf5sz4v.png "JavaScript file showing Graudit display of vulnerable code")


你可以尝试在你的一个项目上运行这个，项目本身有一个长长的[数据库](https://github.com/wireghoul/graudit#databases)列表，用于支持不同的语言。


### Graudit 的优点和缺点


Graudit 支持很多语言，这使其成为许多不同系统上的用户的理想选择。由于它的使用简单和语言支持广泛，它可以与其他免费或付费工具相媲美。最重要的是，它们正在开发中，社区也支持其他用户。


虽然这是一个方便的工具，但你可能会发现很难将某个特定的代码识别为“易受攻击”。也许开发者会在未来版本的工具中加入这个功能。但是，通过使用这样的工具来关注代码中的安全问题总是好的。


### 总结


在本文中，我只介绍了众多安全测试类型中的一种：静态应用安全测试。从静态代码分析开始很容易，但这只是一个开始。你可以在你的应用开发流水线中添加其他类型的应用安全测试，以丰富你的整体安全意识。




---


via: <https://opensource.com/article/20/8/static-code-security-analysis>


作者：[Ari Noman](https://opensource.com/users/arinoman) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Testing is an important part of the software development lifecycle (SDLC), and there are several stages to it. Today, I want to talk about finding security issues in the code.

You can't ignore security when developing a piece of software. That's why there is a term called DevSecOps, which is fundamentally responsible for identifying and resolving security vulnerabilities in an application. There are open source solutions for checking [OWASP vulnerabilities](https://owasp.org/www-community/vulnerabilities/) and which will derive insights by creating a threat model of the source code.

There are different approaches to handling security issues, e.g., static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), software composition analysis, etc.

Static application security testing runs at the code level and analyzes applications by uncovering errors in the code that has already been written. This approach doesn't require the code to be running, which is why it's called static analysis.

I'll focus on static code analysis and use an open source tool to have a hands-on experience.

## Why use an open source tool to check code security

There are many reasons to choose open source software, tools, and projects as a part of your development. It won't cost any money, as you're using a tool developed by a like-minded community of developers who want to help other developers. If you have a small team or a startup, it's good to find open source software to check your code security. This keeps you from having to hire a separate DevSecOps team, keeping your costs lower.

Good open source tools are always made with flexibility in mind, and they should be able to be used in any environment, covering as many cases as possible. It makes life easier for developers to connect that piece of software with their existing system.

But there can be times where you need a feature that is not available within the tool that you chose. Then you have the option to fork the code and develop your own feature on top of it and use it in your system.

Since, most of the time, open source software is driven by a community, the pace of the development tends to be a plus for the users of that tool because they iterate the project based on user feedback, issues, or bug-posting.

## Using Graudit to ensure that your code is secure

There are various open source static code analysis tools available, but as you know, the tool analyzes the code itself, and that's why there is no generic tool for any and all programming languages. But some of them follow OWASP guidelines and try to cover as many languages as they can.


Here, we'll use [Graudit](https://github.com/wireghoul/graudit), which is a simple command-line tool that allows us to find security flaws in our codebase. It has support for different languages but a fixed signature set.

Graudit uses grep, which is a GNU-licensed utility tool, and there are similar types of static code analysis tools like Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder, etc. But the technical requirement it has is minimal and very flexible. Still, you might have requirements that are not served by Graudit. If so, you can look at this [list](https://project-awesome.org/mre/awesome-static-analysis) for other options.

We can install this tool under a specific project, or in the global namespace, or under a specific user—whatever we like, it's flexible. Let's clone the repo first:

`$ git clone https://github.com/wireghoul/graudit`


Now, we need to create a symbolic link of Graudit so that we can use it as a command:

```
$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit
```


Add an alias to .bashrc (or the config file for whatever shell you're using):

```
#------ .bashrc ------
alias graudit="~/bin/graudit"
```


and reload the shell:

```
$ source ~/.bashrc # OR
$ exex $SHELL
```


Let's check whether or not we have successfully installed the tool by running this:

`$ graudit -h`


If you get something similar to this, then you're good to go.

![Graudit terminal screen showing help page Graudit terminal screen showing help page](https://opensource.com/sites/default/files/uploads/graudit_1.png)

Fig. 1 Graudit help page

I'm using one of my existing projects to test the tool. To run the tool, we need to pass the database of the respective language. You'll find the databases under the signatures folder:

`$ graudit -d ~/gradit/signatures/js.db`


I ran this on two JavaScript files from my existing projects, and you can see that it throws the vulnerable code in the console:

![JavaScript file showing Graudit display of vulnerable code JavaScript file showing Graudit display of vulnerable code](https://opensource.com/sites/default/files/uploads/graudit_2.png)

![JavaScript file showing Graudit display of vulnerable code JavaScript file showing Graudit display of vulnerable code](https://opensource.com/sites/default/files/uploads/graudit_3.png)

You can try running this on one of your projects, and they have a long list of [databases](https://github.com/wireghoul/graudit#databases) included in the project itself for supporting different languages.

## Graudit pros and cons

Graudit supports a lot of languages, which makes it a good bet for users on many different systems. It's comparable to other free or paid tools because of its simplicity of use and broad language support. Most importantly, they are under development, and the community supports other users too.

Though this is a handy tool, you may find it difficult to identify a specific code as "vulnerable." Maybe the developers will include this function in future versions of the tool. But, it is always good to keep an eye on security issues in the code by using tools like this.

## Conclusion

In this article, I've only covered one of the many types of security testing—static application security testing. It's easy to start with static code analysis, but that's just the beginning. You can add other types of application security testing in your application development pipeline to enrich your overall security awareness.

## 1 Comment