Embedding robustness and security in your product


You read about it in the news: systems have been hacked and confidential information has gotten into the wrong hands. With the growing complexity and ubiquity of our various information systems in today’s world, the challenge for software developers to guarantee that confidential information remains confidential, has become bigger and more important at the same time.

by AimValley

AimValley has extensive experience in developing software for “carrier-class” telecommunication equipment, where built-in robustness, very fast fault recovery and redundancy are key requirements. To get to this “carrier-class” quality level, we use a selection of tools, such as: code analysis, minimizing manual coding of tedious functions, to help build in robustness and security in your products.

Code analysis

The first step is to screen your code for vulnerabilities such as resource leaks, dereference of NULL pointers, uninitialized data, control flow issues as early as possibly in the development stage. AimValley uses Coverity to scan your C, C++, and Python codes. Coverity runs by a developer or automated via scripts. As a second step we use Valgrind to debug and dynamically profile the application.

Minimizing manual coding of tedious functions

Using a domain specific language with a compiler to generate the application code, a framework, unit test code or documentation, allows developers to focus on those tests that are too complex to automate. Reusing common mature building blocks delivers stability and quality to a product. Manual unit or integration tests will still be required, but this approach helps bring down the development time and reduce the amount of bugs.

Open Source Software

In developing embedded software, it is very common to include free and open-source software modules in your products. These software packages however, all release their own patches and security fixes that you will need to stay up-to-date with. To ease that task AimValley uses Black Duck.

Open-source projects often include more code than is used for a project. A Yocto distribution, for instance, includes support for different hardware boards and modules that are not always used for your product. For an accurate assessment you will need to run the scanner against the used components only. You could do that by manually deselecting components from the scanner’s GUI or via directives in the source tree or via command line options. But how can you be sure that you did not exclude modules that you obscurely use? Functions called from inside a used library can easily be overlooked. While excluding from the GUI is easy, the number of manual annotations can be an issue. For example one of our recent scans of a Yocto environment came up with 750 vulnerabilities, making annotation somewhat cumbersome.


An abstract 3D render of a microprocessor on a circuit board with many electrical components installed. The central microprocessor has an integrated security lock in glowing yellow color. Components are labelled with random serial numbers, with many connections glowing in yellow color too.


During the testing phase we use vulnerability scanners, such as Nessus, OpenVAS and Kali Linux to make sure that the product has no externally exposed vulnerabilities. As a result of the scans, ports that have been left open unintentionally will be detected and additional vulnerabilities in the code will become visible.


All tooling aside, the most effective security counter measures start at the beginning, during the system architecture phase. Similar to the effect of spent effort on bugs detected early, not designing security risks into the system makes a huge difference. There are tools, methods and standards available that can help in this regard. But in general it is preferable to sit down with the development team and define use-cases and record security requirements that can be verified and tested.

All tooling aside, the most effective security counter measures start at the beginning, during the system architecture phase.

We have illustrated how the use of tools can help embed robustness and security in your product design in various stages of the development. This approach will only work if the development team is aware of and focused on the importance of security during architecture, design, reviews, implementation and testing.
A dedicated security officer’s role within the company can help to get guidelines, templates and procedures organized.