Understanding Coding Standards In Medtech Development
By Steve Howard, Perforce Software, and James Thomas, Creo Medical
While the adoption of coding standards in medical device development may lag behind other industries focused on functional safety, their use is progressively increasing — largely driven by the growing complexity and connectedness of devices, as well as more stringent regulation relevant to risk mitigation.
The idea behind coding standards is very simple: they are sets of ‘rules’ that give software developers guidelines relevant to writing code. Irrespective of any safety or security considerations, coding standards help ensure code is written with consistency and uniformity, and is easily readable by everyone in a development team. This helps reduce bugs and security vulnerabilities while creating unvarying quality of code.
This article explores why coding standards’ use in medtech is growing and offers guidance in how to apply these standards.
Compliance
Writing such congruent code (sometimes called “clean code”) clearly is beneficial to quality, but regulatory compliance is among the biggest drivers (regardless of industry) to adopt coding standards. However —unlike some functional-safety focused markets — for medtech, neither the U.S. Food & Drug Administration (FDA), the existing European Medical Device Directives (MDD), nor IEC 62304, ISO 13485, and IEC 61508 (guidance only, referenced by ISO 62304), lay out specific coding standards or requirements for medical devices.
That said, organizations are required to carry out steps necessary to ensure device safety and security as part of compliance to these pieces of regulation. For instance, the MDD states, “For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.”
However, early in 2020, the European Commission Medical Device Coordination Group (MDCG) published its Guidance on Cybersecurity for Medical Devices, covering both medical devices and in-vitro medical devices. In this text, the MDCG extended MDD guidance to specifically include “information security” in its list of software validation requirements, as well as endorsed and referenced the International Medical Device Regulators Forum (IMDRF) paper on Principles and Practices for Medical Device Cybersecurity, published in October 2019.
The IMDRF guidance encourages the use of static analysis — Static Analysis Security Testing (SAST) — under subhead “5.3 Security Testing” withing its Pre-Market Considerations for Medical Device Manufacturers section: "Perform target searches on software components/modules for known vulnerabilities or software weakness. For example, security testing can include: static code analysis, dynamic analysis, robustness testing, vulnerability scanning, software composition analysis."
The text is not specific regarding how one should go about this using static analysis tools, although it references both the National Institute of Standards and Technology (NIST) and Open Web Application Security Project (OWASP) — who champion the CWE and OWASP coding standards, respectively — as “good sources of security requirements and security risk control measures.”
So, while the medical device industry does not seem to be following the route of industries that directly mandate coding standards (such as automotive), a growing emphasis on software security and safety is clear, with guidelines on how that can be achieved trickling out.
While more medical device organizations are beginning to embrace the practical benefits of applying coding standards to their development projects, others have yet to catch up: over 70 percent of respondents to Perforce’s 2019 State of Medical Device Development survey reported they were not using coding standards or they were not aware whether coding standards were being applied.
Another explanation for medical device industry’s slow uptake of coding standards — compared to, say, the rail, nuclear, and automotive industries — is its (typically) much-smaller development teams. However, as codebases become larger, more complex, and more connected, coding standards become more relevant to smaller teams: if a programmer leaves an organization, others need to be able to read his/her code, and a coding standard makes it much more accessible.
How Coding Standards Work
As projects scale, adding greater volumes of complex code, keeping control over quality and consistency while maintaining compliance becomes essential. The challenge is that C and C++ — the two main programming languages in embedded software today — despite giving developers flexibility to innovate and keep system resource costs as low as possible, add further complexity and potential for confusion.
Consequently, C and C++ also require more interpretation and introduce room for error, potentially leading to security flaws. For instance, C and C++ dynamic memory allocation is notoriously complex and easy to get wrong, occasionally leading even the most experienced developer to inadvertently introduce memory leaks (when memory is allocated, but not cleaned up when no longer required).
According to Common Weakness Enumeration (CWE) referenced by NIST: “Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.”
Another risk of poorly policed coding is the use of uncontrolled format strings, which can be exploited to crash the program, view memory content, or write to an arbitrary memory location. A coding standard can include a rule that addresses this vulnerability (e.g., “exclude user input from format strings”).
Other examples of risk reduced or eliminated through the introduction of coding standards are scenarios in which no checks are in place to ensure that an input buffer cannot overflow, allowing someone to design an input containing malicious code.
The Main Coding Standards
Organizations can and do create their own coding standards — for instance, to ensure consistency of naming conventions and code layout. However, in safety-critical markets, it is more typical to apply recognized published standards — such as MISRA C/C++, a set of software guidelines developed by the Motor Industry Software Reliability Association (MISRA), which aims to facilitate code safety, security, portability and reliability in embedded systems.
While MISRA C/C++ was developed for the automotive industry, it has been widely adopted in many other industries. Interestingly, there exists precedent: the Toyota Production System-inspired “LEAN” manufacturing, considered a standard approach in medtech today. Further, in the future, MISRA C++ will incorporate the AUTOSAR C++ coding guidelines (also designed for the automotive industry, with a stronger emphasis on connected and autonomous systems).
Another coding standard gaining traction within the embedded software space is CERT, developed by the CERT division of the Software Institute at Carnegie Mellon University (CMU). The CERT standard focuses on application security for a broad set of systems, and not just those found in the banking and finance sectors.
Finally, there is the aforementioned CWE, a community-developed list of common software and hardware weakness types that have security ramifications. “Weaknesses” are flaws, faults, bugs, vulnerabilities, or other errors in software or hardware implementation, code, design, or architecture that — if left unaddressed — could result in systems, networks, or hardware being vulnerable to attack. The CWE list and associated classification taxonomy serve as a language that can be used to identify and describe these weaknesses in terms of CWEs.
The need to demonstrate comprehensive compliance and security measures leads many organizations are adopting more than one coding standard, sometimes augmented by in-house coding standards to cover naming conventions and layout guidelines.
Different applications may be written in different programming languages, each requiring adherence to an appropriate, language-specific coding standard. Also, some coding standards are specifically designed for resource-limited embedded systems (e.g., MISRA and prohibition of dynamic memory allocation), while some are designed more for general-purpose platforms, such as PCs.
Applying Coding Standards to Medtech
While the theory behind coding standards is sound, there are some important considerations when introducing them into an organization, with team culture being at the forefront. We recommend, before applying coding standards, that organizations work with developers in the selection process and planning; imposing coding standards and tools on developers without their input rarely is successful.
It is important to reach a consensus on a coding style, particularly around naming conventions and layout, which is where most personal coding styles will vary. Not everyone will agree, but it is the only way to ensure consistency, improve code quality and, ultimately, contribute to product safety and security.
It also is recommended that organizations carry out code reviews, or automated code reviews through static code analysis, to ensure conformance with coding standards, though that verification activity should be happening anyway. Tools like static code analysers can be utilized to constantly inspect code in background mode and to deliver thousands of diagnostics at the point of development. Any issues that might be otherwise difficult to detect — deviation from a coding standard, excess complexity leading to a dataflow bug —are detected early, rather than at a later stage.
Ultimately, the implementation of coding standards into your medtech operation is a matter of choice, versus the stipulation of an unavoidable regulatory requirement. However, coding standards are among then the many tools whose value is often underestimated by medical device organizations seeking faster time-to-market, fewer postmarket issues, and a higher quality, more efficient development process. organizations achieving those goals.
About the Authors
Steve Howard is Static Code Analysis and Technical Services Lead at Perforce Software. Steve has more than 15 years of experience in the software verification and validation space, and the majority of that working with static analysis. Steve is well-versed in the challenges, capabilities, and benefits that static source code analysis can bring to software development projects. Steve works at the forefront of static analysis technology, practice and innovation. Steve holds a 1st class degree in Computer Science from the University of Wales, plus industry qualifications in testing [ISTQB and functional safety standards (IEC615508/IEC 60880)].
James Thomas is Software Development Director at Creo Medical, a medical device company focused on the emerging field of surgical endoscopy. He has a background in leading and managing organisations, departments, and teams developing and delivering mission- and safety critical solutions. He has worked in the software industry at all levels, from developer up to director, undertaking a variety of operational roles covering software development and delivery, technical consulting, innovation, quality assurance, team building, staff development, recruitment, and training.