Software as a Medical Device
Second Edition
77 Regulatory Affairs Professionals Society
of unknown provenance. Third parties typically provide these
details in a software bill of materials (SBOM). Tools that
can analyze an SBOM and compare it with vulnerability
databases are required to be able to do proper vulnerability
handling. The IMDRF document Principles and practices
for software bill of materials for medical device cybersecurity
provides further insights.24
All software is prone to vulnerabilities that could, for
example, be introduced by poor design, inadequate coding
practices, improper fault handling, or compiler-introduced
security issues, or which may even be inherent in hardware,
such as CPUs. Attackers may find vulnerabilities in the man-
ufacturer’s software as well as in any third-party software and
hardware used. The more commonly used the software is, the
more attractive it is to attackers, and therefore, it presents a
greater possibility that new vulnerabilities will be discovered.
A vulnerability does not in itself directly introduce a risk.
Only when the vulnerability can be exploited by a person
or by malicious software attacking the underlying system or
infrastructure, does it become a risk. Some vulnerabilities
remain undiscovered for many years for instance, CVE-
2020-1317, a serious vulnerability in the Windows Group
Policies, lingered in the Microsoft Windows operating system
since 2008 before it was discovered and publicly disclosed
on 9 June 2020.25 Once discovered, the probability that a
vulnerability will be exploited may remain low if the attack
is complex, especially if multiple vulnerabilities must be
exploited for a successful attack. However, when a successful
attack has been published and proof-of-concept code has
been made available, the probability increases significantly,
as the attacker’s required skill level is reduced to perform a
successful attack.
Threat actors capable of complex attacks aim to prevent
the discovery of their attacks and the vulnerabilities they
exploit, thereby hiding their malicious activities for as long as
possible. For the same reason, they might target less com-
monly used software or even target specific software from a
single vendor.
As thousands of security vulnerabilities are discovered
and reported every month, it is crucial to be aware of new
vulnerabilities promptly. Security monitoring should start
while a SaMD is still in development to remediate any
vulnerabilities as early as possible this monitoring should
continue throughout the SaMD’s total product lifecycle.
Security monitoring should also begin during the design
phase and continue during the operation of the SaMD’s
intended operational use environment (platform and infra-
structure), under the control of the manufacturer or user.
Security vulnerability analysis should be triggered at
specific intervals, such as weekly or monthly, based on factors
including the type of SaMD, its components, the supporting
platform and network infrastructure used, and the associated
risks. An analysis should also be triggered and expedited by
specific events or security issues the manufacturer becomes
aware of. These indicators might originate from sources such as:
• Complaints and security incidents
• Vulnerabilities and patches reported by suppliers of
components
• Security issues reported by tool vendors (e.g., compilers
and software development kits)
• New risks identified by other third parties (a coordi-
nated vulnerability disclosure, media outlets, the security
community, an information sharing and analysis center
[ISAC], a computer emergency response team [CERT],
national cyber security center, etc.)
• Vulnerabilities identified by running security test tools
(e.g., vulnerability scanning, pen testing, fuzz testing,
secure code analysis, and software bill of material analysis
tools)
• Attacks on the infrastructure
• New risks identified in internal components and similar
products and
• Changes in the threat landscape.
Security monitoring is a continuous process. Figure 7-2
shows an exemplary generic monitoring flow.
Although the SaMD manufacturer sets the requirements
for the intended operational use environment (platform,
supporting software, and infrastructure) on which the SaMD
runs, security monitoring can be the responsibility of mul-
tiple organizations (hereafter referred to as the responsible
organization).
We often become aware of a new vulnerability when the
original component manufacturer releases a patch if a patch
is available to mitigate this latest vulnerability, it needs to
be validated to ensure it does not cause a conflict with the
SaMD or its platform, supporting software, or infrastructure.
The manufacturer must perform this assessment to ensure
that safety and performance are not impacted. On the other
hand, installing patches could lead to other failures that
impact system functionality or performance, break security
controls, or cause interoperability issues.
Even if the maintenance of the platform, supporting
software, and infrastructure is the user’s responsibility, the
manufacturer should also perform security monitoring against
the defined intended operating use environment. Informing
the SaMD users of incompatible patches with the defined
platform and infrastructure is crucial.
Suppose a patch is unavailable or is incompatible with
the SaMD or the platform. In that case, the manufacturer
may need to introduce additional mitigations to ensure the
vulnerability resolved by the patch cannot be exploited. This
consideration also should be made if the patch does not
mitigate all discovered security issues. Mitigations could
include design changes or additional security controls, such as
temporarily limiting network access to specific IP addresses
or network ports, completely isolating the system from the
network, or implementing specific configuration changes, like
denying access to external users. Note that these mitigations
might impede certain functionality.
When design changes or mitigating controls are needed,
they can be made available on short notice for implementa-
tion by the responsible organization. Alternatively, if changes
are considered low-risk, they can be implemented at the next
scheduled maintenance window. In any case, the manu-
facturer should determine who needs to be provided with
Second Edition
77 Regulatory Affairs Professionals Society
of unknown provenance. Third parties typically provide these
details in a software bill of materials (SBOM). Tools that
can analyze an SBOM and compare it with vulnerability
databases are required to be able to do proper vulnerability
handling. The IMDRF document Principles and practices
for software bill of materials for medical device cybersecurity
provides further insights.24
All software is prone to vulnerabilities that could, for
example, be introduced by poor design, inadequate coding
practices, improper fault handling, or compiler-introduced
security issues, or which may even be inherent in hardware,
such as CPUs. Attackers may find vulnerabilities in the man-
ufacturer’s software as well as in any third-party software and
hardware used. The more commonly used the software is, the
more attractive it is to attackers, and therefore, it presents a
greater possibility that new vulnerabilities will be discovered.
A vulnerability does not in itself directly introduce a risk.
Only when the vulnerability can be exploited by a person
or by malicious software attacking the underlying system or
infrastructure, does it become a risk. Some vulnerabilities
remain undiscovered for many years for instance, CVE-
2020-1317, a serious vulnerability in the Windows Group
Policies, lingered in the Microsoft Windows operating system
since 2008 before it was discovered and publicly disclosed
on 9 June 2020.25 Once discovered, the probability that a
vulnerability will be exploited may remain low if the attack
is complex, especially if multiple vulnerabilities must be
exploited for a successful attack. However, when a successful
attack has been published and proof-of-concept code has
been made available, the probability increases significantly,
as the attacker’s required skill level is reduced to perform a
successful attack.
Threat actors capable of complex attacks aim to prevent
the discovery of their attacks and the vulnerabilities they
exploit, thereby hiding their malicious activities for as long as
possible. For the same reason, they might target less com-
monly used software or even target specific software from a
single vendor.
As thousands of security vulnerabilities are discovered
and reported every month, it is crucial to be aware of new
vulnerabilities promptly. Security monitoring should start
while a SaMD is still in development to remediate any
vulnerabilities as early as possible this monitoring should
continue throughout the SaMD’s total product lifecycle.
Security monitoring should also begin during the design
phase and continue during the operation of the SaMD’s
intended operational use environment (platform and infra-
structure), under the control of the manufacturer or user.
Security vulnerability analysis should be triggered at
specific intervals, such as weekly or monthly, based on factors
including the type of SaMD, its components, the supporting
platform and network infrastructure used, and the associated
risks. An analysis should also be triggered and expedited by
specific events or security issues the manufacturer becomes
aware of. These indicators might originate from sources such as:
• Complaints and security incidents
• Vulnerabilities and patches reported by suppliers of
components
• Security issues reported by tool vendors (e.g., compilers
and software development kits)
• New risks identified by other third parties (a coordi-
nated vulnerability disclosure, media outlets, the security
community, an information sharing and analysis center
[ISAC], a computer emergency response team [CERT],
national cyber security center, etc.)
• Vulnerabilities identified by running security test tools
(e.g., vulnerability scanning, pen testing, fuzz testing,
secure code analysis, and software bill of material analysis
tools)
• Attacks on the infrastructure
• New risks identified in internal components and similar
products and
• Changes in the threat landscape.
Security monitoring is a continuous process. Figure 7-2
shows an exemplary generic monitoring flow.
Although the SaMD manufacturer sets the requirements
for the intended operational use environment (platform,
supporting software, and infrastructure) on which the SaMD
runs, security monitoring can be the responsibility of mul-
tiple organizations (hereafter referred to as the responsible
organization).
We often become aware of a new vulnerability when the
original component manufacturer releases a patch if a patch
is available to mitigate this latest vulnerability, it needs to
be validated to ensure it does not cause a conflict with the
SaMD or its platform, supporting software, or infrastructure.
The manufacturer must perform this assessment to ensure
that safety and performance are not impacted. On the other
hand, installing patches could lead to other failures that
impact system functionality or performance, break security
controls, or cause interoperability issues.
Even if the maintenance of the platform, supporting
software, and infrastructure is the user’s responsibility, the
manufacturer should also perform security monitoring against
the defined intended operating use environment. Informing
the SaMD users of incompatible patches with the defined
platform and infrastructure is crucial.
Suppose a patch is unavailable or is incompatible with
the SaMD or the platform. In that case, the manufacturer
may need to introduce additional mitigations to ensure the
vulnerability resolved by the patch cannot be exploited. This
consideration also should be made if the patch does not
mitigate all discovered security issues. Mitigations could
include design changes or additional security controls, such as
temporarily limiting network access to specific IP addresses
or network ports, completely isolating the system from the
network, or implementing specific configuration changes, like
denying access to external users. Note that these mitigations
might impede certain functionality.
When design changes or mitigating controls are needed,
they can be made available on short notice for implementa-
tion by the responsible organization. Alternatively, if changes
are considered low-risk, they can be implemented at the next
scheduled maintenance window. In any case, the manu-
facturer should determine who needs to be provided with