Cybersecurity terminology

Term	Description
CA	Certificate Authority. This is the organization which issues a certificate.
CEP	Component Environment Profile. This includes characteristics such as maximum impact of the component, whether the component is on the attack surface, whether there is data flow (and what data) to the component, etc.
CeQ	Our Cybersecurity-Enabled Quality System is a Medcrypt service offering.
CISA KEV	Cybersecurity & Infrastructure Security Agency Known Exploit Vulnerabilities
COTS	Commercial Off-the-Shelf Software. This is a software or hardware product that is commercially ready-made and can be bought, licensed, or rented by the general public. This is also referred to as Off-the-Shelf Software. See that definition in this table for more information.
CNA	CVE Numbering Authority, such as Microsoft.
CPE	Common Platform Enumeration. Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL. NIST defines CPE as a structured naming scheme for IT systems, software, and packages. It is based on the generic syntax for Uniform Resource Identifiers (URI) and includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name. The CPE specification was designed for operating systems, applications, and hardware devices. It is maintained by the NVD. CPE is recommended for use in identifying a client or server application, firmware, or operating system.
CQI	Continuous Quality Improvement
CSAF	Common Security Advisory Framework is a standard for machine-readable security advisories developed by the OASIS Open CSAF Technical Committee.
CSR	Certificate signing request
CycloneDX	This is derived from CycloneDX specification and use case information. CycloneDX is a machine-readable SBOM format that describes the following types of components: applications, containers, devices, libraries, files, firmware, frameworks, operating systems. It also describes services. Helm supports CycloneDX.
CWE	Component Weakness Enumeration
EPSS	Model that tries to predict how often a vulnerability could be exploited in the wild.
HDO	Health Delivery Organization, such as a group of physicians working together.
HSM	Hardware Security Module. An HSM is a special 'trusted' computer performing a variety of cryptographic operations such as key management, key exchange, encryption/decryption etc.
NTIA	National Telecommunications and Information Administration
OSS	Open-Source Software. The FDA wants to make sure that you know what components are COTS or OSS. OSS and SOUP are often incorrectly used interchangeably. If you have OSS components, you will need to provide documentation to the FDA that it is either being actively maintained, or if it not being actively maintained or is EOL, you’ll need to provide information on how you are mitigating any vulnerabilities with that component.
OTS	Off-the-Shelf Software. This information is derived from the FDA’s “Off-the-Shelf Software Use in Medical Devices” guidance. As the use of general-purpose computer hardware becomes more prevalent, OTS software is being used more often in medical devices. However, it may not be appropriate for a specific use in a medical device. As an MDM, you give up software lifecycle control with OTS, but are still responsible for your device to continue to operate safely and effectively. What do I need to document? This will differ depending on your medical device and the impact on the patient, operator, or bystander safety if the OTS software fails. You will need to do a risk analysis to determine the level of documentation detail you need to provide to the FDA and the level of lifecycle control you will need as the severity of harm from OTA software increases.
PKI	Public Key Infrastructure provides secure encrypted communications and mutual authentication between devices, services and users. Through the use of digital certificates every connected 'thing' can be bound, by the use of public keys, to entities such as people and organizations. The use of these certificates creates a chain of trust between the connected device and a certificate authority that issued the certificates. For PKI to work, you need a randomly generated cryptographic key pair to be generated for every single device manufactured. The key pair must be provisioned into the Root of Trust (RoT) of the microcontroller. The private key must be protected by the hardware RoT and the public part is held in a certificate, both of which are provisioned during manufacturing. The certificate will be signed by a certificate authority, thus providing a means of authentication for the identity. Thus, the identity is not a unique ID or a Universal Unique Identifier (UUID), but the way in which the device or other component is identified by a randomly generated key pair. The public part of the key pair is provided in the form of a certificate which has been signed (authenticated) by a trusted certificate authority. The private part of the key pair is used to prove the identity.
PURL	Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL. Package URL (PURL) standardizes how software package metadata is represented so that packages can universally be located regardless of what vendor, project, or ecosystem the packages belongs to. A PURL is an attempt to standardize existing approaches to reliably identify and locate software packages. It is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.
QMS	Quality Management System. This is a structured system that documents processes, procedures, and responsibilities for continuously delivering high-quality products and services that meet regulatory and customer requirements. Its objective is to provide a framework that improves communication, collaboration, and consistency across your company, while also reducing waste and promoting a culture of continuous improvement.
QSR	Quality System Regulations
RA	Registration Authority
RDP	Remote Desktop Protocol. Allows users to remotely connect to and control another computer or device.
RoT	Root of Trust
SBOM	Software Bill of Materials. This encompasses all components that exist across your software supply chain, including components, licenses, copyrights, and security references.
SMB	Server Message Block is Windows computers in file, port, and printer sharing and other network services. If these protocols are not properly secured, an attacker could potentially gain access to a network and cause significant damage.
SOUP	Software of Unknown (or Uncertain) Pedigree (or Provenance) is a term often used in the context of safety-critical and safety-involved systems such as medical software. SOUP is software that has not been developed with a known software development process or methodology, or which has unknown or no safety-related properties.
SPDX	Software Package Data Exchange. SPDX is an international open standard from Linux enabling communication of SBOM information, including provenance, license, security, and other related information. It provides a machine-readable SBOM, as well as a human-readable one enabling you to share important data about your software ecosystem and improve transparency and cybersecurity risk mitigation. SPDX is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021. Helm does not currently support SPDX, though it is currently in design.
SSVC	Stakeholder-Specific Vulnerability Categorization. This is derived from CISA’s Stakeholder-Specific Vulnerability Categorization document. This vulnerability analysis methodology accounts for a vulnerability’s exploitation status, impacts to safety, and prevalence of the affected product in a singular system. CISA uses its own SSVC decision tree to prioritize relevant vulnerabilities into four possible decisions: Track: Vulnerability does not require action at this time. Continue to track the vulnerability and reassess if new information becomes available. CISA recommends remediating these vulnerabilities within standard update timelines. Track*: Vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating these vulnerabilities within standard update timelines. Attend: Vulnerability requires attention from your internal supervisors, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities sooner than standard update timelines. Act: Vulnerability requires attention from internal supervisors and leaders, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities as soon as possible. These decisions are based on the following values: exploitation status, technical impact, automatable, mission prevalence, and public well-being impact.
SWID	Software ID (SWID) as defined in ISO/IEC 19770-2:2015 is used primarily to identify installed software. Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL Helm does not currently support SWID. SWID is recommended to be used for a container (as is PURL, which we do support), firmware (as is CPE, which we do support), library or framework (non-package), operating system (as is CPE), and operating system package (as is PURL).
TQM	Total Quality Management. This focuses on quality throughout your company, from design to customer satisfaction.
UUID	Universally Unique ID that is readable from most microcontrollers available today. This is not an identity, only an identifier. See PKI definition for more information.
V&V	Verification and Validation methods are used to ensure that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. V&V are critical to a quality management system (such as IO 9000).
VEX	Vulnerability Exploitability eXchange. This is the security advisory that a supplier will communicate regarding their analysis on a particular vulnerability as it relates to their software. Suppliers’ customers, such as hospitals, need to know whether this vulnerability is impacting the use of the device or not. Helm does not use VEX status conventions, but it is currently in design. A VEX provides additional information on whether a product is impacted by a specific vulnerability in a dependency. If so, recommends actions to remediate. For example, a vulnerability in an upstream dependency is likely not exploitable in the final product for reasons including the affected code not being loaded by the computer or inline protections existing elsewhere in the software. Dependency suppliers issue a VEX to assert the status of a vulnerability in specific products. These statuses are: Not affected: No remediation is required for this vulnerability Affected: Actions are recommended to remediate or address this vulnerability. Fixed: These product versions contain a fix for the vulnerability. Under investigation: It is not yet known whether these product versions are affected by this vulnerability. An update will be provided in a future release. VEXes are machine-readable, so users can integrate dependency data from SBOMs with vulnerability status information from VEXes to provide a current view of vulnerability status. This enables users to take a much more targeted approach to finding and remediating vulnerabilities in their software. A VEX can cover more than one vulnerability in a product or across multiple products. These are defined by CSAF, and can provide information such as remediation, workarounds, restart/downtime required, scores, and risks provided from vendors, system integrators, and operators.
VLCDB	Vulnerability Lifecycle Database

Term

Description

Certificate Authority. This is the organization which issues a certificate.

CEP

Component Environment Profile. This includes characteristics such as maximum impact of the component, whether the component is on the attack surface, whether there is data flow (and what data) to the component, etc.

CeQ

Our Cybersecurity-Enabled Quality System is a Medcrypt service offering.

CISA KEV

Cybersecurity & Infrastructure Security Agency Known Exploit Vulnerabilities

COTS

Commercial Off-the-Shelf Software. This is a software or hardware product that is commercially ready-made and can be bought, licensed, or rented by the general public. This is also referred to as Off-the-Shelf Software. See that definition in this table for more information.

CNA

CVE Numbering Authority, such as Microsoft.

CPE

Common Platform Enumeration.

Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL.

NIST defines CPE as a structured naming scheme for IT systems, software, and packages. It is based on the generic syntax for Uniform Resource Identifiers (URI) and includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name. The CPE specification was designed for operating systems, applications, and hardware devices. It is maintained by the NVD.

CPE is recommended for use in identifying a client or server application, firmware, or operating system.

CQI

Continuous Quality Improvement

CSAF

Common Security Advisory Framework is a standard for machine-readable security advisories developed by the OASIS Open CSAF Technical Committee.

CSR

Certificate signing request

CycloneDX

This is derived from CycloneDX specification and use case information.

CycloneDX is a machine-readable SBOM format that describes the following types of components: applications, containers, devices, libraries, files, firmware, frameworks, operating systems. It also describes services. Helm supports CycloneDX.

CWE

Component Weakness Enumeration

EPSS

Model that tries to predict how often a vulnerability could be exploited in the wild.

HDO

Health Delivery Organization, such as a group of physicians working together.

HSM

Hardware Security Module. An HSM is a special 'trusted' computer performing a variety of cryptographic operations such as key management, key exchange, encryption/decryption etc.

NTIA

National Telecommunications and Information Administration

OSS

Open-Source Software. The FDA wants to make sure that you know what components are COTS or OSS. OSS and SOUP are often incorrectly used interchangeably. If you have OSS components, you will need to provide documentation to the FDA that it is either being actively maintained, or if it not being actively maintained or is EOL, you’ll need to provide information on how you are mitigating any vulnerabilities with that component.

OTS

Off-the-Shelf Software.

This information is derived from the FDA’s “Off-the-Shelf Software Use in Medical Devices” guidance.

As the use of general-purpose computer hardware becomes more prevalent, OTS software is being used more often in medical devices. However, it may not be appropriate for a specific use in a medical device. As an MDM, you give up software lifecycle control with OTS, but are still responsible for your device to continue to operate safely and effectively.

What do I need to document?

This will differ depending on your medical device and the impact on the patient, operator, or bystander safety if the OTS software fails. You will need to do a risk analysis to determine the level of documentation detail you need to provide to the FDA and the level of lifecycle control you will need as the severity of harm from OTA software increases.

PKI

Public Key Infrastructure provides secure encrypted communications and mutual authentication between devices, services and users. Through the use of digital certificates every connected 'thing' can be bound, by the use of public keys, to entities such as people and organizations. The use of these certificates creates a chain of trust between the connected device and a certificate authority that issued the certificates.

For PKI to work, you need a randomly generated cryptographic key pair to be generated for every single device manufactured. The key pair must be provisioned into the Root of Trust (RoT) of the microcontroller. The private key must be protected by the hardware RoT and the public part is held in a certificate, both of which are provisioned during manufacturing. The certificate will be signed by a certificate authority, thus providing a means of authentication for the identity.

Thus, the identity is not a unique ID or a Universal Unique Identifier (UUID), but the way in which the device or other component is identified by a randomly generated key pair. The public part of the key pair is provided in the form of a certificate which has been signed (authenticated) by a trusted certificate authority. The private part of the key pair is used to prove the identity.

PURL

Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL.

Package URL (PURL) standardizes how software package metadata is represented so that packages can universally be located regardless of what vendor, project, or ecosystem the packages belongs to. A PURL is an attempt to standardize existing approaches to reliably identify and locate software packages. It is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.

QMS

Quality Management System. This is a structured system that documents processes, procedures, and responsibilities for continuously delivering high-quality products and services that meet regulatory and customer requirements. Its objective is to provide a framework that improves communication, collaboration, and consistency across your company, while also reducing waste and promoting a culture of continuous improvement.

QSR

Quality System Regulations

Registration Authority

RDP

Remote Desktop Protocol. Allows users to remotely connect to and control another computer or device.

RoT

Root of Trust

SBOM

Software Bill of Materials. This encompasses all components that exist across your software supply chain, including components, licenses, copyrights, and security references.

SMB

Server Message Block is Windows computers in file, port, and printer sharing and other network services. If these protocols are not properly secured, an attacker could potentially gain access to a network and cause significant damage.

SOUP

Software of Unknown (or Uncertain) Pedigree (or Provenance) is a term often used in the context of safety-critical and safety-involved systems such as medical software. SOUP is software that has not been developed with a known software development process or methodology, or which has unknown or no safety-related properties.

SPDX

Software Package Data Exchange. SPDX is an international open standard from Linux enabling communication of SBOM information, including provenance, license, security, and other related information. It provides a machine-readable SBOM, as well as a human-readable one enabling you to share important data about your software ecosystem and improve transparency and cybersecurity risk mitigation.

SPDX is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.

Helm does not currently support SPDX, though it is currently in design.

SSVC

Stakeholder-Specific Vulnerability Categorization. This is derived from CISA’s Stakeholder-Specific Vulnerability Categorization document.

This vulnerability analysis methodology accounts for a vulnerability’s exploitation status, impacts to safety, and prevalence of the affected product in a singular system.

CISA uses its own SSVC decision tree to prioritize relevant vulnerabilities into four possible decisions:

Track: Vulnerability does not require action at this time. Continue to track the vulnerability and reassess if new information becomes available. CISA recommends remediating these vulnerabilities within standard update timelines.
Track*: Vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating these vulnerabilities within standard update timelines.
Attend: Vulnerability requires attention from your internal supervisors, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities sooner than standard update timelines.
Act: Vulnerability requires attention from internal supervisors and leaders, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities as soon as possible.

These decisions are based on the following values: exploitation status, technical impact, automatable, mission prevalence, and public well-being impact.

SWID

Software ID (SWID) as defined in ISO/IEC 19770-2:2015 is used primarily to identify installed software.

Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL Helm does not currently support SWID.

SWID is recommended to be used for a container (as is PURL, which we do support), firmware (as is CPE, which we do support), library or framework (non-package), operating system (as is CPE), and operating system package (as is PURL).

TQM

Total Quality Management. This focuses on quality throughout your company, from design to customer satisfaction.

UUID

Universally Unique ID that is readable from most microcontrollers available today. This is not an identity, only an identifier. See PKI definition for more information.

V&V

Verification and Validation methods are used to ensure that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. V&V are critical to a quality management system (such as IO 9000).

VEX

Vulnerability Exploitability eXchange. This is the security advisory that a supplier will communicate regarding their analysis on a particular vulnerability as it relates to their software. Suppliers’ customers, such as hospitals, need to know whether this vulnerability is impacting the use of the device or not. Helm does not use VEX status conventions, but it is currently in design.

A VEX provides additional information on whether a product is impacted by a specific vulnerability in a dependency. If so, recommends actions to remediate. For example, a vulnerability in an upstream dependency is likely not exploitable in the final product for reasons including the affected code not being loaded by the computer or inline protections existing elsewhere in the software. Dependency suppliers issue a VEX to assert the status of a vulnerability in specific products. These statuses are:

Not affected: No remediation is required for this vulnerability
Affected: Actions are recommended to remediate or address this vulnerability.
Fixed: These product versions contain a fix for the vulnerability.
Under investigation: It is not yet known whether these product versions are affected by this vulnerability. An update will be provided in a future release.

VEXes are machine-readable, so users can integrate dependency data from SBOMs with vulnerability status information from VEXes to provide a current view of vulnerability status. This enables users to take a much more targeted approach to finding and remediating vulnerabilities in their software.

A VEX can cover more than one vulnerability in a product or across multiple products.

These are defined by CSAF, and can provide information such as remediation, workarounds, restart/downtime required, scores, and risks provided from vendors, system integrators, and operators.

VLCDB

Vulnerability Lifecycle Database

PreviousCybersecurity is everyone's responsibility NextAPI SDK feature preview

Last updated 11 months ago