---
title: "JavaScript Static Analysis Tools for Medical Devices"
type: white-paper
publisher: Ketryx
source: "https://www.ketryx.com/assets/javascript-static-analysis-tools-for-medical-devices"
content: text extracted from PDF (layout/tables/figures not preserved)
---

# JavaScript Static Analysis Tools for Medical Devices

*Source: [https://www.ketryx.com/assets/javascript-static-analysis-tools-for-medical-devices](https://www.ketryx.com/assets/javascript-static-analysis-tools-for-medical-devices)*

---

S

The Internet provides a platform for communicating through all manner of devices and systems.This interconnectedness is known as the Internet of Things (IoT). In this IoT ecosystem, eachcomponent has different performance expectations that depend on the context of use. Forregulated software and devices, such expectations include notions of safety, security,dependability, trust, or any combination of these properties. The focus of this paper is on software applications (Apps) written in Javascript that meet the Foodand Drug Administration’s (FDA) regulatory definition of amedical device. [link to 21cfr] Becausemedical devices are used to treat, diagnose, deliver therapy, etc. their use may result in patientharm, ranging from minor injuries to death. Therefore, freedom from unacceptable risk(safety)[link to ISO 14971] is an imperative, and security is a subset of safety. FDA compliance and software Medical devices marketed in the United States are regulated by the FDA. Under FDA regulationsthe development and distribution of medical devices must be carried out under a quality systemprocess. The portion of this quality system process for the development of medical devicesoftware is described in the ANSI/AAMI/ISO/IEC 62304 standard. In addition, the FDA providesguidance documents that describe the type of artifacts generated in the standard’s process to besubmitted for pre-market regulatory review. The many steps and tests necessary for the creation of safe medical devices include the FDA’sexpectation that device manufacturers use industry’s best practices when developing a medicaldevice. In the software industry, this requirement means using specialized tools, verification, andvalidation to ensure that developers address common issues within software code, as well asanticipating unknown risks. For example, thirty years ago best practices included reviewing codewith respect to the requirements, performing static code analysis, and conducting codewalkthroughs. While some practices have changed over time, many of these best practices arestill in place. Today, best practices include code change review (aka Pull Request review on GitHub/Bitbucketor a Merge Request Review on GitLab) and running “static” analysis tools against the code toreduce the likelihood of coding and runtime error. Using such tools strengthens the argument tothe FDA that the device software is more likely to perform as intended than not. JavaScript and safety Software written in JavaScript seeking to comply with the FDA’s medical device regulations face acomplex verification and validation process to ensure user safety, which includes activities suchas specification documentation and potential defects studies. JavaScript’s semantics and syntaxhave changed little over time, and, like all coding languages, it can still contain flaws that cancause an App to behave incorrectly. In the simplest case, for example, one can create a variableassignment that is treated as global in the system, whose value can change unpredictably under

unanticipated conditions. In the worst case with medical devices, these unknown responsescause the variable to be assigned a value that can lead to user/patient harm [xx]. Many software tools are available to check for coding errors. Tools that perform correctnesschecks on source code before a program runs are called static analysis tools. For some softwarelanguages such as C, C++, C#, Ada, etc., these checks can be in-depth and rigorous. Lint tools,or lightweight static analysis tools, can also check for basic coding errors in JavaScript. Eventhough lint tools are efficient in identifying obvious mistakes on the syntactic level, they are notcapable of doing deeper analysis on the intention of the code, especially across multiple files,third-party packages, or other APIs. This is due to the lack of static type information inJavaScript. In the context of JavaScript, there are multiple layers of tools that may increase the quality of thesource code: On the first layer, there are code linters and pretty-printers (e.g. ESLint, Prettier) that allowenforcement for specific syntax related rulesets, formatting of the code, and even lightweightcontrol flow analysis on isolated parts of the program. On the second layer, there are type systems that may be applied on JavaScript code, such asTypeScript, that will allow proper static code analysis and type-checking to prevent advanced

logical bugs that may be overlooked by code reviews. These types of languages are commonlyknown as "gradually typed" languages, since they may be partly introduced into existingJavaScript codebases, leaving some parts of the program unchecked. Beyond the first two layers, there's also the possibility to use even stricter statically typedlanguages that compile to JavaScript, which enforce stronger type guarantees during runtime(Elm, ReScript, Js-of-OCaml, F#/Fable, PureScript, Rust / WASM, etc.). In contrast to graduallytyped JavaScript, these languages don't allow partly typed code and therefore deliver morereliable results on static code analysis reports. Common JavaScript concerns for medical device software Use of static tools mechanically checking for common coding errors can lead to concerns withsafety, performance, and security. Awareness of potential issues early in medical device softwaredevelopment can prevent problems down the road when attempting to meet the FDA’s guidelinesfor medical device software. There are many problems that the FDA will hold software developersaccountable for when creating a safe medical device and other regulated products. The list belowis not a comprehensive summary of every issue JavaScript can encounter but rather a generalguide using examples to illustrate the kind of errors to look out for. ● Errors caused by null / undefined values● Errors caused by implicit type coercion of runtime values into strings, either causinghard-to-spot logic comparison issues or wrong math arithmetics (string + number = string+ stringified number)● Errors caused by incompatible JavaScript engines. Depending on the runtime environment(V8, JavaScriptCore, SpiderMonkey, Chakra, etc) there may or may not be certain APIsavailable (see ECMAScript engine comparison table)● Errors caused by low-level differences in the executing JavaScript engines. Even thoughmainstream JavaScript engines try to stay fully compliant to the ECMAScript standard,there may be scenarios where certain functions use different strategies for theimplementation (e.g. different sorting algorithms or data structures). This may causesituations where the same piece of code will use more memory or perform worse in aparticular runtime environment.● Logic errors caused by JavaScript’s notion of “truthy” or “falsy” values (see JS comparisontable)● Errors caused by floating point arithmetic. JavaScript’s number type is represented as a 64bit floating point value that may cause hard to spot arithmetic errors, such as 0.1 + 0.2 =0.30000000000000004.● Errors caused by syntactical errors. Whenever the JS runtime evaluates invalid JavaScriptcode, it will raise an error that will often result in a crash of the program.● Insufficient error handling during asynchronous code execution. Every I/O process callsinto an asynchronous mechanism that may fail and crash the program due to lack of globalerror handling.

● Errors caused by unintentional mutation. In JavaScript, object instances are mutable andcan be modified by any part of the program that gains access to the object reference.Depending on the coding practice, this may cause critical side effects that will affect theend result in unpredictable ways. Addressing software safety concerns With so many potential errors, where do you start when trying to make JavaScript as safe aspossible? Below is a brief list of recommended preventative actions to address concerns withsafety and FDA compliance. This list is not comprehensive and does not include every actionavailable to developers. First steps for making your JavaScript applications as safe as possible: ● Get a clear picture of your third party npm dependencies. The JavaScript ecosystem offersa broad variety of third party packages that may be installed via the npm or yarn packagemanager. Getting an overview of all the installed code is essential, especially for packagesthat install sub-dependencies. Reducing the number of third party dependencies may helpreduce the risk of critical bugs. In certain situations, “vendoring” and simplifying dependentcode may be a very good option to take ownership of critical code paths. Luckily, there aremanagement tools that can help. The Ketryx Platform’s OSS CM allows users to review acontinuously updated software bill of materials (SBOM) and identify risks found independencies used. ● Migrate your JavaScript code to TypeScript to add static type information to yourcodebase. Ideally the tsconfig.json file should have the config “strict: true” enabled toenforce the strictest recommended type checking mechanisms. Doing so will most likely

result in many type checking errors, so you may need to slowly tune up strictness by usingthe individual strictness flags instead (noImplicitAny, strictNullChecks, noImplicitThis, etc).TypeScript may be adopted gradually, so migrations can be done gracefully as new code isbeing written or old code refactored. Tighten the screws on the type checking strictness asyou go.● Depending on the number of dependencies used, you may also need to verify relatedTypeScript type files and make sure the types correspond to the right strictness settings aswell.● Use ESLint for code linting. For a basic setup, enable “eslint:recommended” as a baselineconfiguration and optionally enable rules as you see fit for your organization. You also needto configure `eslint` to use a TypeScript parser to understand your TypeScript code.● Hook up Continuous Integration scripts that enforce full type checks / code linting for thewhole codebase via the `tsc` and `eslint` command. To simplify this long and complicatedprocess, the Ketryx Platform uses enforced checks and linting built directly into theframework. To sign up for a demo, visit https://www.ketryx.com/contact-us. The steps above are quite high level, and the details will be the hardest parts to solve. ManyJavaScript applications will not mix well with a static type system (such as TypeScript), sodevelopers need to make the right trade-offs to add type information to their codebases. Apartfrom adding unit, integration, and end-to-end tests, adding type information to JavaScript code isthe best way to empower humans and machines to analyze code more efficiently and in astandardized way. The Ketryx Platform helps developers take the least burdensome approach tothis task with a full application lifecycle management system that continuously monitors code andenforces FDA compliance. If you would like to learn more, reach out to the Ketryx team here. Conclusion The regulated medical device industry demands the best practices and techniques to ensure safesoftware that is free from unacceptable risk. The FDA will expect developers using JavaScript toemploy static analysis tools to create reliable software for medical devices. However, these toolsalone will not meet FDA medical device guidelines. Implementing static analysis tools is a goodstart to instilling confidence in a software’s code, but developers must also adjust their JavaScriptpractices. Learning new techniques to anticipate or prevent risks in JavaScript and incorporatingnew coding methods is another step to improve a software’s reliability and demonstrates a use ofthe industry’s best practices. Beyond these JavaScript practices, FDA regulations also require extensive documentation,verification, validation, review committees, and other quality management steps. A developerteam’s approach to JavaScript plays a critical role in creating an FDA-approved medical device,but software developers must address the larger series of regulations and practices necessary tothe software development process as well. This process is complex and difficult to follow.However, the Ketryx Platform incorporates FDA requirements into its workflow to ease the burdenon developers, so they can focus on what they do best: building and developing softwareapplications safely.