The goal of this publication is to help you in the setup of your medical software development environment. The earlier you start with good practices application the more value and time you will gain from it.
Targeted audience
The information gathered in this publication should be particularly useful for:
- Head of Software Development Team,
- Software Project Managers,
- DevOps team,
- Software developers.
Introduction
For introduction content, refer to the Part 1 previously published.
Good practices
Refer to the Part 1, 2 and Part 3 previously published.
Management of external libraries
“Never reinvent the wheel and use available libraries” is a great advice for fast innovation. Nevertheless, take only the wheel you need and not the entire car! You can quickly get polluted with useless libraries. Build and compilation time quickly increases with the number of libraries and the time you spend in cybersecurity management is exponentially impacted by the number of libraries.
Debiotech recommends you to:
- Identify your needs and the available solution and check the associated licenses and the known vulnerabilities before integrating a specific library.
- Keep track in a Software Bill Of Materials (manual or ideally automatic) of the libraries you use, their version, their description and the reasons why you use them.
- Every request for a new library to be integrated by a developer should be reviewed and challenged before being approved.
Figure 1. Example of an automatically generated Software Bill Of Materials
SBOM and CVE generation
Quickly your software project will have a level of complexity that won’t allow you to manually follow the libraries you use, their version, the associated license, and other metadata. Reliable automatic code analysis tools exist and can automatically do this work for you and bring you important additional features as Critical Vulnerabilities identification. Those tools allow you to generate the Software Bill Of Materials (SBOM) as well as the list of applicable Common Vulnerabilities Enumeration (CVE).
For proper Cybersecurity management those tools and documents are a must have and shall be used early in the development process, on a regular basis AND during the entire lifetime of the product (even long after release to market). Those tools will allow you to develop your Cybersecurity BOM, requested by the FDA in its latest cybersecurity guidance. You can also perform this search for vulnerabilities manually using CVE or NVD database for example.
Major build systems (e.g., Buildroot, Yocto) are able to generate SBOMs which must preferably be in standard format like CycloneDX or SPDX. Alternatively, tools that will automatically scan the projects dependencies can be used (e.g., using makefiles for C/C++ projects or pip requirements for python).
Some of the well-known tools are WhiteSource or Black Duck.
Figure 2. Sample output of Black Duck SCA tool
Debiotech recommends you to:
- Quickly integrate SBOM automatic generation tool in your software development environment to follow use libraries, their version, their license, and other metadata.
- Quickly integrate CVE automatic identification tool into your software development environment to start rising awareness on cybersecurity management within your team.
- Once your software development environment is fully setup, start investigating more in details:
- Requirements for proper medical software development management
- Requirements for Cybersecurity for your connected devices.
Debiotech will regularly publish expert opinions on those topics.
Static Application Security Testing Tools
Introduction
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”).
SAST tools are available for any programming language. They analyze the source code (and/or compiled code) without running it on the device to detect the most common errors and security flaws.
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 comes 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 your 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).
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 3. 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?
Debiotech recommendations
Debiotech recommends you to:
- Identify the SAST tool that fits the best to your needs,
- Use a SAST tool as early as possible within your development process,
- Integrate the SAST tool within your continuous integration server,
- Integrate the SAST tool within your IDE to provide direct feedbacks to your developers,
- Customize SAST tool reporting to your needs.
Applicable regulatory landscape
This publication does not aim at answering completely to a specific standard or regulation but provide recommendations on multiple aspects that should be established early on in your development to ensure the efficiency of your team. However, it covers directly or indirectly multiple requirements from following standards and regulations:
- Europe: MDR
- US: CFR Title 21 Part 820,
- International: ISO 13485, IEC 62304, UL-2900-1/2
Authors
 |
Rémi Charrier Business Development Director r.charrier@debiotech.com |
||
|
João Budzinski |
 |
||
 |
Laurent Colloud Software Project Manager l.colloud@debiotech.com |
||
|
Gilles Forconi |
 |
Next steps
Debiotech is glad to have the opportunity to share its knowledge with innovative companies from the MedTech industry. Your feedbacks on this publication are welcome and will be used to update it or to create new publications on topics you care about.
Continue your education on medical device development by:
- Accessing Debiotech historic publications: https://www.debiotech.com/news-grid/
- Following Debiotech on LinkedIn to be notified on new publications: https://www.linkedin.com/company/debiotech-sa
- Contacting us to ask a question or request personalized support: contact@debiotech.com
Debiotech would be proud to be your partner and support you with:
- Medical device design & development services:
- Software: Digital Health, Firmware, Embedded, SaMD
- Electronics: Design, Verification and Validation
- Mechanics: Design for micro-fabrication & fluidics systems
- Supply chain development and optimization
- Support in medical innovation management:
- Market analysis and segmentation
- IP management
- Business plan consolidation
- Partnership development
