GSoC: Final Report


This is the final report of my work on Google Summer of Code program. My name is David Carlos and I am a Brazilian software engineering student, at University of Brasilia. I already work as programmer, and really love what I do for a living. When I am not working I am with my family and friends, enjoying good beer and listening to the best Brazilian music style, Samba.

Google Summer of Code 2017

The first time that I heard about GSoC was when a friend from University of Brasilia was accepted on the program, working with the Debian distribution. I already had contributed with open source projects before, but nothing compared with projects like Debian or Fedora. Participating on GSoC this year was the best programming experience that I have ever had. The felling of making part of the Fedora community and writing code that can be used by other people is the best thing that I got from the program. As my project was a new experimental tool, I think that my interaction with the community could be better. Receiving feedback of other Fedora developers, beyond my GSoC mentor, could have improved my skills as a programmer even more, as well as my interaction with the people that make Fedora happen.

Participating of GSoC this year put me on another level as programmer, and my main objective is to help the Fedora community even more, to keep delivering this great operating system.


Static analyzers are computer programs that analyze other computer programs. This is generally done by checking source code through static analysis methods. This is a good means to support software assurance, since static analysis can in theory enumerate all possible interactions in a program, having the potential to find rare occurrences that would be harder to find with automated testing.

kiskadee is a system designed to support continuous static analysis in software repositories using different static analyzers and to store this information in a database. Based on such database information, kiskadee will rank warnings reported by the different static analyzers, where warnings with the highest rank are more likely to indicate real and more critical software flaws, while warnings with the lowest rank are more likely to be false positives. In this context, a warning is a single issue produced by a static analyzer. Finally, kiskadee maps software flaws inserted in specific software versions, providing developers with a relatively small list of warnings to be investigated in a suggested order.

To accomplish the process of monitoring and analysis, we defined an architecture that allows us to download software packages source code and run different static analyzers on them, saving the results using the Firehose project. Figure 1 shows this architecture:

Drawing ..

Figure 1: Kiskadee architecture.

The ideia is to have the monitoring part of kiskadee decoupled from the analysis part, and to allow easy integration of new static analyzers. For a more complete view of why we have built kiskadee this way, check our documentation. kiskadee was developed from the ground, and the architecture presented on Figure 1 was designed with my GSoC mentor. To check all the work I put on kiskadee during GSoC, you can download this file, with all my commits (these commits not includes the user interface work, that is being hosted on another repository).

kiskadee is still in a development stage, and is an experimental project. Our long term objective, is to have kiskadee running on Fedora infrastructure, as proposed by the Static Analysis SIG. You can help us on the development of kiskadee, opening issues, fixing bugs or with new features. On this link you can find our repository, and here the documentation. The steps to run kiskadee can be found in our README.

On the last release of kiskadee we had developed an API, that exposes some endpoints that returns several informations about our static analysis. These endpoints are:

    - An endpoint to list all analyzed packages.
    - An endpoint to return the analysis of a specific package.
    - An endpoint to list the fetchers available for monitoring.

With the API we also developed an experimental user interface to consume it. This user interface is not in production, and it will probably have significant changes in the next months. Image 2 shows a list of packages analyzed by kiskadee:

Drawing ..

Figure Two: Kiskadee UI.

You can check the development of the user interface on this repository.


I would like to thank the entire Fedora community, by had accepted my proposal on GSoC. I also want to thank my mentor, Athos Ribeiro, for the support through this months. His help on the creative process of kiskadee development, and the freedom that he gave me to take technical decisions, made me a better programmer. I received a lot from Fedora, and now it's time to give back to the community my work and dedication.