---
title: "FDA Cyber Guidance and the Software Supply Chain - A Playbook for Shifting Left"
type: white-paper
publisher: Ketryx
source: "https://www.ketryx.com/assets/fda-cyber-guidance-and-the-software-supply-chain-a-playbook-for-shifting-left"
content: text extracted from PDF (layout/tables/figures not preserved)
---

# FDA Cyber Guidance and the Software Supply Chain - A Playbook for Shifting Left

*Source: [https://www.ketryx.com/assets/fda-cyber-guidance-and-the-software-supply-chain-a-playbook-for-shifting-left](https://www.ketryx.com/assets/fda-cyber-guidance-and-the-software-supply-chain-a-playbook-for-shifting-left)*

---

FDA Cyber Guidance and the Software Supply Chain: A Playbook for Shifting Left

Imagine that you’re a part of the development or regulatory team for a medical device manufacturer. You’ve been notified of a potential vulnerability in one of your devices deployed in a hospital. Your team immediately has two responsibilities: First, you must provide evidence demonstrating that the reported vulnerability does not pose a security or safety risk to patients, which involves a thorough risk assessment and documentation process. Second, if the vulnerability presents an uncontrolled risk, you need to initiate and oversee a comprehensive remediation process. This includes developing, testing, and deploying a security update or compensating control, and communicating effectively with hospital customers and potentially regulatory bodies. FDA Cyber Guidance and the Software Supply Chain: A Playbook for Shifting Left © Ketryx Corporation 2024 1

In both cases, your team’s actions must align with FDA guidance on postmarket management of cybersecurity in medical devices, maintain traceability of your decision-making process, and be prepared for potential regulatory scrutiny. To ensure regulatory compliance while still staying competitive in the market, medical device manufacturers must implement integrated tools and processes that address cybersecurity throughout the entire product lifecycle, from initial design and threat modeling to postmarket surveillance and updates. How do you do it? This white paper presents an integrated, shift-left approach to medical device cybersecurity that not only satisfies regulatory requirements but also enables manufacturers to respond quickly to emerging threats, assess risks effectively, and ultimately build and market more secure medical devices. PATCH ACT SBOM SPDX © Ketryx Corporation 2024 2

FDA Guidances on Cybersecurity for Medical Devices Connected medical device software (i.e., medical device software that is connected to the internet through Wi-Fi or Bluetooth) has revolutionized healthcare, but it comes with its own challenges. With their long lifespans and need for ongoing updates, connected devices present unique risks to patient safety and data privacy. Furthermore, if the security of a connected medical device is compromised, there’s a potential threat of multi-patient harm. And because most modern devices are connected to the internet and to other devices, multiple endpoints in that network (multiple devices) create added attack vectors, making it easier for bad actors to gain access to the system. Recognizing these risks, the FDA released two new guidances in 2023 to steer the industry, including the FDA cybersecurity1 and use of Off-The-Shelf Software guidances 2, and recommending the use of standards such as SW96 3 and TIR574. All of these guidelines emphasize that cybersecurity in medical devices is an ongoing process, not a one-time consideration. By adhering to these guidances, manufacturers can meet FDA requirements and enhance patient safety by: • Demonstrating robust cybersecurity measures in premarket submissions, including comprehensive risk assessments, controls, and management plans. • Tracking postmarket cybersecurity metrics to show the FDA in future submissions that their organization can effectively manage cybersecurity risks. These practices satisfy regulatory expectations and build public trust in medical devices by prioritizing cybersecurity as a critical component of device safety and effectiveness. Cybersecurity: Part of Device Safety & Quality System Regulation December 2016 Final Guidance • “Postmarket Management of Cybersecurity in Medical Devices” • Address cybersecurity throughout the product lifecycle December 2023 Final Guidance • “Off-The-Shelf Software Use in Medical Devices” • All about risk, mentions cybersecurity March 2024 Draft Guidance • “Select Updates for Premarket Cybersecurity Guidance: Section 524B of the FD&C Act” • Consider changes to the environment of use June 2023 Final Guidance • “Content of Premarket Submissions for Device Software Functions” • Cybersecurity discussed, mostly by reference, to other guidance documents September 2023 Final Guidance • “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” • Apply cybersecurity risk across the Quality System FDA is applying cybersecurity risk management across the whole quality system “...including but not limited to complaint handling, quality audit, corrective and preventive action, software validation and risk analysis and servicing.” 1 fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical- devices-quality-system-considerations-and-content-premarket-submissions 2 fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use- medical-devices 3 ncbi.nlm.nih.gov/pmc/articles/PMC10512983/#:~:text=AAMI%20TIR57%3A2016%2C%20 Principles%20for,83)%20soon%20after%20its%20publication. 4 webstore.ansi.org/standards/aami/aamitir572016r2023 © Ketryx Corporation 2024 3

This white paper focuses on the continuous management of postmarket vulnerabilities and the software supply chain. Before you enter the first phase of the postmarket cybersecurity lifecycle, you will already have generated a number of artifacts, such as threat models, a cybersecurity risk assessment, and security requirements and controls. The postmarket cybersecurity lifecycle involves the ongoing management of vulnerabilities and risks. This breakdown covers the specific activities that occur during each phase and the tools used to perform the activities. Section 524B 6 of the FD&C Act requires that medical device companies generate and maintain a Software Bill of Materials (SBOM) and monitor, mitigate, and address vulnerabilities in their third-party software components. SBOMs are comprehensive inventories of all medical device software components. They’re necessary for managing the cybersecurity risks associated with third-party software. SBOMs enhance transparency, facilitate faster vulnerability identification and response, improve risk management, and support regulatory compliance. Generating an SBOM is a critical first step in meeting FDA cybersecurity guidance for medical devices that many companies take. However, on its own, it is insufficient and is just one component of a complete cybersecurity lifecycle management strategy. Why are SBOMs important for medical device software security? The Postmarket Cybersecurity Lifecycle In this section, we will drill deeper into the specific phases of the postmarket cybersecurity lifecycle. The stages of the postmarket cybersecurity lifecycle are: • Analyze and Detect • Enrich and Score • Assess, Mitigate and Test • Approve • Release 6 https://www.congress.gov/117/bills/hr2617/BILLS-117hr2617enr.pdf © Ketryx Corporation 2024 4

Analyze and Detect Enrich and Score In this phase, teams analyze their source code repository for software components and software vulnerabilities. • Scan for software components: Scan source repositories to catalog all first- and third-party software components for inclusion in the SBOM. • Scan software components for vulnerabilities: Regularly scan the codebase and its dependencies for known vulnerabilities. Maintain comprehensive SBOMs to track all components and their versions. • Ensure this is updated on every product update: Keep SBOMs current, reflecting any changes in system components or versions, and continuously track new security vulnerabilities that could affect the system or its components. Tools • SCA tools: Software composition analysis (SCA) tools offer a range of functionalities that assist with cybersecurity and compliance. They analyze and monitor a company’s source code repository, including software of unknown provenance (SOUP) and off-the-shelf (OTS) software, to identify vulnerabilities that need to be managed downstream in the lifecycle. SCA tools will also identify software components to help create the SBOMs that the FDA requires in premarket submissions. Examples include Snyk, Black Duck, and Mend.io. In this phase, teams enrich vulnerabilities with NTIA, FDA, and internal metadata and assign a vulnerability severity score (e.g. CVSS) to each vulnerability. • Approval for use: Identify whether the software package is approved by your organization. • Scoring vulnerabilities: Score the vulnerability using CVSS, potentially leveraging the MITRE Rubric for Applying CVSS to Medical Devices7. • FDA-required Metadata: Document end of life and level of support. Tools • SBOM tools: Your SCA tool may be able to generate an SBOM, but additional work must be done downstream after the SBOM is generated. This often includes using SBOM tools to integrate SBOMs across different parts of your application and document information required for FDA compliance (e.g., support level and end-of-life date). After that, identified vulnerabilities are further assessed so the organization can prioritize mitigation steps such as implementing security patches and developing compensating controls. • Excel: Without an SBOM tool, many companies use Excel to record and track SOUP and OTS. 7 mitre.org/sites/default/files/2021-11/pr-18-2208-rubric-for-applying-cvss-to- medical-devices.pdf © Ketryx Corporation 2024 5

Assess, Mitigate, & Test In this phase, teams assess the risk of software packages, mitigate risk with design changes and compensating controls, and document evidence that security controls were tested. Risk analysis • Security risk analysis: Perform security risk analysis for your device and record the results in the security risk management file. • Ongoing risk assessment: Regularly reassess the system’s security posture in light of new threats or changes in the threat landscape. Design change and compensating controls • Mitigations: Mitigate risk through design changes and compensating controls in the system that can be added to Jira as change requests for development. • Security controls: Design specific security measures, such as encryption schemes, authentication protocols, and intrusion detection systems, to address identified risks. • Implement security controls: Code and integrate the security measures defined in the design phase, ensuring they’re properly implemented and interact correctly with other system components. • Analyze potential safety risk: Analyze security controls to ensure they do not introduce a safety risk. Transfer analysis to safety risk process. Testing • Validate controls: Verify that implemented security controls function as intended and effectively mitigate the risks they were designed to address. • Security testing: Conduct comprehensive security tests, including penetration testing, fuzz testing, and security-focused unit and integration tests. • Security risk management review: Conduct a comprehensive security review of the entire system before release. Tools • Risk assessment tools: Many teams use Excel or their eQMS or ALM to perform risk analysis. • Mitigations and tests: Risk mitigations and corresponding tests may be documented in Jira, GitHub, Excel or an ALM or eQMS. • Threat Modeling: Teams may use methodologies like STRIDE and tools like Excel, Microsoft Threat Modeling Tool and OWASP Threat Dragon for threat modeling. • SBOM tools: Your SBOM tool likely helps you find vulnerabilities but may not provide a workflow to connect those vulnerabilities to risks, risk controls, and mitigations and to document all of those items. © Ketryx Corporation 2024 6

Approve Release In this phase, teams collect necessary approvals from all required stakeholders. • Documentation: Prepare and submit all necessary documentation to demonstrate compliance with relevant security standards and regulations. • Approvals: Manufacturers must secure approvals for key documentation, including their Software of Unknown Provenance (SOUP) list, vulnerability reports, and cyber risk assessments (including threat models). Traditionally, these approvals are executed in bulk at the end of the product lifecycle, using tools like PLM or eQMS, and are often spread across multiple systems. A more efficient approach is to approve documentation and assessments piecewise throughout the lifecycle, ensuring a proactive and continuous risk management process. Tools • Records of approvals may be stored in a PLM, ALM, or eQMS. In this phase, teams complete all documentation needed for release and document postmarket metrics. • Apply security patches: Regularly update the system with security patches and fixes, prioritizing updates based on risk severity. • Postmarket metrics: Document postmarket cybersecurity metrics like percentage of identified vulnerabilities that are updated or patched (defect density), duration from vulnerability identification to when it is updated or patched, and duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known.

Tools • Many teams create some or all of their release documents in Word or Excel and track SOUP & OTS. © Ketryx Corporation 2024 7

Top challenges in the cybersecurity lifecycle Teams building medical device software frequently face challenges in managing cybersecurity. When these problems are not resolved by shifting left to manage potential issues earlier in the lifecycle, they can have serious and even life-threatening consequences for patients using your device. In this section, we will cover the challenges teams face in each stage of the cybersecurity lifecycle and why each of these challenges exist. Stage: Analyze SOURCE OF CHALLENGE 1 Medical devices often include a mix of proprietary, opensource, and third- party software components. Each component may have dependencies and subcomponents, meaning that as new components are added or versions change, the SBOM becomes larger and more difficult to manage. Software components in medical devices are frequently updated due to new features, security patches, or compliance requirements. Many teams still rely on manual processes or fragmented tools to track these changes. Without automation, this process is inefficient and prone to errors, as it’s difficult to ensure every update or new component is captured. CHALLENGE 1: Keeping SBOMs up to date Continuously tracking and updating the inventory of all software components and their versions and continuously updating SBOMs as new components are added or versions change can be time-consuming and burdensome, especially if done manually. SOURCE OF CHALLENGE 2 Each system or component may have its own unique vulnerabilities, protocols, and software requirements. The interactions between these systems can create additional risks and vulnerabilities. Furthermore, the lack of standardization across systems and the difficulty in ensuring comprehensive security measures for each interaction contributes to the challenge. CHALLENGE 2: Managing the complexity of interconnected components Medical devices often interact with many other systems and components, creating a complex web of potential vulnerabilities that can be challenging to fully understand and secure. Generating SBOMs at scale requires automation, which in turn requires the ability to ingest information from build systems, SBOM-generation tools, and SBOMs delivered by component vendors and open source projects. A major challenge in ingesting this information is data normalization, using a standard nomenclature and formats to ensure that data from various sources is consistent. — MITRE’s Data Normalization Challenges and Mitigations in SBOM Processing “ ” © Ketryx Corporation 2024 8

CHALLENGE 2: Limitations of SCA and SBOM tools Traditional SCA and SBOM tools operate in isolation, separate from other development and lifecycle management tools (like your ALM, PLM, or eQMS), making it challenging to maintain a comprehensive view of the device’s security posture. They also often lack the robust documentation and audit trail capabilities needed to meet FDA traceability requirements. Additionally, these tools often lack the context of how a particular component is used within the device, which can lead to over-analysis of vulnerabilities that may not be applicable or critical in the specific implementation. Traditional SBOMs are often static documents, while FDA requirements necessitate ongoing monitoring and updates throughout the device’s lifecycle. These tools’ limitations make tracking vulnerabilities across different product versions and deployments difficult. SOURCE OF CHALLENGE 2 Traditional SCA and SBOM tools are limited in scope because they were primarily designed for general software development, not for highly regulated industries like medical devices. These tools were built to identify open-source components and vulnerabilities but lack the specialized features needed for compliance with FDA regulations. As a result, they aren’t equipped to handle the ongoing monitoring, context-specific vulnerability reporting, or the rigorous audit trail capabilities necessary for regulatory compliance in industries like MedTech. STAGE: Enrich and Score SOURCE OF CHALLENGE 1 Medical device teams must continuously manage and categorize vast amounts of specialized data to ensure security and regulatory compliance. Sharing this information across teams, and generating the required documentation, often requires significant manual effort due to fragmented processes, organizational silos, or lack of automation. CHALLENGE 1: Tooling without collaboration While SCA and SBOM tools provide a solid foundation, the real challenge lies in leveraging this information effectively throughout the entire product lifecycle to ensure ongoing security and regulatory compliance for medical devices. It’s important to consider how teams will share and categorize all of this specialized information and generate necessary documentation without requiring significant manual work. © Ketryx Corporation 2024 9

CHALLENGE 2: Lack of organization-wide sharing of information Despite obtaining SOUP and OTS metadata, medical device software companies often report a lack of organization-wide sharing of information. This results in manual, time-consuming traceability and impact assessments from risk analysis to SBOM components, vulnerabilities, and threat models. SOURCE OF CHALLENGE 2 Organizations often lack the processes, tools, or culture to facilitate the effective sharing of SOUP and OTS metadata across departments. Additionally, companies may not have integrated systems or workflows in place to centralize and distribute this metadata effectively. Without automated sharing and collaboration tools, the process can be manual and inconsistent, leading to a disconnect in the flow of crucial information needed for compliance and security across the organization. STAGE: Assess, Mitigate, & Test CHALLENGE 1: Risk analysis disconnected from cybersecurity activities and tools You need to assess and document risks and mitigations surfaced by cybersecurity concerns, but your SBOM tool is likely disconnected from your risk management tool (i.e. Excel, ALM, PLM, or eQMS). Many organizations still rely on multiple, disparate tools and systems for managing risk, leading to fragmented information and inefficient processes. Cybersecurity risks are controlled by mitigations documented in the R&D process (likely stored in an ALM), such as requirements, specifications, and V&V testing. Without a link between the systems where risks are stored and the systems where mitigations are documented, teams may encounter overlooked vulnerabilities, delayed responses, and incomplete risk assessments. SOURCE OF CHALLENGE 1 Organizations often use separate tools and systems for managing risk and cybersecurity activities because these tools were historically developed to address different aspects of the business. Risk management tools were traditionally part of an ALM and focused on product or safety risks, while cybersecurity tools were created specifically for technical threats and vulnerabilities. Over time, these tools evolved independently. Additionally, legacy systems and the lack of standardized, integrated solutions for both risk and cybersecurity management have caused companies to adopt multiple, specialized tools without fully integrating them. Organizational silos, budget constraints, and resistance to change also contribute to maintaining separate systems. © Ketryx Corporation 2024 10

CHALLENGE 4: Integration of security processes with existing development workflows Incorporating security practices into established development processes requires careful change management and widespread advocacy for encouraging developers to mitigate issues throughout the development process (that is, embracing a shift left mentality). This adoption and integration of security checks into development workflows can potentially slow product timelines. SOURCE OF CHALLENGE 4 Integrating security processes into existing development workflows requires significant organizational change. Development teams are often focused on speed and efficiency, and adding security checks early in the process can be seen as slowing down timelines. Shifting security “left” requires a cultural shift, widespread advocacy, and careful change management to ensure that developers prioritize security alongside development tasks. Additionally, existing workflows may not be designed to incorporate security seamlessly, requiring new tools, processes, and training to ensure that security is embedded throughout the lifecycle without significantly impacting productivity. STAGE: Assess, Mitigate, & Test continued CHALLENGE 3: Traceability gap between risks and vulnerabilities As development progresses, the SBOM remains a central artifact, interfacing with PLM, ALM, or eQMS tools. These systems utilize the SBOM throughout risk assessment and testing, documentation, release, and postmarket metrics gathering. For example, cyber requirements and testing data documented in an ALM and risk assessments documented in an eQMS are not always traced to software components and vulnerabilities documented in the SBOM. This is problematic because teams must provide risk assessment on vulnerabilities, so when systems are disconnected, they must take extra time and effort to copy and paste vulnerabilities into the system where they document risks. SOURCE OF CHALLENGE 3 This challenge exists because many organizations lack integrated systems that link information across tools like ALM, PLM, eQMS, and SBOM. These systems often function in silos, making it difficult to trace connections between cyber requirements, testing data, and risk assessments back to specific software components and vulnerabilities in the SBOM. Without a unified platform or automated processes to ensure this traceability, critical gaps can form between different stages of the product lifecycle. This disconnection leads to incomplete visibility into how risks and vulnerabilities are managed and addressed, ultimately affecting the overall security and compliance of the product. © Ketryx Corporation 2024 11

CHALLENGE 6: Siloed relationship between cybersecurity and R&D teams Managing design changes and their impact on SBOM components and vulnerabilities can be a labor-intensive process for medical device software companies, often requiring manual traceability. Additionally, critical mitigation information is not always shared across the organization, leading to communication gaps and potential security risks. SOURCE OF CHALLENGE 6 Managing design changes and their impact on SBOM components requires detailed tracking and manual traceability, which is time-consuming and prone to human error. Many medical device software companies lack automated tools to efficiently handle design changes and trace their effects on components and vulnerabilities. Furthermore, the absence of centralized systems for sharing mitigation information across departments leads to communication gaps. These gaps prevent timely updates and coordination, increasing the risk of unaddressed vulnerabilities or inconsistencies in the security posture across the organization. This fragmented approach makes it difficult to ensure comprehensive security and compliance throughout the product lifecycle. CHALLENGE 5: Postponing risk analysis until the tail end of the lifecycle Delaying risk analysis until late in the development process can lead to significant security issues being discovered too close to release, resulting in rushed fixes, increased costs, and potential delays. This approach also misses opportunities for early risk mitigation and can lead to architectural or design flaws that are costly and difficult to address late in the development cycle. SOURCE OF CHALLENGE 5 Many organizations prioritize rapid development and may view risk analysis as a compliance task rather than an integral part of the development process. By postponing risk analysis until later stages, teams focus on building features first, believing they can address security and risks afterward. However, this results in missed opportunities to identify and mitigate risks early when changes are easier and less costly to make. Additionally, late-stage risk analysis can uncover architectural or design flaws that require significant rework, causing delays and increased costs, as fixes must be rushed to meet deadlines. This delay stems from a lack of integration between security and development teams, a lack of early focus on security, and pressure to deliver products quickly. STAGE: Assess, Mitigate, & Test continued © Ketryx Corporation 2024 12

STAGE: Assess, Mitigate, & Test continued STAGE: Approvals CHALLENGE 7: Test executions are not traced to SOUP/OTS and vulnerabilities Medical device software companies often struggle with the manual effort required to trace testing outcomes back to SBOM components and vulnerabilities. Assessing the impact of changes to determine what needs to be tested or re-tested can be time-consuming, and ensuring that anomalies are properly evaluated for cybersecurity risks and thoroughly tested presents additional challenges. SOURCE OF CHALLENGE 5 These challenges arise because existing workflows and tools are not optimized for the dynamic, highly regulated, and complex nature of medical device software development, making it difficult to ensure thorough testing, security, and compliance. CHALLENGE 1: Coordination between Quality, R&D, and Product Security teams Effective coordination between Quality, R&D, and Product Security teams ensures that vulnerabilities are communicated and addressed without conflicts, avoiding the inefficiencies of managing separate systems and balancing differing priorities in development, operations, and security. SOURCE OF CHALLENGE 1 Quality, R&D, and Product Security teams often work in siloed systems with differing priorities—R&D focuses on rapid development, operations prioritizes stability, and security emphasizes risk mitigation. Without communication between these teams, vulnerabilities can be overlooked, duplicated, or handled inconsistently across systems, leading to inefficiencies and potential security gaps. The lack of coordination makes managing vulnerabilities effectively while balancing each team’s objectives difficult. © Ketryx Corporation 2024 13

CHALLENGE 3: Maintaining control over SOUP/OTS components or vulnerabilities Medical device software companies often face the risk of releasing unapproved SOUP/ OTS components, deploying incorrect versions, or unintentionally deploying uncontrolled vulnerabilities. These issues can lead to security risks and compliance concerns. SOURCE OF CHALLENGE 3 The absence of automated version control and approval mechanisms makes it difficult to ensure that these components’ correct and approved versions are consistently deployed. Additionally, fragmented or manual tracking systems increase the likelihood of introducing uncontrolled vulnerabilities, as teams may overlook critical updates or fail to trace vulnerabilities tied to specific components. The complexity of managing multiple software sources and the need for strict regulatory compliance exacerbates these risks when proper governance and oversight tools are not in place. CHALLENGE 2: Shifting approvals left Approvals for SOUP/OTS items are typically done late in the development process within PLM or eQMS systems. However, delaying approvals increases the risk of needing costly rework if a component must be replaced close to release. Shifting approvals left ensures these items are approved earlier, reducing the likelihood of last-minute changes and expensive delays in the software development lifecycle. SOURCE OF CHALLENGE 2 This challenge exists because traditional development processes are designed to complete approvals at the end of the lifecycle in systems like PLM or eQMS, treating security and compliance as final-stage tasks. Shifting approvals left is difficult because it requires integrating these approval processes earlier in the development cycle, which can be disruptive to existing workflows and requires closer coordination between teams and tools throughout the lifecycle. STAGE: Approvals continued © Ketryx Corporation 2024 14

CHALLENGE 2: Burdensome manual documentation and process verification for cybersecurity activities Medical device software companies often face the burden of manually creating documentation for SBOM, vulnerability reports, cyber risk assessments, and cyber traceability matrices, as well as manually tracking postmarket cyber- security metrics. This process is time-consuming and prone to errors, delaying release cycles and complicating compliance efforts. SOURCE OF CHALLENGE 2 Many medical device software companies lack automated tools and systems to generate and maintain cybersecurity-related documentation. Instead, they rely on manual processes for creating SBOMs, vulnerability reports, risk assessments, and traceability matrices, which are time-consuming, error-prone, and labor-intensive. Additionally, tracking postmarket cybersecurity metrics often involves manual data collection and analysis, further adding to the workload. These manual processes slow down release cycles, create inefficiencies, and complicate compliance with regulatory requirements, as errors and inconsistencies can lead to delays in approval or increased security risks. The lack of automation and integration between development and compliance systems is the root cause of this burden. STAGE: Release CHALLENGE 1: Postmarket metrics Documenting postmarket cybersecurity metrics is challenging because critical information—such as vulnerability identification, patch updates, and deployment timelines—is scattered across multiple tools, including SBOMs, DevOps pipelines, and mobile device management systems. Manually consolidating these metrics from different systems makes tracking and reporting time-consuming and prone to errors, hindering effective cybersecurity management. SOURCE OF CHALLENGE 1 The tools used to track postmarket cybersecurity metrics—such as SBOMs, DevOps pipelines, and mobile device management systems—are typically siloed and not integrated. Each system holds only a piece of the relevant information, making it difficult to get a unified view of cybersecurity performance. This forces teams to manually gather and document metrics, which is time-consuming and increases the risk of errors. © Ketryx Corporation 2024 15

CHALLENGE 2: Not shifting left It’s common to leave security testing until the end of the development process, which can lead to costly late-stage fixes. SOURCE OF CHALLENGE 2 Traditional development workflows often prioritize feature delivery and functionality over security, leaving security testing until the final stages. This approach stems from a mindset that security is a separate, final step rather than an integral part of the development process. As a result, vulnerabilities may go unnoticed until late in the cycle, leading to costly, time-consuming fixes that could have been avoided with earlier testing and integration of security measures. Shifting left requires a cultural and process change, which many teams find difficult to implement within established workflows. CHALLENGE 3: Adapting to changes Many organizations, especially large ones, lack the agility to easily adapt to necessary changes (e.g., having to update a library to mitigate a new vulnerability without involving the same overhead as a full release). SOURCE OF CHALLENGE 3 Larger organizations often have complex, rigid processes and extensive regulatory or internal controls that make adapting to changes difficult. Updating something as simple as a library to mitigate a new vulnerability can require the same level of oversight, documentation, and approval as a full product release, leading to significant overhead. These bureaucratic processes hinder agility, leaving systems exposed to vulnerabilities for longer periods. Ever-present challenges in postmarket cybersecurity These challenges are present in every stage of the postmarket cybersecurity lifecycle. CHALLENGE 1: Postmarket vulnerability monitoring Manufacturers must manage security for multiple software versions that remain in use, requiring continuous oversight. Shifting left by integrating security practices earlier in development helps catch vulnerabilities sooner, aligning with Section 524B of the FD&C Act 8. Additionally, manufacturers must release postmarket updates and patches on a regular cycle for known unacceptable vulnerabilities while addressing critical vulnerabilities out of the cycle as quickly as possible. SOURCE OF CHALLENGE 1 Manufacturers often have multiple software versions in use simultaneously, each requiring ongoing security monitoring and updates. The complexity is further heightened by the need to release patches regularly for known vulnerabilities while addressing critical vulnerabilities out of cycle, which demands constant oversight and quick response. Additionally, many development processes still lack early integration of security practices (“shifting left”), making it harder to identify and resolve vulnerabilities early. 8 fda.gov/medical-devices/digital-health-center-excellence/cybersecurity- medical-devices-frequently-asked-questions-faqs © Ketryx Corporation 2024 16

Benefits of optimizing the cybersecurity lifecycle Solving for the challenges listed above has several key benefits for medical device manufacturers. • Enhanced Compliance with Regulatory Requirements: By addressing issues like fragmented risk management, SBOM updates, and disconnected cybersecurity tools, organizations can improve their ability to meet FDA and other regulatory standards. This ensures better documentation, audit trails, and traceability, reducing the risk of non-compliance and potential penalties. • Improved Security Posture: Integrating risk management with cybersecurity activities, and ensuring continuous SBOM updates, allows organizations to identify and mitigate vulnerabilities more effectively. This reduces the chances of security breaches and helps protect against potential threats that could compromise patient safety or lead to multi-patient harm. • Increased Efficiency and Reduced Manual Work: Automating the processes of managing SBOMs, risk assessments, and vulnerability tracking across ALM, PLM, and eQMS tools reduces manual effort and the risk of human error. This streamlines workflows, enabling teams to focus on more strategic tasks and accelerating development timelines. • Holistic View of Device Security: By linking cybersecurity requirements, risk assessments, and SBOM data across systems, organizations gain a comprehensive, real-time view of their product’s security. This allows for better-informed decision-making, faster incident response, and a clearer understanding of how vulnerabilities and risks affect the entire product lifecycle. Embracing DevSecOps It’s important to note that the activities included in the development phase above are fundamental to a DevSecOps approach. DevSecOps extends the DevOps philosophy by integrating security practices throughout the entire software development lifecycle, making cybersecurity a shared responsibility across development. DevSecOps allows for continuous security testing through the development process, immediate feedback for developers regarding potential security issues, and automated security gates that prevent problematic code from progressing to the next phase of development. © Ketryx Corporation 2024 17

The key to overcoming cybersecurity challenges in MedTech: Shifting left Solving the challenges presented by a disconnected cybersecurity lifecycle requires a comprehensive approach that spans the entire product lifecycle. Here’s what this process looks like as part of a connected MedTech cybersecurity lifecycle where SBOM components are managed in a central place and incorporated across risk management processes. Instead of relying on disconnected tools and processes to manage cybersecurity risks, medical device manufacturers must connect the dots between vulnerability management, SBOM generation, risk management, and lifecycle management. © Ketryx Corporation 2024 18

Here are some best practices that teams developing medical device software should follow in order to build a connected cybersecurity lifecycle: By adopting a holistic security framework, MedTech companies can significantly enhance product safety, ensuring that their devices meet the highest standards of security and reliability. This approach also enables manufacturers to meet increasingly stringent regulatory requirements more effectively. Lastly, it allows companies to maintain development efficiency despite the added security measures, ensuring that innovation is not stifled by security concerns. This integrated approach helps companies stay competitive in the market and maintain public confidence in their devices, a crucial factor in the sensitive healthcare sector where patient trust is paramount. Integrating threat modeling into R&D: Threat modeling should be a cornerstone of the R&D process, including early-stage threat analysis, continuous threat modeling using automated tools, and proactive design thinking wherein developers and designers consider potential misuse of the product. Connecting cyber and safety risk management: Develop a comprehensive framework that evaluates both cybersecurity vulnerabilities and potential patient safety impacts. This involves creating risk assessment practices that address both cybersecurity issues and patient safety, deriving security requirements directly from safety analyses, and establishing clear cybersecurity incident response protocols. Automating security testing and enforcement: Device manufacturers should build an automated security testing pipeline that accounts for average vulnerability detection as well as edge cases and unexpected inputs. They should also automate compliance checks and develop systems for rapid, intelligent patch management. For connected medical devices, secure over-the-air updates and failsafe mechanisms are also critical. Shifting left: Security thinking must be embedded into the earliest stages of the product development process, including using secure-by-design principles, equipping developers with the tools and knowledge to write secure code, and fostering a culture where security is everyone’s responsibility. © Ketryx Corporation 2024 19

AI-powered nutrition platform Nutrino Health was looking for a way to manage thousands of items across their software supply chain, including open-source software, off-the-shelf software (OTS), and other Software of Unknown Provenance (SOUP). Generating an FDA-compliant Software Bill of Materials (SBOM) was consuming considerable developer time, impeding the pace of development and lengthening the time to market. PAIN POINTS Burdensome, Labor-Intensive Manual Documentation DevOps and Quality teams were dedicating countless hours to manual SBOM generation and software supply chain risk management for open- source software. This exhaustive effort not only drained valuable time but also exposed them to risks like overlooking vulnerabilities, developer turnover, and potential compliance audit failures. KETRYX SOLUTION A Self-Documenting SDLC Nutrino sought a developer-centric solution to streamline and secure SDLC management and selected Ketryx to achieve the following objectives: • Automatic Document Generation: Ketryx seamlessly generates supplier data for SOUP and OTS, including manufacturer names and known anomaly lists, and integrates it with risk management information. Automating document generation replaced tedious manual processes, significantly increasing productivity. • Risk Management: Ketryx provides an intuitive platform for effective risk management that includes security and reliability assessments, simplifying FDA-required risk analysis for OTS. • Developer and Quality Productivity: Ketryx’s automated monitoring and notification system for attempted changes in the source code saves valuable time for R&D and Quality teams, who no longer have to manually find and input vulnerabilities. BUSINESS OUTCOMES Faster Validated Releases With Ketryx, the Nutrino team quickly realized several key benefits: • Reduced Documentation Time: Reduced SBOM documentation time by 90%, saving valuable developer time and generating an SBOM instantly. • Expedited Development with a Risk-Based Approach: Shortened time to market and sped up development time through risk-based SOUP, open-source software, and vulnerability management, releasing software faster and more frequently. • Increased Cybersecurity: Shifted left to address potential vulnerabilities earlier in the development process, enhancing product quality, security, and efficiency. How This AI-Powered Medical Software Company Reduced SBOM Documentation Time by 90% Ketryx empowered Nutrino to accelerate the adoption of OTS software and SOUP, ensuring confidence in our ability to proactively identify high-risk components and address potential issues early in the premarket submission cycle. This streamlined SDLC process has enabled us to deliver innovative and safe diabetes solutions much more rapidly. — Chen Weitz Senior Engineering Director, Nutrino “ ” © Ketryx Corporation 2024 20

Looking Ahead: Future Trends in Secure Device Development Several key trends will shape the future of secure product lifecycle management. Artificial intelligence and machine learning are being rapidly integrated into medical device security, offering advanced threat detection and automated response capabilities. But simultaneously, new and more complex attack vectors are emerging, challenging manufacturers to stay ahead of potential vulnerabilities. The regulatory landscape is also evolving, with agencies like the FDA continually updating their guidance to address these new challenges. Amid these changes, the role of cybersecurity has become more critical. As medical devices become more connected and data-driven, comprehensive security measures will be necessary not only for meeting regulatory compliance but also for maintaining public trust in healthcare devices. Master FDA-compliant cybersecurity for your medical device with Ketryx Effective cybersecurity management lies in connecting all aspects of a product’s lifecycle. Traditional SCA tools, while valuable for generating SBOMs and identifying vulnerabilities, fall short of meeting the FDA’s comprehensive requirements for SBOMs and vulnerability management. Your SCA tool, SBOM tool, lifecycle management tool (ALM or PLM), eQMS, and DevTools must all be connected in order to effectively assess, manage, and mitigate risk caused by cybersecurity concerns. A connected lifecycle management tool like Ketryx addresses these gaps by providing comprehensive lifecycle coverage. It enables teams to get a holistic view of a device’s security measures from initial design through postmarket surveillance. By integrating with existing development, quality management, and security tools, Ketryx provides a single source of truth for all security-related information. © Ketryx Corporation 2024 21

Here’s how Ketryx facilitates a connected cybersecurity lifecycle: Ketryx provides a centralized view of your software supply chain, across multiple products and projects, directly from source code. Ketryx enables seamless sharing of SOUP/OTS metadata across the organization and automates the traceability process from risk to SBOM components and vulnerabilities. It also supports integrated safety and cyber risk analysis, allowing for streamlined workflows. These features promote collaboration and knowledge sharing while eliminating the need for manual documentation and tracing, ultimately improving efficiency and reducing risk across the software development lifecycle. These features address the challenge of medical device software companies not sharing SOUP and OTS metadata organization- wide, and covers the traceability gap between data stored in disparate systems. Ketryx ensures compliance with Part 11 regulations via electronic signatures for regulatory documentation. Ketryx enables SBOM component- and vulnerability-level approvals, ensuring that no software is released with unapproved SBOM components or vulnerabilities. Additionally, Ketryx prevents the release of software with flexible or floating versions. This automation eliminates the need for manual process verification before release and helps identify problematic SOUP/OTS components early in the development cycle, improving both security and efficiency. This set of features solves the issue of releasing unapproved SOUP/OTS components, deploying incorrect versions, or unintentionally deploying uncontrolled vulnerabilities. Ketryx automatically generates documentation and tracks key cyber metrics, including vulnerability reports and patch release dates. This reduces the need for manual documentation, shortens the release cycle, and enables companies to demonstrate proper cybersecurity management for successive premarket submissions. Ketryx’s ability to automatically generate documentation replaces the manual creation of documentation for SBOM, vulnerability reports, cyber risk assessments, and cyber traceability matrices, as well as manually tracking postmarket cybersecurity metrics. Automatically identifying and applying relevant FDA-required compliance metadata and vulnerabilities for each SOUP item in accordance with IEC 62304. Ketryx automatically traces anomalies to both risk and testing activities, enforces that all cyber risk assessments are completed, and ensures that anomalies undergo necessary testing. Ketryx also establishes traceability from each vulnerability to design mitigations, compensating controls, and risk transfer documentation. This reduces rework and the likelihood of missed defects late in the release cycle while eliminating the need for manual process verification, ultimately improving efficiency and the security of the software. This functionality solves the problem of manually tracing testing outcomes back to SBOM components and vulnerabilities. © Ketryx Corporation 2024 22

Achieve FDA-Grade Cybersecurity with Ketryx With Ketryx, connected cybersecurity and dynamic SBOM management become possible. Ketryx enables continuous updating and monitoring of SBOMs, aligning with FDA requirements for ongoing vulnerability management. By mapping its features directly to FDA requirements, Ketryx simplifies the process of demonstrating compliance during regulatory audits. Watch our webinar on FDA-compliant cybersecurity and vulnerability management. SBOM SPDX PATCH ACT © Ketryx Corporation 2024 23

© Ketryx Corporation 2024 24

To learn more about FDA-compliant cybersecurity lifecycle management, contact us today at www.ketryx.com Schedule a demo today by scanning this QR code or visiting: go.ketryx.com/cyber-whitepaper