1 Executive Summary

The objective of this deliverable is to describe the tooling developed during the CHARIOT project concerning the
static analyses of firmware for IoT. Two toolboxes, BISMON-Source-Verifier and BISMON-Security-Checker, have
been developed in CHARIOT with two complementary objectives in mind. This deliverable mainly focuses on
BISMON-Source-Verifier, also named BISMON, because BISMON-Security-Checker is still in development with a
design elaborated in 2020 following the rescoping decision. An early description is present in section 5.4. The full
description of BISMON-Security-Checker will be presented in deliverable D1.7.
The BISMON description has evolved continuously since the beginning of the project and it continues to evolve
since it is part of the continuous development process of the BISMON tool2.

This document describes the BISMON vision on static source code (mostly of C and C++ code for IoT firmware
and application) analysis. It proposes a simple static analysis framework leveraging on the powerful recent GCC
[cross-]compiler. A persistent monitor (tentatively named bismon) has been designed and implemented as a
GPLv3+ free software for Linux. BISMON uses meta-programming techniques to generate GCC plugins. It keeps
some intermediate results (of compilation or static analysis) during the entire life of the IoT project, and gives to
the IoT developers (through a web interface) a whole-program view of the source code along with its static
analysis properties. That framework is configurable and scriptable by static analysis experts, hence permitting
different IoT projects to address various concerns, while keeping the usual IoT development workflow (running
as usual their GCC cross-compiler on Linux, with extra plugin-related compilation flags). The deliverable has been
structured starting from the identification of the software and tool users and the document expected audience
as well as the vision on specialized source code analysis towards more secure and safer IoT software
development. The report then describes its strong alignment to adding capabilities to GCC as well as the driving
principles of the tools. Data and their persistence character are also described including mutable and nonmutable values/types while persistence is considered to start by loading some previous persisted state, usually
dumping its current state before termination and loading the next state on the next load-up. The framework for
static code analysis is also defined as part of the GCC compilation process. The described work is also analyzed
in terms of contributing to other free software projects.

Static analysis aims to detect bugs that have impact on the quality, the safety and the security of the firmware.
Nevertheless, it is often late in the development process – during the test phases in a continuous integration
environment. The persistent monitor enables to add earlier interactions with the Static Analyses, in particular
during the various compilation steps that occur before the tests in continuous integration. The developer should
then be more efficient for correcting his own bugs when he writes his code. The persistent monitor also has an
historical context of the code, which enables to provide more pertinent analysis messages.