GSoC: making static analysis with kiskadee

This post will cover some static analysis made with kiskadee 0.2.2 [1], and what are our plans for the next major release. We will present two packages as example, demonstrating the use of the plugins and the analyzers available. Currently, kiskadee uses four static analyzers:

  • Cppcheck, version 1.79 [2]
  • Flawfinder, version 1.31 [3]
  • Clang-analyzer, version 3.9.1 [4]
  • Frama-c, version 1.fc25 [5]

In the production environment two plugins are running: the debian plugin and the anitya plugin. The anitya plugin is our mainly plugin, because with it we can monitor and analyze several upstream that are packed in Fedora. We already have talked deeply about this two plugins, here on the blog. The projets that we will show here was analyzed by the cppcheck and flawfinder tools. These projects are the Xe [6] project, monitored by the anitya plugin, and the acpitool [7] project, monitored by the debian plugin.

The Xe project was, initially, monitored by the Anitya service. The upstream released a new version, and this event was published on the fedmsg bus, by the Anitya service. The Figure One, shows the new release of the Xe project, and the Figure Two, shows the event published on fedmsg.

Figure One: New Xe release.

Figure Two: The new release event.

The anitya plugin behavior is presented on the Figure Four. Every time that the Anitya service, publish a new release event, the fedmsg-hub daemon will receive it and send it to the anitya plugin. If the new release is hosted in a place where the anitya plugin can retrieve it source code, a analysis will be made.

Figure Four: anitya plugin behavior.

The Figure Five shows a static analysis made by the flawfinder analyzer, on the Xe source code. This analysis was only possible because the anitya plugin can receive new release events published on fedmsg. On this post, we talk how this integration was made. The Figure Six shows a static analysis made by the cppcheck analyzer, also on the Xe source code.

Figure Five: Flawfinder analysis.

Figure Six: Cppcheck analysis.

The second project that we analyzed was the acpitool package, that was monitored by the debian plugin. The source code of this package was retrieved using the dget tool, available in the devscripts package. The Figure Seven presents part of the analysis made by cppcheck.

Figure Six: Cppcheck analysis.

All the analysis presented here, can be found on two backups of the kiskadee database, available here on the blog, on the following links:

You can download these backups, import then to a postgresql database, and check several other analysis that we already made. Note that this backups are before the architecture change, that we talked on the post Improvements in kiskadee architecture.

The next major release of kiskadee will bring something that we believe that will permit us to integrates kiskadee with other tools. We will start the development of a API, that will provide several endpoints to consume our database. This API is a new step to reach one of our objectives, that is facilitate the process of integrate static analyzers on the cycle of development of software.

[1]https://pagure.io/kiskadee/releases
[2]http://cppcheck.sourceforge.net/
[3]https://www.dwheeler.com/flawfinder/
[4]https://clang-analyzer.llvm.org/
[5]https://frama-c.com/
[6]https://github.com/chneukirchen/xe
[7]https://sourceforge.net/projects/acpitool/