Here at Medcrypt, we know you take your cybersecurity seriously, and so do we. When you create your account, you’ll automatically be enrolled in multi-factor authentication (MFA), also known as two-factor authentication (2FA). This means that you’ll need to provide a code from an authentication app. If you don’t already have an authentication application installed on your smartphone, you’ll need to choose one. We use Google Authenticator ourselves.

1. You’ll receive a welcome email, inviting you to sign in to your Helm account.

2. After signing in, you’ll be prompted to enable your MFA for security. At that time, you’ll be provided with recovery codes in case your phone is lost or stolen. Make sure to copy and paste these recovery codes into a safe place.

3. When you first sign in and until you’ve uploaded your first SBOM, you’ll see a get started modal, prompting you to choose a path. If you already are familiar with SBOMs and have a CycloneDX .json file, you should choose the top left path to upload your SBOM and get started. If you’re not, choose the path that best matches your current state.

If you accidentally closed that get started modal, don’t worry. You can always access it from the sidebar > Help section.

Ready to leverage the power of Helm to streamline your vulnerability management? Let's get you up and running!

1. Upload your Software Bill of Materials (SBOM) file:

   • Got an SBOM ready? Upload your SBOM file to Helm. We support CycloneDX and SPDX SBOMs.

   • Don’t have an SBOM yet? No worries! You can generate a CycloneDX SBOM or SPDX SBOM using our open-source tool suggestions or any other tool you prefer. You can also manually create your SBOM if that works better for you. If you’re unsure how to get started, we’re here to help—contact us so we can assist you.

2. Automatic matching to the NVD: Once you’ve uploaded your SBOM, our system will automatically attempt to match your components to the NVD (National Vulnerability Database).

   • Matched status with NVD badge: For each Matched status with an NVD badge, we have identified an exact match for your component in the NVD, allowing you to see vulnerabilities associated with that component.

   • Matched status with package manager badge: For each Matched status with a package manager badge, this indicates the component was matched to a specific package manager. If you don’t see an NVD badge, it means we couldn’t locate an exact match in the NVD, but your software does exist in the respective package manager. Refer to Match statuses for more details.

3. Resolve Select match status: For each Select match status, this indicates that we found multiple potential matches in the NVD. Click Resolve to review the match suggestions. Once you find the correct software, you can link it immediately. You must resolve this status by identifying an exact match in the NVD to see vulnerabilities for the component.

4. Resolve Not found status For each Not found status, this indicates we didn’t find a match in the NVD, meaning that there are no known vulnerabilities listed for that component using the name in your SBOM. You’ll need to resolve this status by identifying an exact match in the NVD to view the vulnerabilities. Remember that software can sometimes have a different name in the NVD.

5. Save time with reusable aliases: If you’re an Administrator, you can create an alias for a dependency to known software that you identify. This alias will save time and effort by ensuring consistent matching for future SBOM uploads.

6. Resolve Fix version status: For each Fix version status, this indicates that the version you provided does not match the expected version format. You'll need to resolve this status before you can view vulnerabilities for that component.

7. Contact Us status: If you see a Contact us status, this means we were unable to process the version. We are aware of the issue and will notify you once support has been added. At that point, we will automatically reprocess the affected component to attempt to find a match in the NVD.

8. Am I impacted by that vulnerability? Where? You can quickly check whether a particular vulnerability impacts your products, and if so, which products you'll need to focus on. Just enter the vulnerability ID in the global search bar at the top of any page.

9. Am I impacted by that vulnerable component? Where? You can quickly check whether your products contain a particular component, and if so, which products you'll need to assess. Just enter the component name in the global search bar at the top of any page.

10. Manage vulnerabilities: You can start managing vulnerabilities for any components that have a Matched status with an NVD badge.

11. Monitor your progress: You can track your progress on your Dashboard, accessible via the Home icon on the sidebar.

By having an SBOM that represents the current state of your product, you now have a catalog of all of your “ingredient lists”, creating visibility and transparency across your software security supply chain and ensuring that your software is updated and patched on a regular basis. You can then quickly identify any potential exploitable vulnerabilities you need to assess and mitigate.

What is an SBOM?

SBOMs are a critical component for operationalizing software supply chain security; they are key building blocks in your software supply chain cybersecurity programs. SBOMs act like a list of ingredients for the software that makes up applications. You may call these individual software “components” or “dependencies”. Helm enables you to provide transparency to your own company, your auditors, and even your customers, depending on your company policies, on your software supply chain, ensuring that stakeholders are aware of otherwise invisible dependencies on proprietary, open source and licensed, Commercial Off-the-Shelf (COTS) libraries.

Common elements of an SBOM include:

• Open-source libraries.

• Plug-ins, extensions, and add-ons

• Custom source code created in-house

• Information about versions, licensing status, and patch status of dependency components

• SaaS: Third-party services and API information required to run the SaaS application.

SBOMs are critical to secure your present and future

SBOMs are critical to realizing a better and more secure future for your company, your customers, and their patients. It is the latest step in the path to ensure that through making your software dependencies visible, you can then manage vulnerabilities of this software, ensuring that you are focusing on the highest-risk and most critical vulnerabilities first. Per the FDA, it’s no longer sufficient to rely on “security through obscurity”, as medical device manufacturers, you need to take responsibility and realize your pre-market and post-market liability for insecure software being used in your devices and systems, which are then passed down to customers and patients.

Recent cybersecurity attacks and changing economic conditions

Over the past few years, there have been a number of high-profile software supply chain attacks. Today’s connected devices rely on many software libraries, including home-grown, third-party, and open source projects. As a result of the pandemic, there have been a number of business-critical supply chain shortages, which have forced device and product manufacturers to expand outside their network of trusted suppliers, adding another layer of risk to the software supply chain. Here are a few of the more recent and most impactful attacks, although there are many more:

SolarWinds

In 2020, the SolarWinds attack on the software supply chain has a deep and lasting impact on the US governmental infrastructure and many companies across the US, Europe, Asia, and the Middle East, as IT networks were hacked by intruders over a months-long operation against SolarWinds, which supplied the hacked companies with a network monitoring and management platform. It cast a sobering spotlight on the extent to which medical device manufacturers know about the software that is used in their devices.

Log4Shell (Log4j)

In 2021, a critical remote-code execution vulnerability was discovered in the ubiquitous Apache Log4j open-source Java logging library. Its widespread usage combined with its ease of exploitation for even inexperienced hackers makes it especially dangerous, putting any Java applications with a user interface at risk of a Log4Shell attack. It made the risk inherent in using open source components in devices painfully clear. Systems and services that use the Log4j library include Twitter, Tesla, Apple, Minecraft, and many others.

WannaCry

In 2017, the WannaCry (also known as WannaCrypt) ransomware attack targeted computers running the Microsoft Windows operating system by using the EternalBlue exploit to encrypt data and the DoublePulsar tool to install and execute copied of itself, then demanding cryptocurrency payments to unencrypt the data. While Microsoft had released patches to close the exploit, many organizations had not applied these patches or were using older Windows operating systems that were past their end-of-life. According to Europol, WannaCry infected over 200K computers across 150 countries, impacting the National Health Service and a myriad of other companies.

Is my company impacted by Log4j or WannaCry?

You can easily check that once you’ve generated and uploaded your SBOM into Helm!

For Log4j, you can search for “log4j” in our global search to return all dependency components that are potentially impacted, or you can search on the vulnerability ID CVE-2021-44228. If you think you are impacted, refer to CISA's Log4j Vulnerability Guidance for more information.

For WannaCry, you can search for older Windows operating systems (e.g., Windows XP and upwards) to make sure that they have been patched. You can also search for associated vulnerability IDs: CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147, and CVE-2017-0148. If you think that you could be impacted, refer to CISA's WannaCry fact sheet for more information.

Meet government requirements

According to Gartner, by 2026, at least 60% of companies with mission-critical software solutions will mandate SBOM disclosures in their license and support agreements.

By having an SBOM that represents the current state of your product, you now have a catalog of all of your “ingredient lists”, creating visibility and transparency across your software security supply chain and ensuring that your software is updated and patched on a regular basis. You can then quickly identify any potential exploitable vulnerabilities you need to assess and mitigate.

Secure your company's present and future

SBOMs are critical to realizing a better and more secure future for your company, your customers, and their patients. It is the latest step in the path to ensure that through making your software dependencies visible, you can then manage vulnerabilities of this software, ensuring that you are focusing on the highest-risk and most critical vulnerabilities first. Per the FDA, it’s no longer sufficient to rely on “security through obscurity”, as medical device manufacturers, you need to take responsibility and realize your pre-market and post-market liability for insecure software being used in your devices and systems, which are then passed down to customers and patients.

The US government published Executive Order 14028 for Improving the Nation’s Cybersecurity in 2021, after which federal agencies were subsequently required to adopt NIST guidelines, including using SBOMs to conform with NIST secure software development practices.

Meet hospital requirements

Hospitals, the consumer of medical devices, are increasingly requesting a detailed SBOM as part of their Business Associate Agreements (ex. Mayo Clinic), with expectations including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, health systems like the Mayo Clinic will continue to reject supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.

Recent cybersecurity attacks and changing economic conditions

Over the past few years, there have been a number of high-profile software supply chain attacks. Today’s connected devices rely on many software libraries, including home-grown, third-party, and open source projects. As a result of the pandemic, there have been a number of business-critical supply chain shortages, which have forced device and product manufacturers to expand outside their network of trusted suppliers, adding another layer of risk to the software supply chain. Here are a few of the more recent and most impactful attacks, although there are many more:

SolarWinds

In 2020, the SolarWinds attack on the software supply chain has a deep and lasting impact on the US governmental infrastructure and many companies across the US, Europe, Asia, and the Middle East, as IT networks were hacked by intruders over a months-long operation against SolarWinds, which supplied the hacked companies with a network monitoring and management platform. It cast a sobering spotlight on the extent to which medical device manufacturers know about the software that is used in their devices.

Log4Shell (Log4j)

In 2021, a critical remote-code execution vulnerability was discovered in the ubiquitous Apache Log4j open-source Java logging library. Its widespread usage combined with its ease of exploitation for even inexperienced hackers makes it especially dangerous, putting any Java applications with a user interface at risk of a Log4Shell attack. It made the risk inherent in using open source components in devices painfully clear. Systems and services that use the Log4j library include Twitter, Tesla, Apple, Minecraft, and many others.

Meet government requirements

To further support this, the US government published Executive Order 14028 for Improving the Nation’s Cybersecurity in 2021, after which federal agencies were subsequently required to adopt NIST guidelines, including using SBOMs to conform with NIST secure software development practices.

Meet hospital requirements

Hospitals, the consumer of medical devices, are increasingly requesting a detailed SBOM as part of their Business Associate Agreements (ex. Mayo Clinic), with expectations including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, health systems like the Mayo Clinic will continue to reject supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.

What can I use SBOMs for?

You can use SBOMS to proactively understand and prevent or reduce risks, as well as to respond to incidents when they do occur.

By having an SBOM that represents the current state of your product, you can create a catalog of all of your “ingredient lists” to create visibility and transparency across your software security supply chain, as well as identifying any potential exploitable vulnerabilities you need to assess and mitigate.

Meet Mayo Clinic requirements

If you’re doing business with the Mayo Clinic, they often request a detailed SBOM as part of their Business Associate Agreements, including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, the Mayo Clinic will continue to reject for supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.

Pre-market dependency and vulnerability tracking

Per the FDA guidance in Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, manufacturers should be addressing cybersecurity during the design and development of their medical device, which often results in more robust and efficient mitigation of patient and operator risks. Medical device manufacturers also need to establish design inputs for their device related to cybersecurity, as well as establishing a cybersecurity vulnerability and management approach as part of the software validation and risk analysis required by 21 CFR 820.30(g). This approach should address the following:

• Identification of assets, threats, and vulnerabilities

• Assessment of the impact of threats and vulnerabilities on device functionality and operators/patients

• Assessment of the likelihood of a threat and of a vulnerability being exploited

• Determination of risk levels and suitable mitigation strategies

• Assessment of residual risk and risk acceptance criteria.

Medical devices that can connect (wirelessly or hard-wired) to another device, to the internet, to another network, or to portable media (e.g., USB or CD) are more vulnerable to cybersecurity threats than devices that are not connected. The extent to which security controls are needed depends on the device’s intended use, the presence and intent of its electronic data interfaces, its intended environment of use, the type of cybersecurity vulnerabilities present, the likelihood the vulnerability will be exploited, and the probable risk of patient harm due to a cybersecurity breach. To determine whether your device is considered a cyber device, refer to the What does the FDA classify as a cyber device? section.

Post-market dependency and vulnerability tracking

Per the FDA guidance in Postmarket Management of Cybersecurity in Medical Devices, due to constantly changing nature of cybersecurity risks to medical devices, manufacturers cannot completely mitigate risks through pre-market controls alone. Thus, it is critical that manufacturers implement comprehensive cybersecurity management programs and documentation consistent with the Quality System Regulation (21 CFR part 820), including complaint handling, quality audit, corrective and preventive action, software validation and risk analysis, and servicing.

Cybersecurity risk management programs should address vulnerabilities that will potentially allow the unauthorized access, modification, misuse or denial of use, or the unauthorized use of information stored, accessed, or transferred from a medical device which may result in patient harm. This program should include:

• Monitoring cybersecurity information sources for identifying and detecting cybersecurity vulnerabilities and risks.

• Maintaining robust software lifecycle processes, including mechanisms for:

  • monitoring third-party software components for new vulnerabilities throughout the device’s lifecycle

  • design verification and validation for software updates and patches that are used to remediate vulnerabilities, including for off-the-shelf software

• Understanding, assessing, and detecting the presence and impact of a vulnerability

• Establishing and communicating processes for vulnerability intake and handling.

• Using threat modeling to clearly define how to maintain safety and essential performance of a device by developing mitigations that protect, respond, and recover from cybersecurity risk

• Adopting a coordinated vulnerability disclosure policy and practice

• Deploying mitigations that address cybersecurity risk early and prior to exploitation.

Participation in an ISAO to share vulnerability and threat information

Per the FDA guidance in Postmarket Management of Cybersecurity in Medical Devices, it is strongly recommended that medical device manufacturers participate in an ISAO that shares vulnerabilities and threats that impact medical devices. Sharing and disseminating cybersecurity information and intelligence pertaining to vulnerabilities and threats across multiple sectors is integral to a successful post-market cybersecurity surveillance program.

In case you weren’t aware, Medcrypt owns an ISAO, MedISAO - we’d love to have you join us in sharing information!

Threat modeling

As part of your cybersecurity program, FDA post-market guidance states that manufacturers should define the safety and essential performance of their device, the potential for and severity of patient harm should the device be compromised, as well as the risk acceptance criteria, all of which will enable you to quickly triage vulnerabilities for remediation and mitigation. Threat modeling is critical to helping to you understand and assess the exploitability of a vulnerability, as well as ensuring that your vulnerability remediation can reasonably control the risk of patient harm. Acceptable mitigations will vary depending on the severity of the potential patient harm.

Handling a data breach

Having a complete SBOM is critical during a data breach, enabling you to quickly detect and analyze the impacted software and to understand the impact of the data breach and which other dependency components might be affected so that you can act quickly to limit the impact to your company, your customers, and their patients. It also helps you identify what critical areas you need to address and what to prioritize first in your cybersecurity plan.

Detect and analyze

SBOMs are very useful during the detection and analysis phase, providing visibility into what is in the software for context and details that inform the analysis. This drastically reduces wasted time spent gathering information from binary files, which is especially critical during a data breach.

Commit and recover

By shifting the process of providing transparency to your entire software supply chain to the left, you can get requisite information from your vendors and third parties to determine their impact in your device’s particular environment. This also enables you to proactively identify necessary patching and communicate that to your customers before exploits occur.

If your SBOM is complete and accurate, your incident response team can more easily understand how an application or API works, enabling them to put an attack in context. It can also help them track down repositories and which people are involved in the project, shortening response time. If your SBOM contains information about services, such as backend connections to databases, queues, APIs, and directories, they can use this to calculate the impact of a breach while it is occurring. They can also seek out impacted or affected components or dependencies in areas that they haven’t begun investigating yet, enabling them to more quickly ensure that they’ve eradicated a particular attack.

Post-incident response

After dealing with an exploit, you can use your SBOM in your post-mortem analysis to identify critical areas to address and what needs to be prioritized for the near and longer-term future.

You can upload .zst SBOM files generated by Yocto on Linux. If you still prefer to convert your .zst files to a zipped format, follow the steps below.

Generate your .zst file using Yocto on Linux

1. Inherit create-spdx class: Ensure that your Yocto configuration file inherits the create-spdx class by adding the following line:

   Copy

   INHERIT += "create-spdx"

2. Build the image: Proceed with building the image using the standard Yocto build process.

3. Locate the SBOM files: After the build process, you'll see three different outputs. All are provided here to guide you, but you must only use the third one (in bold). These items are copied directly from Yocto documentation.

• SPDX output in JSON format as in IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE in your build directory.

• This top-level file also has an IMAGE-MACHINE.spdx.index.json containing an index of SPDX files for individual recipes

• The compressed archive IMAGE-MACHINE.spdx.tar.zst, which contains the index and files for the single recipes.

Convert your .zst file to a zipped format (.tar.gz or .zip)

Please note this step is now optional, Helm natively supports the .zst file format.

1. Navigate to the directory that has the .zst file.

2. Run this command to unzip this file, which contains your individual SBOM files. Replace filename with your actual file name (in the bullets above from Yocto's docs, this is their IMAGE-MACHINE).

tar --zstd -xvf filename.zst

1. Create a directory with the name of what you want to name your zip file.

2. Navigate into that directory, then create the subdirectory, packages, in this directory.

3. Copy the individual SBOM files into this directory.

4. Run this command to zip the parent directory. In this example, we've used zst_sbom as the file name.

Create .tar.gz

COPYFILE_DISABLE=1 tar -zcvf zst_sbom.tar.gz zst_sbom -x 

Create .zip

zip -r zst_sbom.zip zst_sbom -x '**/.*'

When creating a .zip for Mac, use: -x '**/__MACOSX' in the command. This does not work for creating a .tar.gz.

1. Once you've converted the file to either .tar.gz or .zip, you can upload your SBOM to Helm.

You can easily integrate Helm into your CI/CD process to streamline and automate the process of creating product versions and uploading SBOMs to Helm. You can either use our GitHub action independently or integrate it into your existing GitHub action workflow, enabling you to maintain comprehensive and up-to-date documentation of your product's components, dependencies, and vulnerabilities with minimal effort.

Save time and effort manually maintaining SBOMs

Once configured, Helm will automatically add or update SBOMs for the appropriate product versions based on your event trigger when new or updated SBOMs are added to your connected GitHub repository.

• Efficiency: Automates the labor-intensive process of maintaining SBOMs, freeing up your team to focus on development.

• Accuracy and consistency: Ensures that every change in your codebase is reflected in your SBOMs.

• Integration: Fits naturally into your existing GitHub workflows, enhancing your DevOps practices without disrupting them.

• Compliance and transparency: Facilitates compliance with regulatory requirements and enhances transparency with stakeholders by providing detailed and up-to-date SBOMs.

Automate SBOM upload from GitHub repository

Our GitHub Action simplifies the management of SBOMs by automating the creation and uploading of product versions and their corresponding SBOM files from your GitHub repository.

1. To get started, you'll need Helm API access and the API credentials, as well as our Helm API URL (api-base-url).

2. In your GitHub repository, create a /workflows directory: .github/workflows

3. Create a new workflow .yml file under .github/workflows/ if you don’t already have one. If you already have one, just incorporate our step under jobs: > steps.

4. Create a step to upload your SBOM in the jobs section.

5. In the step, you can refer to the parameters in the table below or to the Readme for each of the parameters you'll need to add.

6. Provide the product-name and product-version-name.

7. If the product and version don't exist and you want us to create it for you, set create-product-and-version-if-missing to true.

8. Pass in your client-id and client-secret. These are your Helm API credentials. client-id is your email address (for the user that generated the API key) and client-secret is that user's API key.

9. Provide your sbom-file-path.

10. In our action, we currently set on to workflow_dispatch, which enables you to run it manually from the GitHub UI, but you can set it to whatever trigger you want, such as push, pull_request, or to run on a schedule.

Parameters to include in the YAML file

In the uses: parameter, this is set to /medcrypt/action-helm-sbom-upload@your_version_branch

In the with: parameter, specify the following information:

Ingest SBOMS for multiple products from same repository

Wrap our action up in your own workflow file, then write a reusable workflow using on: workflow_call to call your workflow.

Ingest SBOMS for different products from different repositories

Just copy and paste the step into that repo's yml file. If desired, you can create your own reusable action to store client-id and client-secret, anything that will be the same across your organization.

What happens if there is an error during SBOM upload?

If there is an error, you can check the action to see where errors occurred.

What if I accidentally add the wrong product or version?

What if I need to change the configuration or disconnect a repository?

You can stop using this or modify your action settings at any time, including changing or disconnecting repositories, changing event triggers, and more.

Navigation

Top navigation bar

In the top navigation bar, you can access your profile, as well as sign out of Helm. You can also search within your vulnerabilities or your SBOMs, as detailed below.

Sidebar

You can access any main page in the sidebar, including Products (SBOMs), Vulnerabilities, Global search discovery, Help, and Admin. If you need help getting started at any time, click Help for some paths to get you started, whether you have an SBOM yet or not.

Filter

Product/version selection bar

You can , specifying the product and version that you want to associate this SBOM with. You can then switch between SBOMs by selecting the appropriate product and version you want to work with.

Filter bar

You can or your to quickly drill down to exactly the information you need.

Search

From any page in Helm, you can s (Vuln ID) or on (SBOM) in the global search box in the top navigation bar.

Themes

Choose between our dark or light theme. To switch themes, click the sun/moon icon in the main navigation bar.

Tables

Customizable data display

Take control of how you view and interact with data. You can adjust table column visibility, perform multi-sorts, and choose your preferred display density.

• Content refresh setting: Take charge of your data updates by setting auto-refresh intervals or turning it off entirely. You can also refresh manually refresh.

• Pagination: Navigate large datasets with ease using our new pagination feature, ensuring you don’t lose your place.

• Customizable columns: Tailor your tables to display exactly what you need. Use the Columns link to show or hide specific columns and hover over column headers to drag and drop them into your preferred order with the … icon.

• Multi-column sorting: Focus on what’s important by applying complex sorts across multiple columns. Access this feature through the Sort fields link at the top of each table.

• Flexible display density: Optimize your view by selecting a compact or expanded display mode and adjusting the number of rows per page to suit your preferences.

• Advanced date picker: Gain precise control over date filtering with options for absolute/relative dates, custom ranges, and multi-month views.

Where did my columns go?

If you don't see your columns, that just means that they are currently hidden by default. Click the Columns link in the top of the table to show which columns are available, then toggle on/off columns to display only the ones you need. For example, if you need CVSS v2 scores, just toggle on this column.

Contextual actions

Easily access additional information or perform actions directly from tables by clicking on cell values.

Help

Get started

Click the path that best describes your needs to get started quickly.

Documentation

About

Click Help > About in the sidebar to view version information.

Contact us

We are always here to help get you unstuck!

Our SBOM vulnerability management product integrates data from multiple sources to ensure you have the most comprehensive and up-to-date information, including frequency of updates. By integrating these sources, our SBOM vulnerability management product ensures you are well-equipped to manage and mitigate risks effectively.

How often is data updated?

What data sources does Helm use?

Each vulnerability in Helm shows what data source or sources it was pulled from. Links are provided to the original CVE, as well as to exploitability and threat information.

National Vulnerability Database (NVD)

The National Vulnerability Database (NVD) is the world’s most comprehensive repository of publicly available vulnerability management data. Maintained by the National Institute of Standards and Technology (NIST), the NVD is built on the foundational work of MITRE and other leading cybersecurity entities. The database catalogs vulnerabilities identified as Common Vulnerabilities and Exposures (CVE), offering detailed information on over 100k documented CVEs, reaching back to the 1990s. The NVD not only provides vital intelligence on software flaws and misconfigurations but also includes crucial metadata such as severity scores, impact and exploitability metrics, and remediation steps, making it an indispensable resource for cybersecurity professionals.

You can easily see which vulnerabilities come from the NVD via the NVD badge indicator in the Source column.

AI co-pilot

In response to the NVD backlog, MedISAO, in collaboration with Medcrypt, has experimented with an AI copilot that leverages. This strategy aims to bridge the gap until NVD and CISA resolve their backlogs.

This system constructs CPE product and version match data to ensure rapid and continuous and continuous vulnerability enrichment.

This AI copilot pulls information from vulnerability databases like NVD, MITRE, and other external sources to stay up-to-date and continuously update vulnerability information.

AI copilot data sources and updates

This AI copilot pulls information from vulnerability databases like NVD, CISA, CVE.org, MITRE, and other external sources to stay up-to-date and continuously update vulnerability information.

CVE.org integration

We are currently adding CVE.org as a data source, and this support should be available in an upcoming release. CVE.org provides a list of publicly disclosed cybersecurity vulnerabilities, each assigned a unique CVE ID. With over 230,000 CVEs identified, defined, and catalogued, CVE.org partners with community members worldwide to grow CVE content. CVE.org has now been tasked with enriching CVEs in the NVD with CPE information to handle the backlog.

Support and integration

Supported by Helm, Medcrypt’s vulnerability management tool, this AI-driven approach uses historical data and a custom grammar parser to minimize inaccuracies and increase reliability. This AI copilot’s output mirrors the NVD data feed, allowing tools compatible with the NVD feed to seamlessly utilize enriched data.

How often is the NVD data feed updated?

This feed is updated daily and is available to MedISAO members and partners. It has thus far analyzed thousands more vulnerabilities than the NVD or CISA and integrated into Medcrypt's Helm product, enabling more enhanced vulnerability identification.

CVE.org

Private vulnerability repository

You can add, track, remediate, and resolve private vulnerabilities from other sources such as penetration testing or threat modeling in Helm. These vulnerabilities are identified and reported privately by organizations and cybersecurity firms, and often include zero-day vulnerabilities and proprietary software issues.

The three primary use cases for private vulnerabilities are for organizations:

• Tracking vulnerabilities in internally-developed components, whether unique to one product or that spans multiple products across the organization

• Documenting security research on an issue before deciding whether to disclose it publicly

• Using unmanaged data sources to identify vulnerabilities, such as change logs, commit logs, issue trackers, and social media posts, among others.

Exploit Database (ExploitDB)

Any active exploit retrieved from this database will show either an ExploitDB badge or Metasploit badge, depending on whether it is just an active exploit or whether there is a Metasploit toolkit. Additionally, you can view the impact of each vulnerability, which shows all known exploits and threats and provides links to the original source details.

Exploit Prediction Scoring System (EPSS)

Helm provides EPSS scores for any vulnerabilities that have a CVSS v3 score, as only CVSS v3 vulnerabilities have been assessed using the EPSS methodology.

Top 25 CWE (Common Weakness Enumeration)

Any vulnerability that is considered a top 25 CWE threat will show a Top CWE badge in Helm. You can also view more impact information in the vulnerability details, as well as review original sources.

CISA Known Exploited Vulnerabilities (KEV)

For the benefit of the cybersecurity community and network defenders—and to help every organization better manage vulnerabilities and keep pace with threat activity—CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild. Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework.

Any vulnerability that is in the CISA KEV list will show a CISA KEV badge in Helm. You can also view more impact information in the vulnerability details, as well as review original sources.

Microsoft Knowledge Base (KB) catalog

Important updates provide significant benefits, such as improved security and reliability. Optional updates might include, for example, new or updated driver software for devices that you have added to your computer.

Any vulnerability that has a recommended patch update will show an available patch indicator. You will soon be able to view patch recommendations in the vulnerability details as well.

Tidelift

Tidelift also partners with open-source maintainers to implement industry-leading secure software development practices and commit to these practices so that organization can feel confident in the security of their open source components in their ecosystems both now and in the future.

Data source routing

Components often belong to one or more ecosystems. These ecosystems typically have one or more sources of truth that provide additional data about the components. For example, Maven Central and the NPM repository provide information about Java and Node components respectively.

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

Package URL (PURL)

Helm uses PURL in several ways:

• Match components to identify vulnerabilities

• Reduce false positives and false negatives

• Identify outdated components across ecosystems

Supported package manager ecosystems

When does a PURL match get made?

For any vulnerability that was matched using a package manager, it will show the corresponding package manager name in its badge. If a dependency component is matched with a package manager badge, but also has a NOT IN NVD badge this means that Helm has identified your software in the package manager, but that no vulnerabilities have been reported in the NVD.

What is PURL used for?

PURL is recommended for use in identifying a container, library or framework (package), or operating system package.

PURL syntax

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.

As mentioned above, we currently support the following PURL package managers: Cargo, NPM, NuGet, and PyPI.

PURL format

A PURL is composed of 7 components:

scheme:type/namespace/name@version?qualifiers#subpath

The definition for each component is:

• scheme: this is the URL scheme with the constant value of "pkg". One of the primary reason for this single scheme is to facilitate the future official registration of the "pkg" scheme for package URLs. Required.

• type: the package "type" or package "protocol" such as maven, npm, nuget, gem, pypi, etc. Required.

• namespace: some name prefix such as a Maven groupid, a Docker image owner, a GitHub user or organization. Optional and type-specific.

• name: the name of the package. Required.

• version: the version of the package. Optional.

• qualifiers: extra qualifying data for a package such as an OS, architecture, a distro, etc. Optional and type-specific.

• subpath: extra subpath within a package, relative to the package root. Optional.

Examples:

• pkg:pypi/django@1.11.1

• pkg:nuget/EnterpriseLibrary.Common@6.0.1304

• pkg:npm/foobar@12.3.1

Common Platform Enumeration (CPE)

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.

When does a CPE match get made?

For any vulnerability that was matched using a CPE match, it will show a CPE badge. If a dependency component is matched with a CPE badge, that means that it has at least one vulnerability that has been reported in the NVD. A CPE is only assigned to software when a vulnerability has been reported in the NVD.

CPE syntax

CPE follows this format: cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

• cpe_version: This is the version of the CPE definition. As of this writing, the latest CPE definition version is 2.3.

• part: This can be one of three values: a for Applications, h for Hardware, o for Operating systems. It is sometimes referred to as type.

• vendor: This identifies the person or organization that manufactured or created this dependency component.

• product: This is the name of the system/package/component.

• version: This is the version of the system/package/component.

• update: This shows any update or service pack information, also known as minor versions.

• edition: This describes the build of the system/package/component beyond version.

• sw_edition (2.3 only): This indicates the language of the system/package/component, such as en-us for US English.

• target_sw (2.3 only): This indicates the language of the system/package/component, such as en-us for US English.

• target_hw (2.3 only): This indicates the language of the system/package/component, such as en-us for US English.

• other (2.3 only): This indicates the language of the system/package/component, such as en-us for US English.

CPE string examples

Application: If the URI is cpe:/a:microsoft:office:2007:sp2:professional then the CPE string is: cpe:2.3:a:microsoft:office:2007:sp2:-:*:professional:*:*:*

Operating system: If the URI is cpe:/o:microsoft:windows_7:-:sp1:x64 then the CPE string is: cpe:2.3:o:microsoft:windows_7:-:sp1:-:*:*:*:x64:*

Hardware (not supported in an SBOM): If the URI is cpe:/h:3com:3c13612 then the CPE string is: cpe:2.3:h:3com:3c13612:-:*:*:*:*:*:*:*

What does a wildcard in a CPE string indicate? Anything that is a wildcard (*) means that no particular value was provided for that section, so it will encompass any applicable value in that section.

What is Helm?

Helm is a comprehensive (SBOM) and vulnerability management tool designed to give you full visibility over your software supply chain and help you manage cybersecurity risks effectively. Helm is designed especially for medical device manufacturers (MDM) to effectively identify and remediate medical device risk, which often have long lifespans and infrequent updates. It enables you to track multiple software versions across devices, ensuring compliance with FDA cybersecurity guidelines. about how Helm helps you meet FDA cybersecurity expectations.

Specifically designed to address FDA cybersecurity guidelines

Helm provides a host of features specifically designed to address the cybersecurity guidelines of the FDA:

1. Vulnerability management: Helm helps MDMs implement robust plans for addressing post-market vulnerabilities. With its proactive approach, Helm identifies and manages potential risks before they pose significant threats. In the event of a major vulnerability like Log4j or Wannacry, Helm can determine which devices could be impacted within seconds.

2. Software Bill of Materials (SBOM): Helm supports SBOMs from open source software (OSS), commercial software composition analysis (SCA) tools, and even manually created SBOMs. All SBOMs are organized in an intuitive UI to ensure full transparency about all components used in your medical device software, in compliance with FDA guidelines.

3. Industry specific frameworks: MedCrypt has developed a Cybersecurity Quality tool that provides an easy to follow template and model implementation of a Secure Product Development Framework (SPDF).

4. Broad software, firmware, and OS awareness: Helm provides visibility into both open source software (OSS) and commercial third party software. It supports tracking operating systems (OS), including real-time operating systems (RTOS), ensuring you have a comprehensive view of your software ecosystem.

5. Compliant SBOM maintenance: With Helm, you can be assured that your SBOMs meet both NTIA minimum requirements and the FDA’s cybersecurity requirements for human- and machine-readable formats.

Get started with Helm

How do we identify matches in your SBOM to known software in the NVD?

In order to match the software in your SBOM to known software in the NVD, we normalize values (e.g, “windows10”, “windows_10”, and “win 10” will all be converted to the official value, such as Windows 10). If you see a status of Matched, that means that the dependency has an exact match in the NVD (once we have normalized values), including having an exact match on a CPE string, alias, dependency component name, or supported PURL package manager.

What matching sources do we use?

Understand your current vulnerability risk

Monitoring new vulnerabilities

Helm facilitates continuous monitoring for new vulnerabilities, highlighting those with available exploits or malware kits. It also suggests Windows KB updates for resolution (specific to Windows operating systems) and provides updates from the National Vulnerability Database (NVD).

Rescore vulnerabilities individually or in bulk

Monitor your overall security posture

Stay on top of new vulnerabilities

Search vulnerabilities and dependency components across your products

Search vulnerabilities for a particular CVSS score range across your products

Patch Windows operating systems

For any products you have that are running a Windows operating system, you can apply Windows KBs to each of your product versions. For any vulnerabilities associated with a Windows operating system, you'll see suggested KB updates that you can apply to resolve each vulnerability. Alternately, you can collect the KB updates to create tickets for your team to address for your next release. You can also track which KBs have been applied to your digital version of your physical test device, so you can keep these in sync.

Manage licenses

Helm supports the ingestion of licensing information from CycloneDX and SPDX SBOMs, and enriches this information via our partnership integration with Tidelift. You can also manually enter or modify license details as needed. For each dependency component, you can view its details or manually modify it to add licensing information. All licensing information displays in the License details section of the dependency component details panel.

Export FDA-ready reports

Export vulnerabilities

You can use many different open-source tools to generate your SBOM in CycloneDX format. We support CycloneDX 1.4 and JSON and XML formats.

Note: We have not used all of these, so have appended an * to the ones we've used or have seen our clients use successfully.

Java *

Core

Generate an SBOM for Java Core projects with the CycloneDX Java Core plugin.

Maven

Generate an SBOM for Java Maven projects with the CycloneDX Maven plugin.

Gradle *

Generate an SBOM for Java Gradle projects with th CycloneDX Gradle plugin or Gradle's own CycloneDX plugin.

JavaScript *

Generate an SBOM for JavaScript projects with the CycloneDX JavaScript library.

Node.js

NPM *

• Generate an SBOM for Node.js NPM projects with the CycloneDX Node module.

• Generate an SBOM for Node.js NPM projects with the CycloneDX-npm tool.

Yarn

Generate an SBOM for Node.js Yarn projects with the CycloneDX Node module.

Objective-C/Swift

CocoaPods *

Generate SBOM for CocoaPods projects with the CycloneDX Cocoapod plugin.

.NET

NuGet *

Generate SBOM for .NET NuGet projects with the CycloneDX .NET module.

Python *

Generate SBOM for Python projects with the GitHub Python SBOM generation tool.

Pip

Generate SBOM for Python Pip projects with the CycloneDX Python SBOM generation tool.

Poetry

Generate SBOM for Python Poetry projects with the CycloneDX Python SBOM generation tool.

PHP

Composer

Generate SBOM for PHP Composer projects with the CycloneDX PHP Composer plugin.

Go

Gomod

Generate SBOM for Golang projects with gomod using the CycloneDX-gomod tool.

Elixir

Mix *

Generate SBOM for Elixir Mix projects using the CycloneDX SBOM generation Mix task

Erlang

Rebar3

Generate SBOM for Erlang Rebar3 projects with the CycloneDX Rebar3 SBOM generation tool.

Multi-Language

• Microsoft's SBOM generation tool (microsoft.sbom.tool) apparently can detect NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, Linux packages within containers, Gradle, Ivy, GitHub public repos, and more. It uses Component Detection to generate your SBOM.

• Generate SBOM using Syft's CLI tool and Go library.

Linux kernel source code

• Download Microsoft's SBOM tool the tool to your local environment, then give execute permission to the downloaded executable file:

  chmod +x ./sbom-tool

• Download, then extract the Linux kernel source code from The Linux Kernel Archives. For example, this uses version 5.15.88:

  tar xvfJ linux-5.15.88.tar.xz

• Run the SBOM generation tool:

  ./sbom-tool generate -b ./linux-5.15.88 -bc ./linux-5.15.88 -pn kernel -pv 5.15.88 -ps linux.org -nsb https://kernel.org

• Locate the generated SPDX file in ./linux-5.15.88/_manifest/spdx_2.2/ folder. It is named manifest.spdx.json. You will now need to convert the SPDX file to CycloneDX.

Ruby *

Generate SBOM for Ruby projects with the CycloneDX-ruby gem.

More tools

• CycloneDX SBOM Standard GitHub repositories *

• SBOM Utility on GitHub

• License Scanner on GitHub

• CLI SBOM Extension on GitHub

• SBOM tool repository on GitHub

• CERTCC SwiftBOM generator and demo tool

• UI tool to generate SBOM

• CycloneDX Linux generator

• Syft SBOM generator

Use Medcrypt's SBOM generation tool

You can now use Medcrypt's SBOM generation tool! Contact us to get access.

Use an open-source SBOM generation tool

• Generate CycloneDX SBOM with open-source tools

• Generate SPDX SBOM with open-source tools

Other ways to create your SBOM

• Create SBOM manually

• Get expert Services help

You can use several different open-source tools to generate your SBOM in SPDX format. We support SPDX 2.2 and 2.3 with JSON format.

SPDX Software Bill of Materials (SBOM) generator

• spdx-sbom-generator tool enables generation of SPDX SBOMs with current package managers. It automatically determines which package managers or build systems are actually being used by your software dependency components.

• Works with Linux, Mac, and Windows.

• Comes with a Dockerfile for you to maintain your own image.

• has CLI (command-line interface) to generate SBOMs info, including dependency components, licenses, copyrights, and security references of your software supply chain using SPDX v2.2 spec and aligning with NTIA known minimum elements.

Yocto on Linux

Refer to Generate SBOM with Yocto on Linux.

Kubernetes SBOM tool

• bom is a utility to create, view, and transform your Software Bills of Materials (SBOMs). It can generate SPDX packages from directories, container images, single files, and other sources. It also has a built-in license classifier that recognizes over 400 licenses in the SPDX catalog.

• Supports Golang dependency analysis and full .gitignore support when scanning git repositories.

Multi-Language (Microsoft and Syft SBOM tools)

• Microsoft's SBOM generation tool (microsoft.sbom.tool) apparently can detect NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, Linux packages within containers, Gradle, Ivy, GitHub public repos, and more. It uses Component Detection to generate your SBOM.

• Generate your SBOM using Syft's CLI tool and Go library.

Generate your .zst file using Yocto on Linux

1. Inherit create-spdx class: Ensure that your Yocto configuration file inherits the create-spdx class by adding the following line:

   Copy

   INHERIT += "create-spdx"

2. Build the image: Proceed with building the image using the standard Yocto build process.

3. Locate the SBOM files: After the build process, you'll see three different outputs. All are provided here to guide you, but you must only use the third one (in bold). These items are copied directly from Yocto documentation.

• SPDX output in JSON format as in IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE in your build directory.

• This top-level file also has an IMAGE-MACHINE.spdx.index.json containing an index of SPDX files for individual recipes

• The compressed archive IMAGE-MACHINE.spdx.tar.zst, which contains the index and files for the single recipes.

Convert your .zst file to a zipped format (.tar.gz or .zip)

1. Navigate to the directory that has the .zst file.

2. Run this command to unzip this file, which contains your individual SBOM files. Replace filename with your actual file name (in the bullets above from Yocto's docs, this is their IMAGE-MACHINE).

tar --zstd -xvf filename.zst

1. Create a directory with the name of what you want to name your zip file.

2. Navigate into that directory, then create the subdirectory, packages, in this directory.

3. Copy the individual SBOM files into this directory.

4. Run this command to zip the parent directory. In this example, we've used zst_sbom as the file name.

Create .tar.gz

COPYFILE_DISABLE=1 tar -zcvf zst_sbom.tar.gz zst_sbom -x 

Create .zip

zip -r zst_sbom.zip zst_sbom -x '**/.*'

When creating a .zip for Mac, add: -x '**/__MACOSX' after the command. This does not work for creating a .tar.gz.

1. Once you've converted the file to either .tar.gz or .zip, you can upload your SBOM to Helm.

Create, edit, or merge SBOMs

You can add components to an existing SBOM or you can create an SBOM from scratch by adding each one manually. You can also merge SBOMs to combine all dependency components for multiple systems into one.

Create components (dependencies) manually

1. If you're just starting your SBOM, click the Add SBOM drop-down button > Add dependency. Note that if you've already created or uploaded any SBOMs, this button will change to Manage SBOM and will have additional options, including checking file status.

2. In the panel that displays, specify the product and version in the first section.

3. In the next section, provide any information you have for your component. The only required field is the name, so if you don't have information (e.g., version), you can always add this later. However, Helm will need the version to attempt to accurately identify the matching known software.

4. Click Add component. Helm will analyze your component for matches in supported package managers and the NVD, so this will take a few seconds. If you've provided a PURL or CPE, Helm will analyze our package managers and other data sources to ensure that you have the correct string. If not, Helm will automatically fix this for you. If you don't see your component display, you can refresh it. If Auto-refresh is on, we will automatically be updating this, but if you're not seeing anything, turn Auto-refresh off, then click the manual Refresh button.

Edit component

1. On the component you want to edit, click Actions ... > Manage component.

2. Click Edit on the section you would like to edit. Note that you cannot edit the Match details section.

3. If you edit the component details, then save your changes, you will be prompted to reload this component. Note that this will assess the component anew, which will lose any previous metadata, including matching, EOS/EOL, licensing, or review information that you have manually added.

4. If you edit the lifecycleIn the panel that displays, make any necessary changes, then save. This will automatically reload your component, which will no longer retain any review information you've already added for this dependency component. If you don't see your updated dependency component display, make sure Auto-refresh is on or click Refresh to manually update the page.

Merge another SBOM into your existing SBOM

To combine SBOMs from various systems into one SBOM, you can simply upload another SBOM to Helm. This will automatically merge that SBOM into your existing one, de-duping any dependency components that are on both SBOMs.

You can add dependency components to an existing SBOM or you can create an SBOM from scratch by adding each one manually. You can also merge SBOMs to combine all dependency components for multiple systems into one.

Create dependency components manually

1. If you're just starting your SBOM, click the Add SBOM drop-down button > Add dependency component. Note that if you've already created or uploaded any SBOMs, this button will change to Manage SBOM and will have additional options, including checking file status. This will display the Add dependency component modal.

2. In the panel that displays, specify the product and version in the first section. If you haven't created any products or product versions yet, click the create button in this drop-down. If you've already added products and versions, select the appropriate ones.

3. In the next section, provide any information you have for your dependency component. The only required field is the name, so if you don't have information (e.g., version), you can always add this later. However, Helm will need the version to attempt to accurately identify the matching known software.

4. Click Add dependency component. Helm will analyze your dependency component for matches in supported package managers and the NVD, so this will take a few seconds. If you've provided a PURL or CPE, Helm will analyze our package managers and other data sources to ensure that you have the correct string. If not, Helm will automatically fix this for you. If you don't see your dependency component display, try refreshing your browser.

Edit dependency component

1. On the dependency component you want to edit, click Actions ... > Manage dependency component.

2. In the panel that displays, make any necessary changes, then click Save changes. This will automatically reload your dependency component, which will no longer retain any review information you've already added for this dependency component. If you don't see your updated dependency component display, make sure Auto-refresh is on or click Refresh to manually update the page.

Merge another SBOM into your existing SBOM

To combine SBOMs from various systems into one SBOM, you can simply upload another SBOM to Helm. This will automatically merge that SBOM into your existing one, de-duping any dependency components that are on both SBOMs.

Helm provides many ways to ensure you have a comprehensive and accurate view of your overall risk that is tailored to your product's particular security posture, enabling you to spend your limited time on the vulnerabilities that matter most:

• Set rules to automatically update component Level of support and EOS/EOL information across all products, ensuring consistency

• Reload components to automatically add missing licenses (only for components that do not have any associated licensing information), ensuring you're not missing valuable license risk that could even impact your IP.

• Automatically rescore all vulnerabilities according to your product's security posture, ensuring you're focusing on the most exploitable vulnerabilities. Helm can also automatically update exploitability and fixability changes if you so choose.

• If we identify inaccurate CPEs or PURLs in your SBOM, Helm will attempt to provide an enriched CPE or PURL that matches to the correct software

• For components we're unable to match, you can create aliases to automatically match these to known software for future SBOMs.

• Use our Helm API to automate many tasks, such as creating product versions, uploading SBOMs, returning all vulnerabilities and generating reports, as well as returning only unmatched components or only CISA KEV vulnerabilities.

• Integrate our GitHub action your CI/CD process to automate product version creation and SBOM uploads

• Export your FDA-ready SBOM to ensure you have everything you need for FDA submission

Upload SBOM and match to known software

Prioritize and remediate risk

API & Administration

Ready to upload your first SBOM, or not sure what an SBOM is? We’re here to help! Helm supports both CycloneDX and SPDX SBOM formats, making it easy for you to manage your software components.

Upload a CycloneDX or SPDX SBOM

1. Click Add SBOM > Upload SBOM.

2. If you are uploading a compressed SPDX SBOM file, .

1. In the modal that displays, specify a product name and version.

2. Click the Choose file button to browse to your SBOM file.

3. Click Upload SBOM.

4. If you're not seeing your SBOM dependency components loading, check that you have Auto-refresh turned on, or manually refresh the page. Larger SBOMs will take a bit more time. If you're still not seeing your SBOM, click Manage SBOMs > View file upload status. If you see a Failed status here, click the icon next to that status for more information. If you can't resolve the issue, for help.

5. Once you’ve uploaded your SBOM, you will see all of the dependency components that are contained in that product display on the page. We’re already starting to match, drawing data from the NVD, including Package URLs (PURL) of Cargo, NPM, Nuget, or Pypi package manager), CPE strings, dependency component name/version/supplier combo, and alias matches.

6. If you need to aggregate and merge additional SBOMs to this SBOM, click Manage SBOMs > Upload SBOM. This will add dependency components from that SBOM to your existing SBOM.

7. If you see any warning or error icons next to your dependency component version, click the icon for more information. You should be able to just edit the version for a warning scenario, but will need to for an error scenario. You'll need to resolve this issue before we can match this dependency component and return any vulnerabilities.

Upload a compressed SPDX file

If you have a compressed SPDX SBOM file, follow these steps to upload it:

1. Prepare your files:

   • Create a directory named after what you want to name your zip file.

   • Navigate into that directory and create a subdirectory named packages in this directory.

   • Copy your individual SBOM files into the packages directory.

2. Compress your files:

   • Use the following commands to compress your files into a .tar.gz or .zip format:

     • Create .tar.gz: COPYFILE_DISABLE=1 tar -zcvf yourfilename.tar.gz yourdirectory

     • Create .zip: zip -r yourfilename.zip yourdirectory -x '**/.*'

3. Upload your file:

What happens after upload?

Create products and versions without an SBOM

1. In the Select product drop-down, choose Create product, specify the product name, then click Save.

2. In the Select version drop-down, choose Create version, specify the version, and click Save.

3. When you have an SBOM ready, just click the Add SBOM drop-down button (Manage SBOM if you already have uploaded other SBOMs), then select Upload SBOM when you’re ready to add your SBOM file.

Troubleshooting and support

You may have turned off auto-refresh. You can either turn it back on from the Auto-refresh switch above the table, or you can click Refresh to manually refresh the page.

No exact match

Upload issues

Have a large SBOM file?

If you have a larger SBOM file, this could take a little longer to upload. Get a cup of coffee or tea while we process your SBOM! We'll automatically start matching to known software in the NVD as soon as your upload is completed successfully.

Don't think your SBOM uploaded successfully?

SBOM contains component hashes

Although you can't currently view masked component hashes in Helm, rest assured that the component hash information in your SBOM has been retained and will be exported intact to any SBOM report.

Have a different SBOM format

Don't know what an SBOM is or not sure where to start

Ready to upload your first SBOM, or not sure what an SBOM is? We’re here to help! Helm supports both CycloneDX and SPDX SBOM formats, as well as manual SBOM creation, making it easy for you to manage your software dependency components.

Upload a CycloneDX or SPDX SBOM

1. Click Add SBOM > Upload SBOM.

1. In the modal that displays, specify a product name and version.

2. Click the Choose file button to browse to your SBOM file.

3. Click Upload SBOM.

5. Once you’ve uploaded your SBOM, you will see all of the dependency components that are contained in that product display on the page. We’re already starting to match, drawing data from the NVD, including Package URLs (PURL) of Cargo, NPM, Nuget, or Pypi package manager), CPE strings, dependency component name/version/supplier combo, and alias matches.

7. If you need to aggregate and merge additional SBOMs to this SBOM, click Manage SBOMs > Upload SBOM. This will add dependency components from that SBOM to your existing SBOM.

Upload a compressed SPDX file

If you have a compressed SPDX SBOM file, follow these steps to upload it:

1. Prepare your files:

   • Create a directory named after what you want to name your zip file.

   • Navigate into that directory and create a subdirectory named packages in this directory.

   • Copy your individual SBOM files into the packages directory.

2. Compress your files:

   • Use the following commands to compress your files into a .tar.gz or .zip format:

     • Create .tar.gz: COPYFILE_DISABLE=1 tar -zcvf yourfilename.tar.gz yourdirectory

     • Create .zip: zip -r yourfilename.zip yourdirectory -x '**/.*'

3. Upload your file:

What happens after upload?

Create products and versions without an SBOM

Not ready to upload your SBOM yet? No problem! You can create your products and their respective versions now and add your SBOM later.

1. In the Select product drop-down, choose Create product, specify the product name, then click Save.

2. In the Select version drop-down, choose Create version, specify the version, then click Save.

3. When you have an SBOM ready, just click the Add SBOM drop-down button, then select Upload SBOM.

Troubleshooting and support

Not seeing your SBOM dependency components?

You may have turned off auto-refresh. You can either turn it back on from the Auto-refresh switch above the table, or you can click Refresh to manually refresh the page.

No exact match

Upload issues

Have a large SBOM file?

If you have a larger SBOM file, this could take a little longer to upload. Get a cup of coffee or tea while we process your SBOM! We'll automatically start matching to known software in the NVD as soon as your upload is completed successfully.

Don't think your SBOM uploaded successfully?

Need help getting started?

Have a different SBOM format

Need to generate an SBOM

Don't know what an SBOM is or not sure where to start

Our expert Services team of former FDA reviewers and analysts can provide expert assessment, guidance, and design of anything from building cybersecurity and continuous improvement into your product development lifecycle to your Public Key Infrastructure cryptography to FDA letters and most anything in between. to see how we can help!

Helm provides many ways to ensure you have a comprehensive and accurate view of your overall risk that is tailored to your product's particular security posture, enabling you to spend your limited time on the vulnerabilities that matter most:

• to automatically update component Level of support and EOS/EOL information across all products, ensuring consistency and regulatory compliance.

• to automatically add missing licenses (only for components that do not have any associated licensing information), ensuring you're not missing valuable license risk that could even impact your IP.

• Automatically according to your product's security posture, ensuring you're focusing on the most exploitable vulnerabilities. Helm can also automatically update exploitability and fixability changes if you so choose.

• If we identify inaccurate CPEs or PURLs in your SBOM, Helm will attempt to provide an that matches to the correct software

• For components we're unable to match, you can to automatically match these to known software for future SBOMs.

• to automate many tasks, such as creating product versions, uploading SBOMs, returning all vulnerabilities and generating reports, as well as returning only unmatched components or only CISA KEV vulnerabilities.

• your CI/CD process to automate product version creation and SBOM uploads

• to ensure you have everything you need for FDA submission.

Add your SBOM

Before you've added your first SBOM for a product version, you'll see an Add SBOM drop-down button. If you've already added an SBOM, this will change to Manage SBOMs and will have additional options, including checking SBOM file upload status.

To access these options, click the Add SBOM or Manage SBOMs drop-down button:

• View upload status: This displays the SBOMs that have been uploaded for your products and versions. You can view the file name, file ID, when it was uploaded and by whom, the number of entries processed, and the status. If a file has uploaded successfully, you can see the number of dependency components processed from the SBOM. If a file has not uploaded successfully, you will see a red x icon next to the Failed to upload status. For these files, you will see an info icon to get more information on resolving the error.

Manage your SBOM

After or , you can manage your SBOM for each product and version in your software supply chain. Once you've uploaded your SBOM, Helm will match your software against the National Vulnerability Database (NVD), supported Package URLs (PURL) package managers, and CPE strings.

View dependency components in your SBOM

To view your SBOM, ensure you've selected a product and version so that you can .

In the Components table, you can quickly see where you need to complete matching, as well as understand exploitability risk and end-of-support/end-of-life risk, enabling you to prioritize upgrades. You can easily see what needs to be reviewed and catch up on reviews your team has made, as well as understand and manage license risk.

Click to drill-down for more information

Most things in Helm tables are clickable, enabling you to quickly drill down for more information, such as component details, match suggestions, fixing a version, contact us, reviewing a dependency component, and more.

Click the next step for each dependency component

For each dependency component, if there is a clear next step you need to take, that will be in the Actions column. If not, you'll just see the actions overflow ... button.

Dependency components columns

To view your SBOM, ensure you've selected a product and version so that you can see that version's dependency components.

• Name: This is what may be referred to as a component in other systems. It is the firmware, software, framework, library, file, or operating system that is installed on the physical representations of your device (e.g., Windows, OpenSSL).

• Version: This is the version for this dependency component name (e.g., 10.1 for Windows).

• Supplier: This is the organization that supplied the dependency component. The supplier may often be the manufacturer, but may also be a distributor or repackager (e.g., Microsoft for Windows).

• Level of support: Indicates whether the component is supported. Can be date or text value.

• EOS/EOL: Indicates whether the component has a known end-of-support or end-of-life date or other information. Like Level of support, this can also be a date or text value. If there is a date, this indicates that the component will no longer be supported or maintained after this time, thus it will potentially become more vulnerable and less reliable over time. You should either upgrade to a supported version or replace it with an alternate component to reduce risk.

• Review status: Indicates whether the dependency component has been reviewed or needs to be reviewed.

• Licenses: Displays the dependency component's licenses.

Manage dependency components

• Manage component: This will display all details for this dependency component in view mode. This will also show how Helm matched the dependency component, as well as any review information from your team. If you edit the dependency component, you'll be prompted to confirm this change. This is because Helm will reload the dependency component and rematch it, which will discard any review information you may have added.

• Add review note: Add a review note, then change the review status to Reviewed. You'll see this updated status in the Review status column, along with a note icon.

• Review history: This will show any analysis notes or review status changes your team has made. You can also add a review note from here.

• Reload component: If a dependency component is in an error state that is not caused by an inaccurate or unsupported version, you can reload it, but you should rarely, if ever, need to do this. This is a backup action in case you run into an error state. Helm will discard any previous information for the dependency component, and attempt to match it to known software.

• Delete component: If you have appropriate permissions, you can remove a particular dependency component. To avoid accidentally removing something that you wanted to keep, you’ll then be prompted to confirm this action.

Filter components

Click the Filters drop-down on the Components page to filter quickly to what you need.

• Component details: Search by component name or component review status

• Match details: Search by component match status

• License details: Search by SPDX license ID or custom license name

• Lifecycle details: Search for components with upcoming or expired end-of-support/end-of-life (EOS/EOL) dates, or search for components that will expire within a particular date range.

Recommended filters to reduce risk

Follow these steps to ensure you've completed your dependency component matching and identified all possible vulnerabilities across your SBOM.

Match status

The match status of each of your dependency components is indicated in the Match status column of the dependency components table. You can click directly on this status badge itself to begin the resolution process, or you can select an action from the Actions column.

1. To ensure that you complete matching, filter on Select match first. Helm has provided strong match suggestions for these, so you should be able to match these relatively quickly. Click Select match on any of these statuses to start matching.

2. For users with Admin role, we highly recommend that you create an alias for each dependency component you match. This will ensure that these are automatically matched for future SBOMs. If you're not sure whether to create an alias during the match, you (or your Admin) can always create one later.

3. If you want to complete matching, filter on Not found next. This indicates that Helm was unable to find an exact match in the NVD. Click the Not found badge to view the match suggestions Helm has identified. If you don't see the correct match, make sure you create an alias so that this will be automatically matched for future SBOMs.

Match source

Lifecycle details

Be confident that you're using actively maintained and supported components when building a new product or updating an existing one. Filter quickly on the support status of your components, as well as the timeframe for components that are nearing their end-of-support or end-of-life dates, enabling you to prioritize updates effectively, thereby ensuring the stability and security of your device throughout its lifecycle.

License details

Filter your dependency components by license, including those with specific licenses, no license, or unknown license status. This filtering capability helps quickly identify and mitigate license-related risks, such as copyleft licenses or unknown license statuses that may impact IP.

You can filter on GPL licenses and other restrictive licenses to quickly evaluate legal risk, enabling you to quickly prioritize updating or changing components that have licensing that could impact your IP and legal compliance. You can also filter on which components have at least one license, those that don't currently have any license information, as well as those that are specifically set to No license or NONE or Unknown or NOASSERTION (the values in caps are SPDX values), ensuring you understand your legal risk for every component in your product.

If you have an SBOM that is already in a CSV file, you have a few options that you can use to convert it to a CycloneDX file, including using an open-source tool, writing a custom script, or adding each dependency manually. If you run into issues or aren’t comfortable doing this, .

Use an open-source tool

The one that we’ve used is . You will have to install and run this locally, so if this is outside your realm of expertise, so we can get your SBOM converted.

1. Install CycloneDX-CLI.

2. Add these metadata columns shown in this into your CSV file: Supplier, Type, Name, Version. You may already have these columns. They are required in order for Helm to be able to successfully identify matches for your dependency components.

3. Add the metadata field to your CSV file. See the for more information.

4. Run the tool, using the “--output-format json” option. This will output the file as a JSON file format. For example, from your directory (ours is ./bin/linux-x64/cyclonedx), you would enter the following in the command line (in our example, we used source_sbom_cyclonedx.csv as our source CSV file, then destination_sbom_cyclonedx.json as the output JSON file that we were creating from the CSV file): convert --input-file source_sbom_cyclonedx.csv -–output-format json > destination_sbom_cyclonedx.json

Write a custom script

You can write a custom script in Python or your favorite language to convert the file from CSV to CycloneDX JSON.

You can view details about a dependency components, including its licenses, how it was matched, and any review information. In the Software Bill of Materials (Products) page, select Actions ... > Manage component to modify dependency component details.

Product details

• Product name: This is your product name.

• Product version: This is your product version.

Component details

• Name: This is the firmware, software, framework, library, file, or operating system that is installed on the physical representations of your device (e.g., Windows, OpenSSL).

• Version: This is the version for this dependency component name (e.g., 10.1 for Windows).

• Supplier: This is the organization that supplied the dependency component. The supplier may often be the manufacturer, but may also be a distributor or repackager (e.g., Microsoft for Windows).

• Original CPE: This is the original PURL assigned to this component in your SBOM file. Example format: (e.g., cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other)

• Enriched CPE: This is the PURL that was added or enriched from the respective package manager during the component matching process. This will only display if populated. You cannot edit this.

• Original PURL: This is the original CPE assigned to this component in your SBOM file. Example format: (e.g., scheme:type/namespace/name@version?qualifiers#subpath)

• Enriched PURL: This is the CPE that was added or enriched by our AI copilot during the component matching process. This will only display if populated. You cannot edit this.

Match details

This is how Helm matched or attempted to match your dependency component.

• Match status: This shows the current , as well as what were matched on.

• Vuln source: This is the source where we located this dependency component. This is currently always NVD. If it was not in the NVD, it will show a badge.

• Matched by:

  • System: Helm automatically matched this dependency component based on an exact match in the NVD, which could be from a CPE, PURL package manager, name/version/supplier, or alias.

  • User name: This user manually matched this dependency component to a suggested match or created a new alias to link it to known software.

Review details

This shows the last review added for this dependency component. You can also add your own review or view all review information.

• Review status: Shows whether the dependency component has been reviewed or needs to be reviewed. You can click this badge to set a new status.

• Last reviewed: Shows who last reviewed this dependency component and when.

• Last review: This is the last review note made on this dependency component to inform the team or progress, final status, or critical risk.

Edit component

1. On the component you want to edit, click Actions ... > Manage component.

2. Click Edit on the section you would like to edit. Note that you cannot edit the Match details section.

3. If you edit fields in the Component details section, then save your changes, you will be prompted to reload this component. Note that this will assess the component anew, which will lose any previous metadata, including matching, EOS/EOL, licensing, or review information that you have manually added.

4. f you don't see your updated dependency component display, make sure Auto-refresh is on or click Refresh to manually update the page.​​

Delete component

Click Actions > Remove (Delete) component. You will be prompted to confirm, as you cannot recover deleted components. This will only delete this component from this product version.

To keep track of various versions of your SBOM and to ensure that your SBOM is accurate for each product release to meet FDA requirements and protect your customers and their patients, you should create a new version of your SBOM whenever your team:

• Updates the device or application

• Adds or removes a dependency component or changes a dependency component version

• Adds one or more Windows KBs to a device version

• Adds a Windows KB to a vulnerability

• Upgrades the version of a dependency componen

This will help ensure your readiness for your pre-market FDA submission, while ensuring that customers post-market understand whether they are affected by vulnerabilities associated with a particular version of your product. Refer to for more information.

To ensure that changes you make to a component in one product version is persisted throughout your product portfolio, users with privileges can create specific rules for each component directly in the Rules manager, or can automatically create rules when updating the component details.

For each rule, you can set conditions around the supplier name, component name, and component version. You can then set effects that will be applied when all of the conditions are true to persist the specified Level of support and EOS/EOL (End-of-Support and End-of-Life) information across all of your products.

Add rule

1. If you haven't created any rules yet, you'll see a Create rule button. Click this to switch to the Edit rules mode to begin creating your rule. If you need to add more rules later, you'll need to be in this edit mode.

2. If you already have rules, click the Add another rule button to create a new rule at the top of the list. You can rearrange the rule's priority by dragging it lower in the list.

3. For each condition, make sure that the Enabled switch is turned on (is blue).

4. Set each condition by selecting the corresponding field and comparator, then specifying the expected matching value. As you add conditions, the rule name will be automatically updated in the following format, provided that particular condition is set: [Supplier name]/[Component name]/[Version]. For version ranges, the name will reflect the conditions specified in the following format: [Supplier name]/[Component name] [less than 10.1], such as Google Chrome less than 10.1. You cannot currently edit rule names. If this is important to you, !

5. Click Add version condition to add additional version conditions. Each condition uses the AND logic, so everything must be true in order to apply the effects. You can set the version as either an exact match or set conditions for a version range. For an exact match, set the version as is equal to. For version ranges, you can set the following conditions: is less than and/or is greater than. You can specify either a version exact match or up to two version conditions for a version range.

6. Set each effect below the conditions by selecting the corresponding field, comparator, then specifying the expected matching value. For Level of support and EOS/EOL (end-of-support and end-of-life) information, you can specify either is equal to date, then select a specific date, or set it as is equal to text, then provide the respective text value.

7. When you're finished adding rules, updating rules, and/or changing rule priority, click Save & apply. Note that unsaved changes will only persist during your Helm session, so make sure to save and apply anything you don't want to be discarded.

8. After you confirm these changes, Helm will begin applying them to your existing SBOMs, and will apply them to any future SBOMs.

Manage rule

1. Click the Edit rules toggle button to edit rules.

2. Make any modifications to conditions and/or effects.

3. To change rule priority, click the drag icon next to the rule name to drag it to a different position in the list. Rule priority is determined by the order of the rules in the Rules manager. If multiple rules impact a component, the one highest in the list takes precedence.

4. To delete a rule, click the Delete action. You will be prompted to confirm, but this deletion will not take effect before you click Save & apply. Deleted rules will be unapplied from existing SBOMs, and will no longer be applied to future SBOMs. You cannot recover a deleted rule. Note that if you decide to delete the only rule you have, any unsaved changes that you have made will be automatically applied and the rule will be deleted. In that case, you'll now see a blank rule, so that you can add more rules in the future.

5. When you're finished making changes, click Save & apply. Note that unsaved changes will only persist during your Helm session, so make sure to save and apply anything you don't want to be discarded.

6. After you confirm these changes, Helm will begin applying them to your existing SBOMs, and will apply them to any future SBOMs.

From any page in Helm, you can search on dependency components (SBOM) across all products using the global search box in the top navigation bar. For example, you may want to find all products that are running the Windows 10 operating system.

1. In the global search box on any page, select SBOM from the search drop-down. Alternately, you can go directly to the Discover page to run searches. Either way, your last search results will display on this page, if you need to return to them.

2. Type in a dependency component name, such as Windows 10, then press Enter to run the search.

3. From Actions > …, you can then jump to either viewing Products (SBOM) or Vulnerabilities.

View products and versions that contain a component

If you jump to this product, you’ll be able to see which product and product versions contain that dependency component and version. From the Actions > … button, you can choose to view more details, add a review note, view review history, and more.

View vulnerabilities for a dependency component

If you jump to vulnerabilities for this dependency component, you can view the applicable vulnerabilities. From the Actions > … button, you can manage each vulnerability, including adding review notes and setting the Resolution. If you change this resolution, it will update the Review status.

You may see the following match sources: NVD, Alias, Name, CPE, User, or one of our supported PURL package managers: PyPI, NPM, NuGet, and Cargo. If you’re in the Dependency details panel, you’ll see any of our supported package managers, NVD or NOT IN NVD, Alias, User, Exact, Name, CPE, and System. You can use these to gauge the strength of a match and your corresponding confidence in the match by the source.

• Alias: This displays if a user on your account created an alias for this software component/version/supplier combo. You can hover over the token for more information on whether the alias was created by a user in this session (Matched by user) or automatically matched by our system (Matched by system).

• Cargo: This was exactly matched to a component in the Cargo package manager from a Package URL (PURL) uploaded in your SBOM file.

• CPE: This was exactly matched to a component from a CPE string uploaded in your SBOM file. CPE is considered the strongest match.

• Name: This dependency name/version/supplier combo exactly matches an existing dependency name/version/supplier combo in our system.

• NuGet: This was exactly matched to a dependency in the NuGet package manager from a Package URL (PURL) uploaded in your SBOM file.

• NPM: This was exactly matched to a dependency in the NPM package manager from a Package URL (PURL) uploaded in your SBOM file.

• NVD: This dependency/version/supplier combo had an exact match in the National Vulnerability Database (NVD).

• PyPI: This was exactly matched to a dependency in the PyPI package manager from a Package URL (PURL) uploaded in your SBOM file.

• User: This was exactly matched by a user on this account to a possible match suggestion our system provided, or the user created an alias in this session. If the user created an alias in a previous session, that will be considered an automatic match, and will have a System token.

• System: This was exactly matched to an alias that was created by you or the Helm team.

Your dashboard provides an overview of your overall security posture. You can get to your dashboard by clicking the home icon on the sidebar.

Dashboard overview

This represents your total SBOMs and vulnerabilities across all time. The date range filter does not apply to these widgets.

Vulnerabilities over time

These widgets represent your vulnerabilities for a selected date range. You can view this over all versions within a product or for a particular product version.

Top 5 impacted products

Each donut chart represents the total number of vulnerabilities that have been detected in each of your products across all of their respective SBOM dependency components, within the selected date range, products, and versions, as well as the percentage of vulnerabilities in each level of severity.

You can view these widgets across all of your products and versions, or filter down to view particular products and versions.

Get more details:

Hover over the donut chart to display a View details button. Click that button to drill down into details for that product.

Add your first product:

1. If you haven’t added a product yet, you’ll see an Add new product button in this section.

2. Click this to specify the product name, then click Save.

3. To view your new product, click the Products option in the sidebar. Your new product will be selected in the products drop-down.

4. You’ll now need to add a version for this product. In the version drop-down, select Create version.

5. Specify the version, then click Save. Your new product version will be selected. You’re now ready to upload your SBOM.

Top 5 vulnerable dependencies

This shows your top 5 most vulnerable dependency components within the selected date range, products and versions.

The match status of each of your components is indicated in the Match status column of the components table. For most statuses, you can click directly on this status badge itself to begin the resolution process, or you can select an action from the Actions column. We use a variety of metadata and match sources to identify a match, including the NVD, CPE, alias, name, and supported package managers (Cargo, NPM, NuGet, PyPI).

Matched status

This status means the component has an exact match with software listed in the National Vulnerability Database (NVD). This means there was an exact match for your dependency component in the NVD, and that it has associated vulnerabilities, so you can start prioritizing and remediating these risks.

If the component has a correct CPE or PURL identifier but incorrect supplier information, our system will automatically correct it and create a match. If we're able to identify the PURL that exists for your component, but is missing in your SBOM, we'll automatically add that for you to ensure a unique match.

Matched to package manager

This status shows that a component is matched to a package manager but is not found in the NVD, thus it will not show any vulnerabilities. Note that sometimes package managers might use different names or PURLs than the NVD, so you should check the NVD to make sure your component isn’t listed under a different name. Refer to Resolve match statuses for more information.

Matched to CPE

If you see a component that has a Matched status with an NVD token and CPE token, that means that there this component has at least one vulnerability that has been reported in the NVD. A CPE is only assigned to software when a vulnerability has been reported in the NVD. Refer to Resolve match statuses for more information.

Select match

This status indicates that Helm has found multiple potential matches using identifiers like CPE, PURL, alias, or name. You can click the badge or the primary action link to review and assess the suggested matches. Refer to Resolve match statuses for more information.

Not found

This indicates that the component does that match any known software in the NVD or supported package managers will have this status. Refer to Resolve match statuses for more information.

Create an alias to link to known software

You can use aliases to match any dependency components in your SBOM that have multiple matches or are unmatched to known software components in the NVD. Administrators can create new aliases.

Other statuses

• Scanning: This is an interim status that indicates that Helm is processing this match. If you have been waiting and haven't seen this update, try refreshing the page.

• Fix version: The software version provided for this dependency component does not match the expected version. This issue should be rare. If you see this, you will also see a warning icon next to the version. Refer to Resolve match statuses for more information on resolving this issue.

• Contact us: Helm was unable to parse this version. We have logged this issue and will work to resolve it quickly. Refer to Resolve match statuses for more information on resolving this issue.

• Error: Some other error occurred while trying to parse this dependency component. Contact us for help in resolving this issue.

Automatic de-duplication

Helm checks CPE and PURL IDs to determine if a dependency component is unique. If a duplicate is detected, it will automatically be removed to streamline your SBOM management.

You can archive and unarchive products, as well as remove product versions.

Archive and unarchive a product:

1. In the Software Bill of Materials product drop-down list , hover over the product you want to archive, then click the trash icon. This will archive the product.

2. To unarchive a product, simply add the product again with the exact same name. This will automatically unarchive the product, its associated versions, and all dependency components. If you don't want to unarchive the product, add the product with a slightly different name.

Delete a product version:

1. In the Software Bill of Materials version drop-down list, hover over the version you want to delete, then click the trash icon. This will display a confirmation dialog. If you need to re-add the version and SBOM, just create the same version again.

You can assess the likelihood that this is the correct match by viewing the trend of reported vulnerabilities over time and the known versions for this match suggestion. Multiple matches that have a trend of reported vulnerabilities and that match your dependency’s versions (or at least version formats) are considered stronger matches.

Match details modal sections

You can determine the likelihood of this potential match by checking the sample versions for the expected format, checking how many and which sources were used to identify the suggested match, and the type of match. A match based on CPE is considered the strongest match.

If the match was suggested via multiple sources, such as Alias and a PURL package manager, that is an even stronger match. Alias and User matches indicate that a user manually assessed this dependency to find the right match. Name is considered the weakest match.

Match suggestions modal

You can use aliases to match any dependency components in your SBOM that have multiple matches or are unmatched to known software components in the NVD. These can be created by your Administrators.

View aliased matches

To view aliases, click the Aliases item in the sidebar. If you have appropriate , you will see an Aliases table with the original name of the dependency component in your SBOM, the linked (aliased) name of the known software in the NVD.

In the Software Bill of Materials (Products) page, you will see a Matched status with an ALIAS token in the Match status column for all aliased matches.

Create an alias

When resolving, , and other , users with an can create an alias for a dependency component in your SBOM to a particular software that exists in the NVD. If you're not an Administrator, but have identified a likely match, contact one of your administrators to have the alias created for you.

There are two ways you can create aliases: directly from the unmatched dependency component or from the Aliases page (detailed above).

To create an alias directly from the dependency component:

1. Navigate to the Software Bill of Materials (Products) page, then click Resolve in the Actions column. This will display the Resolution options modal.

2. Click the Create alias button to display the Create alias modal.

3. The scope is defaulted to Organization, which means that this alias you create for this dependency component will be linked in the future any time anyone else in your company uploads an SBOM that contains this dependency component. There isn’t another option for this currently.

4. Enter the Dependency name that you’re creating the alias link for, then click Next. You’ll then be prompted to enter the dependency name.

5. Enter all or part of your dependency name. Select the supplier/dependency combo that best matches your dependency, then click Create. You’ll be prompted to confirm this alias.

6. When you’re ready to confirm the alias, click Confirm. This will change any Not found or Select match statuses to Matched. Going forward, whenever you or anyone else in your organization uploads this dependency component in an SBOM, this alias will be applied.

Remove an alias

If you find that your team has added an incorrect alias, you can easily remove it if you are an Administrator.

2. Click the row that you want to remove to highlight it, then click Remove. You'll be prompted to confirm the removal.

Alias permissions

• Administrator: Users with an Administrator role can view and edit all products, as well as create aliases and use existing aliases to link software in their SBOMs to known software in the NVD.

• User with edit permissions for a product: Users who have edit permissions for a particular product, but are not Administrators, will be able to view and use existing aliases for that product to link software in their SBOM to known software in the NVD, but will not be able to create aliases unless they have an Administrator role.

• User with read-only permissions for a product: These users will be able to view aliases for that product, but will not be able to use these aliases to link software.

There are two ways to export your SBOM:

• Click the item in the sidebar, then click the corresponding export button on the report card.

• Click the Manage SBOM drop-down button, then click Export SBOM.

When downloading (exporting) your SBOM to share with others or for auditing purposes, you can either export your original SBOM or your enhanced SBOM (with matches our system made automatically or that your team matched). You can also choose to include vulnerabilities and any associated CPE or PURL information in your export. SBOMs are currently exported in CycloneDX 1.4 format. If you are interested in exporting in another format, .

Customize your SBOM export

• Export as file name: This is the filename that will be generated with your exported data.

• Export details: You can choose to export your original SBOM or your enriched SBOM. Your enriched SBOM can include vulnerabilities, enriched CPE and PURL information, and more.

• Export as file type: For your original SBOM, you can export in CycloneDX JSON, SPDX JSON or XML, and CSV. For your enriched SBOM, you can export in CycloneDX or SPDX JSON.

• Include vulnerabilities: Check this box to export all of the vulnerabilities associated with this SBOM. This will include the source name (currently always the NVD), a link to the vulnerability, both its v2 and v3 CVSS scores and vector strings, when the vulnerability was first detected, when it was updated, and more.

• Include enriched CPEs and PURLs from matching: Your original SBOM export will include all CPE/PURL information, but you can check this box to export all enriched CPE/PURL data, including those identified by Helm or during the matching and analysis process or that you manually matched or added.

SBOM contains component hashes

If your SBOM contained any component hashes when uploaded, that information was retained and will be exported intact to any SBOM report.

Helm supports the ingestion of licensing information from CycloneDX and SPDX SBOMs, and enriches this information via our partnership integration with Tidelift. You can also manually enter or modify license details as needed.

For each dependency component, you can view its details or manually modify it to add licensing information. All licensing information displays in the License details section of the dependency component details panel.

Supported SPDX licenses

• For active SPDX licenses, these will be automatically linked to the corresponding license URL from the .

• If you have deprecated SPDX licenses in your SBOM, Helm will retain the URL.

• Helm also handles .

Ingest licenses from CycloneDX SBOMs

Helm populates license information from the following sections in a CycloneDX SBOM:

• components > licenses: The primary source for license information. Each dependency component must include either a license ID, name, or SPDX expression.

• components > pedigree > notes: This will be populated into the License comments field. Because this notes field applies to all components in a CycloneDX SBOM, the information in this field will be applied to all licenses for a particular dependency component.

Helm does not support license information populated from other sections of a CycloneDX SBOM. Any such information will be retained in exports but ignored in the UI.

Ingest licenses from SPDX SBOMs

A SPDX SBOM contains packages, each of which could be a file or set of files, grouped by the SBOM author. These files could be one or more files of any type including but not limited to source, documents, binaries, etc. Helm processes each package as a dependency component. A SPDX SBOM can contain licensing information at the package, file, or even code snippet level. For every package that contains licensing, Helm populates that license information into the dependency component's details in the Licenses section.

Helm processes each package as a dependency component and populates license information from the following fields:

• PackageLicenseConcluded: The primary field for populating the license name. If missing, Helm will use the PackageLicenseDeclared field.

• ExtractedLicensingInfo: If present, this section provides license names and text for custom or non-SPDX licenses. When a custom license is added, you can manually enter the license name, but the URL will not display.

Identify and automatically add missing licenses

Helm has partnered with Tidelift to enrich license information for open-source components that lack licensing details:

• Component license is set to No license (NONE in SPDX): If a dependency component in your SBOM lacks a license but has a unique PURL or Helm can generate the correct PURL, Helm will check with Tidelift to determine if any licenses are associated with that component. If so, Helm will add those licenses to provide you with a comprehensive view of licensing info and identify licensing risks across your supply chain.

• Component license is set to Unknown (NOASSERTION in SPDX): If your SBOM component license is set to Unknown (NOASSERTION in SPDX), but Tidelift indicates that there is one or more licenses associated with that component, we will add those licenses for you.

Automatically generate a license for an existing component

For existing components, you can have Helm automatically add license information. In the Components table, click Actions > Reload component. Note that reloading will discard any metadata you may have added to this component, such as review information, and will re-identify associated vulnerabilities, so you may see some discrepancy in your number of vulnerabilities for that component. This reduces your manual effort of tracking down licensing information, ensuring you have the latest license information available from our data sources.

View license information

The Licenses section of the component details panel displays the following fields:

License type: This field is populated from the license information in your SBOM.

• License expression:

  • For components combining multiple SPDX licenses with AND or OR, or using a SPDX license exception.

  • Individual licenses: If your SBOM component contains multiple SPDX licenses that are not combined with AND or OR (or +) or if your component has custom licenses, choose this option.

  • No license (NONE in SPDX): If you are certain that your SBOM component does not have an associated license, choose this option. In a SPDX SBOM, this is indicated with the NONE value.

  • Unknown (NOASSERTION in SPDX): If you are not sure whether your SBOM has an associated license, choose this option. In a SPDX SBOM, this is indicated with the NOASSERTION value. In a CycloneDX SBOM, if your SBOM does not contain licensing information or licensing info is empty, it will display as Unknown

• Individual licenses: For components with multiple SPDX licenses not combined, or for custom licenses.

• No license (NONE in SPDX): The component has no associated license. In a SPDX SBOM, this is indicated with the NONE value.

  • CycloneDX SBOM: There is no corresponding value for this in CycloneDX 1.4 or 1.5 specs. If you manually add this for a license, then export your CycloneDX SBOM, the licensing information for this component will have this value in the components > licenses > license name field.

  • SPDX SBOM: Indicates that the SPDX SBOM author provided NONE as the package-level license information. The SPDX spec requires that when the info is not provided, it be set to NOASSERTION.

  • For open-source dependency components, Helm will attempt to identify if there actually is an associated license for you.

• Unknown (NOASSERTION in SPDX):

  • Use this if you are unsure whether the component has an associated license. For open-source dependency components, Helm will attempt to identify this license for you.

  • SPDX SBOM: Indicates that the SPDX SBOM author provided NOASSERTION or did not provide package-level license information.

  • CycloneDX SBOM: Indicates that the CycloneDX SBOM did not contain any licensing information or the licensing information was empty.

License name:

SPDX SBOMs

For SPDX SBOMs, this field is populated from the SBOM’s PackageLicenseConcluded, PackageLicenseDeclared, or ExtractedLicensingInfo sections. PackageLicenseDeclared will only be used if PackageLicenseConcluded field in the SBOM is blank or omitted.

• If the package-level licensing has a LicenseRef[idstring] and that LicenseRef[idstring] matches one in the ExtractedLicensingInfo section, the license name and full license text will be populated from that section into License name and License text, respectively. If the license name is missing, the term Custom license will be used as the license name.

• Non-SPDX license in your SPDX SBOM: If your SPDX SBOM contained the ExtractedLicensingInfo section, the License name field will be populated with the corresponding license name from ExtractedLicensingInfo > name field.

• SPDX SBOM has NONE or NOASSERTION in the package: If the PackageLicenseConcluded field contains NONE or NOASSERTION, that value will be populated here. If the component is open-source and has a unique PURL, then we will check whether there is license information for that component and if so, enrich it with the missing information.

• SPDX SBOM contains no package-level licensing information: NOASSERTION will be populated into the License name field.

• SPDX license exceptions: If you need to add a SPDX license exception, type WITH after your first SPDX license, such as GPL-2.0-or-later WITH Bison-exception-2.2. Make sure to observe spacing. After you type WITH, followed by a space, then you can either click the drop-down to view only valid SPDX license exceptions or start typing to filter the exceptions.

CycloneDX SBOMs

• This field is populated from the components > licenses > license > id field if the id field in used in the SBOM, or the components > licenses > license > name field if it exists.

• CycloneDX SBOM does not contain licensing info or licensing info is empty: Since there is no corresponding defined term for missing CycloneDX licensing information, this will show as Not set.

License URL:

• For SPDX licenses, this field is automatically populated from the SPDX license list and is uneditable.

• CycloneDX SBOM: This is populated from the components > licenses > license url field.

License text:

• SPDX SBOM: For custom licenses, this will be populated from the ExtractedLicensingInfo > text section of SPDX SBOMs.

• You can add or modify license text for both SPDX and custom licenses.

License comments:

• SPDX SBOM: This is only populated from the package-level PackageLicenseComment field.

• CycloneDX SBOM: There is at least one SPDX license ID in the components > pedigree > notes field. Some automatic scanning tools will automatically populate either the SPDX license full name or an AND/OR SPDX expression here. If the notes field exists in your SBOM file, it will be added as License comments for all of the licenses for that particular SBOM component.

• You can add or modify license comments for both SPDX and custom licenses.

• Comments are applied to all licenses associated with a dependency component.

License source:

• SBOM: The license information was populated directly from your SBOM.

• User: License was added or modified by a user.

Add component license

1. Click Add dependency component from the Add SBOM (Manage SBOMs) drop-down button.

2. Specify the required fields.

3. In the License details section, select a License type. Choose License expression if you have one or more SPDX licenses in an expression (e.g., connected with AND, OR, or WITH) or Individual licenses if you have one or more SPDX or custom licenses (not in an expression) that you want to add to a component. You can also select Unknown or No license.

5. If you want to add a nested expression, such as MIT AND (LGPL-2.1-or-later OR BSD-3-Clause), type ( to display the SPDX license list or start typing to filter the list. Note that the expression in the parentheses will be processed first.

6. If you want to add a SPDX license exception, type WITH after the license, then select the exception from the drop-down (e.g., GPL-2.0-or-later WITH Bison-exception-2.2). Make sure to observe spacing.

7. If you're adding one or more individual licenses, click the License name drop-down to show the SPDX license list, start typing to filter the list, or keep typing to enter a custom license.

8. If you need to clear a license value, click the x icon in the field.

9. If you need to remove a license before you've saved, click Remove in the license section.

10. For individual custom licenses, specify any license text. You cannot add text for a SPDX license.

11. Add any license comments in the License comments field. License comments will be associated with all licenses for that component.

12. For individual licenses, click Add another license to add a new license. You cannot add individual licenses to a License expression. You can add as many licenses as you want. Your first license will show License 1, then your second will show License 2. When you save, these section names will change to the license name or expression itself.

13. Click Add component. You'll see a success message. If you don't see your component, you may have a sort applied.

Edit component license

1. Click Actions > Edit details to open the component details.

2. In the License details section, click Edit in the license section you want to edit.

3. If you just want to edit license type, license text or license comments, click the edit icon next to that field. Any edits you make to the license comments will be applied to all other licenses for this component.

4. Make any changes, then click Save changes. You'll see a success message. If you don't see your component, you may have a sort applied.

Delete component license

1. Click Actions > Edit details to open the component details.

2. In the License details section, click Edit in the license section you want to edit. This will display a Delete action.

3. Click Delete, then confirm the deletion. You cannot recover a deleted license or its related data. If you are deleting the only license associated with this component, this will also delete any license comments.

4. Click Close. The deletion has already been performed and cannot be cancelled. You'll see a success message. If you don't see your component, you may have a sort applied.

Deprecated licenses:

You can ingest or manually add or edit deprecated SPDX licenses. Deprecated SPDX licenses are available in the Deprecated licenses section of the License type drop-down.

Filter component icenses

You can filter licenses on the SBOM page to narrow down your view:

• SPDX license ID

• No license (NONE for SPDX)

• Unknown (NOASSERTION for SPDX)

Export SBOM with license information

You can export your SBOM with enriched license information in the following formats. Click Reports in the sidebar, then select your preferred format.

• FDA SBOM: Excel format.

• Vulnerability Disclosure Report (VDR): JSON format. Missing license information will be noted as Unknown (NOASSERTION in SPDX) in the export.

• CycloneDX SBOM: JSON format. Missing license information will be noted as Unknown (NOASSERTION in SPDX) in the export.

• SPDX SBOM: JSON or XML format. Any file-level licensing details will also be included in the export, though they will not display in the Helm UI.

• CSV format: Export your SBOM data, including CPE/PURL and license information, as a CSV file.

After you’ve matched SBOM dependency components to software components in the NVD, which could be one or more , you’ll be able to see any reported vulnerabilities for those dependency components.

View vulnerabilities for a product and version

In the Vulnerabilities page, select the product and version that you want to filter on.

Filter vulnerabilities

Filter down to just what you need:

• Narrow down vulnerabilities by criteria such as severity, exploitability, and threat information.

• Select "Any" or specific parameters in filter drop-downs.

• Use text filters for direct input.

Vulnerability columns

View vulnerabilities across all products and versions

If you don't have a product and version selected in the Vulnerabilities page, you'll see all vulnerabilities for all products across all versions.

To ensure you're focusing on the most exploitable vulnerabilities, you can create and apply a reusable rescore profile to rescore all vulnerabilities across a product version. You can also rescore individual vulnerabilities manually.

Once you've rescored your vulnerabilities, you can then prioritize the remaining vulnerabilities by filtering down on those that have a combination of high CVSS scores with high exploitability (EPSS) scores, as well as having exploits or threats publicly available.

In the Vulnerabilities page, you can export all vulnerabilities for a particular product, as well as all notes your team has made in identifying the risk each vulnerability poses to your organization.

There are two ways to export vulnerabilities, either from the Reports page or directly from the Vulnerabilities table.

Export vulnerabilities from Reports

1. Click the Reports item in the sidebar to display the Reports page.

2. Click the Export vulnerabilities button on the Vulnerabilities CSV card.

Export vulnerabilities from the Vulnerabilities page

1. In Vulnerabilities, select the product name and either all versions or a particular version.

2. Click Export vulnerabilities. This will export any vulnerabilities that you have not otherwise filtered out.

Depending on your organization, you’ll likely want to start with the most critical vulnerabilities first, so that you can assess their severity given your particular device, its environment and its use. In the Base score column, you’ll see both a v2 and a v3 score. Older devices may not have a v3 score, while newer devices may not have a v2 score. We recommend that you mitigate the v3 score first.

Rescore a vulnerability

You can individually rescore any vulnerability associated with a particular product version. If you've already applied a rescore profile to this product version, this individual rescore will override the profile rescore. Refer to Rescore an individual vulnerability for more information.

Remediate a vulnerability

Initially, all of your vulnerabilities will have a Status of blank. For CycloneDX status, you'll ultimately want to remediate each of these to either Exploitable or Not affected. For VEX status, you’ll ultimately want to remediate each of these to either Affected or Not affected. Refer to Rescore an individual vulnerability for more information.

Depending on your organization, you’ll likely want to start with the most critical vulnerabilities first, so that you can assess their severity given your particular device, its environment and its use. In the Base score column, you’ll see both a v2 and a v3 score. Older devices may not have a v3 score, while newer devices may not have a v2 score. We recommend that you mitigate the v3 score first.

Helm returns the Common Vulnerability Scoring System (CVSS) to provide numerical ratings corresponding to critical, high, medium, and low scores to ensure you understand your current vulnerability risk. Because older devices may only have a CVSS v2 score, while newer devices may only have a v3 score, Helm provides both CVSS v2 and v3 scores, enabling you to assess risk across the spectrum of your legacy and new devices.

This score incorporates a number of factors assessing the exploitability of a vulnerability.

Base score

For CVSS v3 scores, you can use a number of calculators to understand how the CVSS score for a particular vulnerability was calculated:

• NIST calculator for CVSS 3.1

• NIST calculator for CVSS 3.0

• NIST calculator for CVSS 2

Hover over each metric classification value to get more information on how to determine which value applies to your situation. For your convenience, we've also provided those metric and value definitions below.

Rescore CVSS 3.x vulnerabilities

You can rescore all vulnerabilities associated with a particular product version or rescore individual vulnerabilities.

Base CVSS score

Every vulnerability in the NVD starts with a base CVSS score. You cannot modify this base score, but you can modify the temporal and environmental scores by assessing your particular device's situation. Every metric in these two sections is set to Not defined (X) by default, which has the highest impact on the CVSS score.

All definitions are extracted from first.org's CVSS 3.1 calculator.

Exploitability metrics

Impact metrics

CVSS 3.1: Temporal score

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

CVSS 3.1: Environmental score

These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of base metrics and are assigned metric values based on the component placement in organization infrastructure.

Exploitability metrics

Impact metrics

Impact subscore modifiers

CVSS 2.1

Base CVSS score

Every vulnerability in the NVD starts with a base CVSS score. The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments. The Access Vector, Access Complexity, and Authentication metrics capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it. The three impact metrics measure how a vulnerability, if exploited, will directly affect an IT asset, where the impacts are independently defined as the degree of loss of confidentiality, integrity, and availability. For example, a vulnerability could cause a partial loss of integrity and availability, but no loss of confidentiality.

You cannot modify this base score, but you can modify the temporal and environmental scores by assessing your particular device's situation. Every metric in these two sections is set to Not defined (X) by default, which has the highest impact on the CVSS score.

All definitions are extracted from first.org's CVSS v2 calculator.

CVSS base score is divided into Exploitability and Impact metrics. Exploitability metrics include Attack vector, Access complexity, and Authentication, while Impact metrics include Confidentiality impact, Integrity impact, and Availability impact.

Exploitability metrics