Your software supply chain could be a cybersecurity risk. Here’s what you can do.

Vince Arneja, GrammaTech

The healthcare industry has been fighting a war on two fronts during the COVID-19 pandemic against the virus and an outbreak of cyberattacks. The Department of Health and Human Services says the sector reported a 9,851% increase in cyberattacks in 2020 compared to 2019.

Cybercriminals see healthcare organizations as “soft targets” that are not as well defended; they need to be accessible to users and have heavy traffic of files and records, which leave multiple attack vectors open for criminals. In addition, healthcare is in the midst of a technology expansion, with explosive growth in Internet of Things (IoT) connections, patient portals and telehealth.

All these new medical technology applications run on software. MarketsandMarkets Research says healthcare IT spending will grow more than 20% every year through 2026, and most of that growth will come from enterprise software. The software development process — both for custom and off-the-shelf programs — often relies on what’s known as “Software of Unknown Pedigree/Provenance (SOUP),” or code from open-source libraries or other sources that developers use to save time and money by copying the programming of common functions. The practice lets them develop and update software at speed and scale, but can also expose vulnerabilities that attackers can use to steal patient and PII data or install malicious code such as spyware or ransomware that can disrupt critical healthcare services.

In this environment, protecting medical devices from security vulnerabilities in open source and third-party code is imperative. Supply chain attacks are a growing concern among all industry sectors, and medical devices present a large attack surface for this type of threat.

Protecting medical devices from supply-chain poisoning

The FDA already requires risk management of third-party software and other SOUP for pre-market approval of medical devices. Still, comprehensive software risk management, augmented with automated analysis, can also help analyze and fix vulnerabilities in software at speed and scale.

For example, software composition analysis can help software supply chain risk management by providing insight into open source and third-party code. A software bill of materials (SBOM) should be a basic part of risk management efforts. You can’t secure what you don’t see.

These outside sources of software can often fly under the radar of security; analyzing them requires specialized skills and can be costly and time-consuming. Automated tools can be key to understanding and managing risk and documenting, tracking, and communicating the risks associated with SOUP.

So how to protect medical devices to avoid landing in the SOUP? Some best practices to reassess your approach to software security can lower the risk and liability from third-party software:

• Adopt new guidelines for software development. The techniques and methodology for developing both software and critical devices are evolving. Any organization will benefit from reviewing software risk management, development and security best practices. Including software as part of supply chain management is critical, as is evaluating software for safety, quality, and security.

• Combine risk management with security threat analysis and assessments. Security should be a part of medical device risk management at all stages of development. A safety analysis may focus on the device’s medical function and overlook its cybersecurity, but a device open to hacking is not a safe device. The assessment must include the software supply chain, including any off-the-shelf software and SOUP.

• Manage the software supply chain. Most software development will continue to reuse code or leverage existing open-source or commercial programs. Creating an SBOM to understand the make-up of the software enables your organization to detect vulnerabilities that may be hiding in open source and third-party code. Reducing this risk will require continuous assessments of the quality and security of SOUP and other code, internal or external to the company.

• Integrate automated development and testing tools. As software approaches evolve, an automated toolbox is critical to leverage increased security, quality, and safety opportunities. Static application security testing (SAST) is required to find and fix defects through the software development life cycle (SDLC). Additionally, software composition analysis to parse out the SBOM needs to play an important role in automating the vetting of software.

• Integrate security and safety audits continuously. Automation allows security staff to continually monitor the security of software under development when it’s part of a continuous integration and deployment pipeline. Confirming that software meets the auditing standards complies with the FDA requirement for pre-market approval, and doing so continuously avoids any unexpected shocks later in the development process.

Forrester found that 85% of healthcare organizations claim to be very or extremely concerned about the security risks of IoT devices, and 95% are spending more to secure their devices in the next two years. Tighter management of supply-chain risk throughout the SDLC should be a key part of the effort to deliver medical devices with a security-first mindset.

Vince Arneja is chief product officer for GrammaTech (Bethesda, Maryland) — a  provider of application security testing solutions including static analysis (SAST) and software composition (SCA) products. Arneja has over 20 years of management experience in product strategy spanning application, cloud, mobile, endpoint and network security. 

The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of MedicalDesignandOutsourcing.com or its employees.