After having covered Threat Modeling and CVE analysis in previous articles, our third part focus on another well-known method in cybersecurity which is used to ensure code quality, Static Code Analysis.
Many Lines of Code = Many Potential Bugs
Typical medical device projects are often a mix of one or many printed circuit boards (PCBs) with hardware components interacting with each other, external digital interfaces, user interfaces and critical algorithms. Tying all these elements together requires large software projects, with thousands of lines of code. The major drawback is that the higher the number of lines of code (LOC), the higher the number of bugs introduced in the software, especially at early stage of development (i.e., before testing).
Static Application Security Testing Tools
A very good practice to automatically detect bugs during development, also recommended by UL 2900-1 18.1, is to regularly scan the code using a Static Code Analysis tool (SCA, although SAST which stands for “Static Application Security Testing” should be preferred to avoid confusion with “Software Composition Analysis”, see part. 2).
SAST tools are available for any programming language. They analyze the source code (and/or compiled code) without running it on the device in order to detect the most common errors and security flaws.
Like Software Composition Analysis tools, a lot of different SAST tools are available on the market, whether they are open source like Clazy or cppcheck, or commercial like Fortify or CodeSonar. Each of them come with pros and cons and must be selected based on the project needs and integrated in the software development workflow as early as possible. To help in this process, a list of SAST tools is maintained by the OWASP (click here to see the list).
How to Select The SAST Tool?
First thing to consider is selecting a tool compatible with the used programming language and ideally the used libraries and frameworks (this may avoid a lot of false positive).
Figure 1: Clazy analyzer allows clang to understand Qt semantic
The tool must be able to detect a lot of error types, depending on the underlying technology, like SQL injection if a database is used, hardcoded passwords for a server application, or the well-known buffer overflows or null pointer dereference in unmanaged languages like C and C++.
Being compliant with the common bug classification types, like OWASP Top 10 or CWE Top 25 and coding guidelines like MISRA C is a real plus. Some tools like Perforce Klocwork or Parasoft C/C++test also come with standard compliance certification for IEC 62304, which will exempt you from validating the tool and automatically generate the required documentation.
Figure 2: Fortify SAST is compatible with CWE classification
The next step is to ensure that the tool integrates smoothly with your development workflow. Some questions that should be asked at this stage:
- Is it possible to run it automatically from the continuous integration server?
- Can it be integrated in the IDE to provide easy to understand feedback to the developers?
- Can generated reports be customized?
Figure 3: cppcheck warnings are integrated in QtCreator IDE
Figure 4: Fortify SAST allows to customize reports
Code Scanning and Auditing
After selecting the right tool, what remains is to scan the code. If there is already a large codebase, there is a high probability that the scan will end up with a lot of issues including a lot of false positives. ALL issues must be audited, either marking them as “non applicable” if they are false positives or fixing the code to make them disappear in the next scan.
Figure 5: CodeSonar audit field
Auditing all the findings can be time consuming at first glance, but the effort is worth it as it helps finding bugs early in the development process, making the code more robust and saving a lot of time and money that would be spent later in support and debugging.
Last but not least, this scanning should be performed frequently (ideally automatically after each commit) as it will guarantee to maintain the code quality and robustness as the development progresses.
Preview of Part 4
In the fourth and last part of the articles dedicated to cybersecurity in medical devices, we will share with you several concepts based on our experience that will allow you to develop a safe and reliable software.
