CyberMed
← All articles

How to Perform security code review

Published Updated Andres EcheverryEditorial policy

How to perform a security code review for medical device software: inputs, tools plus manual review, what to look for in device code, and FDA evidence.

Here's the truth:

Automated tools can catch plenty of vulnerabilities in a security code review. But they can't catch everything.

That's because you still need a human professional who understands the code, knows how the device works, and has the ability to spot security weaknesses tools might very well miss.

Understand that the actual process starts with your security requirements and threat model. Static code analysis and software composition analysis are next up. These are used to identify potential vulnerabilities as well.

There's also a lot of manual examination to find potential code problems like hardcoded credentials, or weak authentication and authorization, and improper use of encryption. Another big code issue discovered through manual means: unsafe handling of data coming through external interfaces.

But keep in mind it's not enough to just callout a code irregularity. Every finding needs to be documented, or corrected, or have its security impact evaluated.

Expect to expand your records even further by showing what you reviewed, what you found, and how you addressed it.

Some would say this is just good security practice. But there's more to it. FDA's February 2026 premarket cybersecurity guidance recommends static and dynamic code analysis, while IEC 62304 calls for software unit verification against defined acceptance criteria.

This guide is meant to help teams on both fronts with the security code review process. You'll learn about the security part as well as meet FDA guidance recommendations.

Why code review matters for an FDA submission

When you're preparing a medical device for FDA submission, you need more than a report saying your software passed a security scan. You need evidence that you've looked for vulnerabilities, tested your security controls, and addressed the problems you found.

Hardcoded credentials are one concern the FDA specifically calls out. Passwords, encryption keys, and other sensitive information embedded directly in your code can create security risks, which is why checking for them should be part of your review.

The FDA's February 3, 2026, premarket cybersecurity guidance makes this clear. Section V.C recommends that manufacturers document several types of vulnerability testing, including:

  • "Static and dynamic code analysis, including testing for credentials that are 'hardcoded,' default, easily guessed, and easily compromised"
  • "Software composition analysis of binary executable files"

Section V.B.1 also asks manufacturers to document that their security controls have been implemented and tested to confirm they work as intended. That's where static code analysis for medical device software becomes especially valuable. It helps identify potential vulnerabilities, while a manual code review lets reviewers take a closer look at whether controls such as authentication, encryption, and code integrity have been implemented correctly.

IEC 62304 unit verification is another important part of the process. Clause 5.5 covers software unit implementation and verification, while Clause 5.5.3 requires defined acceptance criteria before integration for Class B and C software. Clause 5.5.4 adds requirements for Class C software, including fault handling, initialization, memory management, overflows, and boundary conditions.

These checks help your team catch software defects early, before they become harder and more expensive to fix.

Although IEC 62304 doesn't specifically address cybersecurity, these checks can help uncover weaknesses involving memory safety and input handling. IEC 81001-5-1:2021 builds on that lifecycle by introducing security activities. The FDA also identifies it as a framework manufacturers can use when developing security design inputs.

Following secure coding practices for medical device software is an important first step, but you also need to verify that developers are following those practices. Our book chapter on secure coding practices explains how to write more secure software. Here, we'll focus on reviewing that code, identifying potential vulnerabilities, and documenting the results.

Step 1: Set the inputs

Before anyone starts reviewing code, make sure they have the information needed to do the job properly. Otherwise, they're relying on their own experience to decide what looks suspicious, and important vulnerabilities can slip through.

A good security code review starts with five things:

  • Security requirements. Give reviewers the security controls defined in your design inputs, along with their acceptance criteria. Section V.B.1 of the FDA guidance addresses these expectations. For each requirement, the reviewer needs to determine where the control is implemented and whether the code actually does what it's supposed to do.
  • The threat model and architecture views. These show where your software accepts outside input, stores sensitive information, and enforces trust boundaries. They also help reviewers identify which parts of the code deserve the closest attention.
  • The coding standard. If you're developing firmware in C or C++, you're probably familiar with SEI CERT C or MISRA C. Reviewers should check your code against the standard identified in your software development plan, rather than applying their own preferences.
  • The software bill of materials (SBOM). Your SBOM identifies the third-party software components included in the build. This helps reviewers distinguish between code your team developed and components that need to be evaluated through software composition analysis.
  • The Common Weakness Enumeration (CWE) list. Section V.A.5 of the FDA guidance asks manufacturers to consider applicable CWE categories when evaluating software anomalies. The CWE Top 25 provides a useful starting point for identifying common weaknesses in medical device software.

One more thing: document exactly what you're reviewing. That means identifying the repositories, commit, and build configuration.

This matters because reviewing a development build with debugging features enabled isn't the same as reviewing the software you're preparing to release. You want your findings and verification records tied to the correct version of the code.

Need help with security code review or your software and cybersecurity documentation? Email us at info@cybermed.ai.

Sources

Frequently asked questions

›Does FDA expect security code review for medical device software?

FDA's premarket cybersecurity guidance (February 2026) lists static and dynamic code analysis, including testing for hardcoded, default, easily guessed, and easily compromised credentials, among the vulnerability testing it recommends documenting in a submission. It also asks for evidence that each security control was implemented and tested. Code review is how most teams produce that evidence.

›What is the difference between static analysis and security code review?

Static analysis is a tool pass that flags known patterns, such as buffer overflows or dangerous functions. Security code review is a human activity that uses tool output as one input and adds judgment about logic, authorization, cryptography use, and whether the code matches the threat model. You need both.

›What should a security code review look for in device firmware?

Hardcoded credentials and keys, memory safety in every parser that handles external input, correct use of cryptographic libraries and random number generation, authorization checks on every privileged operation, debug code and backdoors left in release builds, update and boot integrity checks, and fail-safe error handling that preserves essential performance.

›How do code review findings get into the FDA submission?

Findings that are fixed become part of your verification records. Findings that remain are software anomalies with potential security impact. Section V.A.5 of the February 2026 guidance asks you to assess those for security impact, consider the applicable CWE categories, and provide the criteria and rationales for how you addressed them.

›Can we review third-party and open source code the same way?

Rarely in full. For components you cannot read, rely on software composition analysis of the binary, your SBOM, known-vulnerability checks including CISA's Known Exploited Vulnerabilities Catalog, and the supplier's own security evidence. Review your integration code and the boundary where the component touches external input.