Upload SBOM & match to known software

Prioritize and remediate risk

API & Administration

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

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. This also contains the breadcrumbs, from which you can select products and product versions, as well as understand at a glance where you are in Helm. You can also click the sun/moon icon to change themes.

Breadcrumbs

Each Helm page has a breadcrumb trail so that you know exactly where you are. Your Dashboard is Home, so all other page breadcrumb trails start at Home /.

Vulnerabilities breadcrumbs

In the Vulnerabilities page, the default view is All products and All vulnerabilities. If you don't have any products yet or need to add a new one, click the All products (or selected product) drop-down > Create product. If you don't have any product versions yet or need to add new one, click the All versions (or selected version) drop-down > Create version.

If you have existing products and want to drill down to a particular product, click the All products drop-down to select one or all products. If you've selected All products, you will also see all versions of those products. If you've selected a particular product, click All versions to select the version you want to view.

Components breadcrumbs

In the Products (SBOM) page, there is no default product view. Click the Select product drop-down to select a particular product. f you don't have any products yet or need to add a new one, click the Select product (or selected product) drop-down > Create product. If you don't have any product versions yet or need to add new one, click the Select version (or selected version) drop-down > Create version. Select any product and product version to view just those components.

URLs

Share deep links to particular Helm pages with colleagues.

Sidebar

You can access any main page in the sidebar, including:

• Global search discovery:
• Admin: Add and manage products, then manage user permissions for each product

• Help: Provides paths to get you started, no matter where you are in your cybersecurity journey.

Filter

Product/version selection bar

Filter bar

Search

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.

• Hide or show columns: Click the Columns link to toggle on/off specific columns. If you want to hide a particular column that is already displayed, you can also hover over each column header to display a ... icon. Click this, then select Hide column.

• 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.

• Change column order: Hover over each column header to display a ... icon. Click this, then select Move right or Move left to order columns exactly how they work best for you.

• Multi-column sorting: Click the Sort fields link at the top of each table to apply complex sorts across multiple columns.

• Column sorting: Sort columns in alphabetic or reverse-alphabetic order. Hover over each column header to display a ... icon. Click this, then select Sort A-Z or Sort Z-A.

• 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.

Why can't I see some columns?

If you don't see particular columns, that means that they are currently hidden by default. You can customize your view to show only the data you want, nothing you don't — enabling you to stay focused on what matters most. Click the Columns link in the top of the components or vulnerabilities table to see 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: Get started or get unstuck quickly right here!

• Contact us: We are always here to help get you unstuck!

What is Helm?

Key features

FDA compliance

• Supports NTIA and FDA cybersecurity requirements for SBOMs.

• Provides tools for Secure Product Development Framework (SPDF).

Broad ecosystem visibility

• Tracks both open-source software (OSS) and commercial third-party software.

• Supports real-time operating systems (RTOS) and other operating systems to give a comprehensive view of your software ecosystem.

SBOM management

• Handles SBOMs from open source, commercial tools, and manual uploads.

• Matches your software against the National Vulnerability Database (NVD) and package managers using advanced normalization techniques. For example, Helm will normalize values such as “windows10”, “windows_10”, and “win 10” to the official value, such as Windows 10.

• Manage component licenses. Import or manually add license information. Helm can also add missing license information.

Vulnerability management

• Zero in on critical vulnerabilities.

• Track progress on unremediated vulnerabilities.

Regulatory reporting

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 for 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 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.

Top 5 vulnerable dependencies

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

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

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 component is matched with a package manager badge, but does not have an 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 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 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.

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

• 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 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

Kubernetes SBOM tool

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

Multi-Language (Microsoft and Syft SBOM tools)

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:
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

Create .zip

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

Use Medcrypt's SBOM generation tool

Use an open-source SBOM generation tool

Other ways to create your SBOM

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 components

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

SBOMs are critical to secure your present and future

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

Is my company impacted by Log4j or WannaCry?

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

Meet hospital requirements

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

Pre-market component and vulnerability tracking

• 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.

Post-market component and vulnerability tracking

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

Threat modeling

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 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 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

Maven

Gradle *

JavaScript *

Node.js

NPM *

Yarn

Objective-C/Swift

CocoaPods *

.NET

NuGet *

Python *

Pip

Poetry

PHP

Composer

Go

Gomod

Elixir

Mix *

Erlang

Rebar3

Multi-Language

Linux kernel source code

• 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 *

More tools

Use an open-source tool

1. Install CycloneDX-CLI.

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.

Overview

The Helm API allows users to efficiently manage SBOMs, assess vulnerabilities, and generate detailed reports. Currently available as a Python SDK (built on protobuf), the Helm API provides bindings and helper scripts to facilitate interactions with the API.

Key features

• Upload single or multiple SBOMs.

• Retrieve all vulnerabilities or filter to focus on CISA KEV vulnerabilities.

• Generate FDA SBOM reports or CycloneDX VEX reports.

• Identify unmatched SBOM components in your data.

Getting started

Request API access

Download Helm API SDK

1. Once you have received an email granting you access to the Helm API, click the Developers item in the sidebar.

2. Download the file below.

2. Because our API documentation is hosted on Gitbook, you will see an interim page that Gitbook is verifying the safety of this file -- this page unfortunately does not go away, but your file will complete downloading successfully.

Authentication and setup

Once you have been granted access to the Helm API, you'll need to download our API SDK, then generate your API key to make calls to the API.

Run scripts to automate SBOM and vulnerability management

API methods

The Helm API provides the following methods:

• listorganizations: Retrieves the organizations that the user has access to.

• listorganizationproducts: Retrieves the products a given organization has.

• listorganizationproductversions: Retrieves the product versions of a particular product for that organization.

• createorganizationproduct: Creates a new product under that organization with the provided product name. The user will have access to this product.

• createorganizationproductversions: Creates a new product version under a selected product with the provided version name.

• submitsbom:

  • Uploads an SBOM provided in the --sbom_files parameter.

  • Allows the user to upload an SBOM under an existing product and product version.

  • Users can create a new product, product version, and upload an SBOM under this new version.

• listunmatchedsbomentries: This lists all of your unmatched SBOM entries for a given SBOM product and version.

• listvulnerabilities: This lists all vulnerabilities for a given SBOM product and version. You can also filter this down via --exploit_source to CISA KEV vulnerabilities only, as detailed below.

• requestreport: This issues a request to generate a product version report. The report generation process is asynchronous, so this may take a moment.

• getreportrequeststate: This checks on the status of a requested report.

• getreportfile: Once a report request is completed (report_request_state=4), the report file will be available for download.

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.

• Seamless 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

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.

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:
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

Create .zip

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

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.

Bulk rescoring and remediation

Auto-enrich data

• All vulnerabilities are automatically updated with severity and exploitability information.

Automate and integrate

Compliance and reporting

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.

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.

7. Once you’ve uploaded your SBOM, you will see all of the 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, component name/version/supplier combo, and alias matches.

8. If you need to aggregate and merge additional SBOMs to this SBOM, click Manage SBOMs > Upload SBOM. This will add 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:

To include lifecycle information, these are the supported properties you can use in your CycloneDX SBOM. This information will be populated into the respective columns in the Products table, as well as in the component details. Note that if your SBOM contains duplicate properties for the same component, Helm will take the first property and discard the rest. For each field, you can only include either date or text value - if you include both, only date will be populated in the Helm UI.

To use any of these properties, you will need to include the whole namespace value (e.g., cdx:lifecyle:milestone.endOfSupport or medcrypt:lifecycle:milestone:endOfLifeText) in the name field and the corresponding value in the value of the property. We will import and export from thecomponent and/or metadata > components array of your CycloneDX SBOM.

1. Level of support (date): Import will support cdx:lifecycle:milestone:endOfSupport name property or eos_date (Medcrypt-specific name property). Export will be the CycloneDX native property.

2. EOS/EOL (date): Import will support cdx:lifecycle:milestone:endOfLife name property or eol_date (Medcrypt-specific name property). Export will be the CycloneDX native property.

3. Level of support (text): Import will support medcrypt:lifecycle:milestone:endOfLifeText or eol_text name property. Export will be `medcrypt:lifecycle:milestone:endOfLifeText.

4. EOS/EOL (text): Import will support medcrypt:lifecycle:milestone:levelOfSupportText or eos_text name property. Export will be `medcrypt:lifecycle:milestone:levelOfSupportText.

Including lifecycle information?

To include lifecycle information, these are the supported properties you can use in your CycloneDX SBOM. This information will be populated into the respective columns in the Products table, as well as in the component details. Note that if your SBOM contains duplicate properties for the same component, Helm will take the first property and discard the rest. For each field, you can only include either date or text value - if you include both, only date will be populated in the Helm UI.

To use any of these properties, you will need to include the whole namespace value (e.g., cdx:lifecyle:milestone.endOfSupport or medcrypt:lifecycle:milestone:endOfLifeText) in the name field and the corresponding value in the value of the property. We will import and export from thecomponent and/or metadata > components array of your CycloneDX SBOM.

1. Level of support (date): Import will support cdx:lifecycle:milestone:endOfSupport name property or eos_date (Medcrypt-specific name property). Export will be the CycloneDX native property.

2. EOS/EOL (date): Import will support cdx:lifecycle:milestone:endOfLife name property or eol_date (Medcrypt-specific name property). Export will be the CycloneDX native property.

3. Level of support (text): Import will support medcrypt:lifecycle:milestone:endOfLifeText or eol_text name property. Export will be `medcrypt:lifecycle:milestone:endOfLifeText.

4. EOS/EOL (text): Import will support medcrypt:lifecycle:milestone:levelOfSupportText or eos_text name property. Export will be `medcrypt:lifecycle:milestone:levelOfSupportText.

End of support example with component array

End of support example with component array

Including Windows KB patch information?

CycloneDX does not support Windows KB information natively, so to include Windows KB patch information, this is the Medcrypt-specific property you can use in your CycloneDX SBOM.

To use this property, you will need to include the whole namespace value (e.g., medcrypt:vulnerability:remediation:mskb in the name field and the corresponding value in the value of the property. of the component or metadata > components array of your CycloneDX SBOM. We will import and export from thecomponent and/or metadata > components array of your CycloneDX SBOM.

• Import and export will support the medcrypt:vulnerability:remediation:mskb name property, but regardless of where the KBs appeared in the original SBOM, they will be exported to metadata > component only.

Windows KB example with component array

What happens after upload?

Including lifecycle information?

To include lifecycle information, these are the supported properties. This information will be populated into the respective columns in the Products table, as well as in the component details. Note that if your SBOM contains duplicate properties for the same component, Helm will take the first property and discard the rest. For each field, you can only include either date or text value - if you include both, only one will be uploaded.

1. Level of support (date): Import will support cdx:lifecycle:milestone:endOfSupport property or eos_date (Medcrypt-specific property). Export will be the CycloneDX native property.

2. EOS/EOL (date): Import will support cdx:lifecycle:milestone:endOfLife property or eol_date (Medcrypt-specific property). Export will be the CycloneDX native property.

3. Level of support (text): Import will support medcrypt:lifecycle:milestone:endOfLifeText or eol_text. Export will be `medcrypt:lifecycle:milestone:endOfLifeText.

4. EOS/EOL (text): Import will support medcrypt:lifecycle:milestone:levelOfSupportText or eos_text. Export will be `medcrypt:lifecycle:milestone:levelOfSupportText.

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.

Not seeing your SBOM 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?

SBOM contains component hashes

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

Matched to NVD status

Matched to package manager

If matched to a package manager Package URL (PURL), it will have a badge of the package manager, such as Cargo, PyPI, NPM, or NuGet.

Matched to alias

Matched to CPE

Matched to name

The Matched status with a NAME badge indicates that the component name/version/supplier combo exactly matches a known component name/version/supplier combo

Matched by user

The Matched status with a USER badge indicates that this was manually matched by a user on this account. If the user created an alias rule while matching, it will be considered an Alias match.

Select match

Not found

Create an alias rule to automatically link to known software

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.

Automatic enrichment

If the component has a correct CPE or PURL identifier but incorrect supplier information, our system will add an Enriched CPE or Enriched PURL field, to preserve your original data. If we're able to identify a CPE or PURL for your component that is missing in your SBOM, we'll automatically add that to these fields for you to ensure a unique match.

Automatic de-duplication

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

Overview

After uploading your SBOM (Software Bill of Materials) or manually adding a component, you may encounter different statuses that your software component, version, and supplier combination was not automatically matched to an existing unique entry in the NVD (National Vulnerability Database).

To view vulnerabilities for your components, you'll need to resolve any statuses other than Matched NVD. By following these steps to resolve these statuses, you can ensure accurate matching of your software components to

Resolve Select match, Matched to package manager, and Not found statuses

• A Select match status means that your software component, version, and supplier combination has multiple potential matches, making it unclear which one is the correct match.

• A Matched status with a package manager badge (but no NVD badge) indicates that there either are no known vulnerabilities for that component, or that the component has a different name in the NVD.

• A Not found status means that your software component, version, and supplier combination could not be automatically matched to an existing entry in the NVD. This could mean there are no vulnerabilities for this component, or it could mean the component is named differently in the NVD.

Review potential matches (Select match or Not found statuses only)

1. Click the Match status badge to open the Resolution options modal, then click the View suggestions button in the Select match box. This will display the Multiple matches modal, where you can evaluate the option based on the following details:

   • Supplier: The name of the supplier associated with the potential match.

   • Name: The name of the software component.

   • Sample versions: Versions that were extracted from the CVE vulnerability data.

   • Type of match: This shows sources used to determine a possible match, such as Alias, Name, CPE (Common Platform Enumeration), PURL (Package URL), or a particular package manager match.

2. If you need more information to make a decision, click the details icon. This will open the Match details modal, where you can view more versions of the component and see reported vulnerabilities over time. A trend of reported vulnerabilities that aligns with your component versions suggests a strong match.

3. Create an alias: Once you determine the correct match, you can create an alias that links this match to your component. This alias ensures that future uploads of an SBOM containing this software component, version, and supplier combination will automatically use this alias.

4. Add a review note: Click Actions > Add review note to keep your team informed about the status of the assessment, suggest further review, or highlight any critical risks associated with the software component.

Match suggestions fields

To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

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 component's versions (or at least version formats) are considered stronger matches.

Match details fields

To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

Resolve Fix version status

After uploading your SBOM or manually adding a component, you might see a warning icon next to the component version, as well as a Fix version match status. This indicates that the version format doesn’t match the expected supplier version format.

1. Click the Fix version status badge for the component with the warning icon. Alternately, select Actions > Fix version for the component with the warning icon.

2. Check the version format to ensure it matches the known version number, make any necessary modifications, then save.

Resolve Contact us status

After uploading your SBOM or manually adding a component, you might see an error icon next to the component version, along with a Contact us match status. This indicates that we do not have a version parser for this specific version format.

If you see this icon, we're aware of the issue. However, if you need this resolved more quickly, please contact us for expedited assistance.

What happens when we add this version parser?

When we add support for a new version parser format, we will automatically reload any impacted SBOMs and their components to attempt to match them to known software in the NVD. You will be notified once the issue has been resolved.

How does this impact you?

• Exact match: Any known vulnerabilities from the NVD will be brought forward.

• Vulnerability discrepancy: If you notice a discrepancy in the number of vulnerabilities, don’t be alarmed—this process is part of ensuring accurate tracking and reporting.

• Multiple matches: Review these suggestions to determine the correct match.

• No match: If an exact match cannot be found in the NVD, it may indicate that the component does not exist in the NVD (implying no known vulnerabilities) or that it is listed under a different name. In these cases, you should:

  • Check the NVD to find the correct match.

  • Create an alias to link your software component correctly going forward.

Resolve Fix version status

After uploading your SBOM or manually adding a component, you might see a warning icon next to the component version, as well as a Fix version match status. This indicates that the version format or PURL value doesn’t match the expected values.

1. Click the Fix version match status badge or click Actions > ... > Fix version for the component with the warning icon. This will open the Manage component panel.

2. Version warnings are generally caused by an incorrect PURL or version format. Check the component's PURL and version to see whether this solves the problem. Make sure that the version format matches the known version number and PURL.

Resolve Contact us status

What happens when we add this version parser?

Upon adding support for a new version parser format, we will automatically reload any impacted SBOMs and their components to attempt matching them to known software in the NVD. You will be notified once the issue is resolved.

How does this impact you?

• Exact match found: Any known vulnerabilities from the NVD will be associated with the component. If there's a discrepancy in the number of vulnerabilities, don’t be alarmed—this process is part of ensuring accurate tracking and reporting.

• Select match: You'll need to review these suggestions to determine the correct match.

Add review for component

After matching or assessing a potential match or doing some other research, you can add a note for your team to reduce parallel efforts.

1. Click Actions > ... > Add review. This will display the Review component panel.

2. If the component does not already have a Reviewed status, this will automatically update it to Reviewed.

• 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 component name/version/supplier combo exactly matches an existing component name/version/supplier combo in our system.

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

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

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

• PyPI: This was exactly matched to a component 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. If the user created an alias rule while matching, it will be considered an Alias match.

Overview

Benefits of lifecycle rules

• Streamline FDA compliance: Automatically include required lifecycle information in FDA reports

• Ensure consistency: Apply the same lifecycle data across your entire product portfolio

• Save time: Update lifecycle information once and have it apply everywhere

• Improve accuracy: Eliminate manual data entry errors with automated rules

• Maintain flexibility: Easily adjust rules as product lifecycle information changes

Understanding the impact of lifecycle rules

When lifecycle rules are applied, they affect:

• Existing SBOMs: All previously uploaded SBOMs will have the lifecycle information applied

• Future SBOMs: Any new uploads will automatically have the rules applied

• FDA SBOM reports: The lifecycle information will be included in FDA compliance reports

• User-provided data: Rules take precedence over any manually entered lifecycle information

Add lifecycle rule

1. Click the Add lifecycle rule button. This will switch you to the Edit rules mode.

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

3. 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:

   • Standard format: [Supplier name]/[Component name]/[Version].

   • Version range format: 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.
4. To add additional version conditions, click Add version condition. Each condition uses AND logic, so everything must be true for the effects to apply.

5. 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 finished adding rules, updating rules, and/or changing rule priority, click Save & apply lifecycle rules. 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.

After you confirm these changes, Helm will apply them to existing and future SBOMs.

Set priority order of lifecycle rules

Lifecycle rules are applied according to their position on the rules list.

1. Drag-and-drop them higher to increase their priority or lower to decrease their priority.

2. Click Save & apply changes. This will apply any changes you have made, including adding new rules, marking rules for deletion, and reprioritizing.

Edit lifecycle rule

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

2. Make any modifications to conditions and/or actions to perform.

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 list. 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 on the main rules list.

5. When you're finished making changes, click Save & apply lifecycle rules. 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 apply them to existing and future SBOMs.

Delete lifecycle rule

Deleted rules will be unapplied from existing SBOMs, and will not be applied to future SBOMs. You cannot recover a deleted rule.

1. Click the Rules item in the sidebar.

2. Click the Lifecycle rules tab.

3. Click Mark for deletion on the lifecycle rules you want to delete.

4. If you need to change priority of any rules as a result of these impending deletions, drag-and-drop the respective rules higher or lower in the list.

5. Click Save & apply changes button. This will display a confirmation panel showing the impact of your potential deletions across your portfolio.

6. If you are deleting the only rule you have, you will be prompted to confirm applying all unsaved changes. In that case, you'll now see a blank rule, so that you can add more rules in the future.

7. Confirm your changes. You'll see a success notification that the rule will no longer be applied to existing or future SBOMs.

Troubleshooting and best practices

• Rule naming: You cannot currently edit rule names. They are automatically generated based on conditions.

• Rule conflicts: When multiple rules could apply to the same component, the rule higher in the list takes precedence.

• Session persistence: Always save your changes before navigating away, as unsaved changes will be lost.

• Verification: After applying rules, check a sample of components to verify the rules are working as expected.

You can view details about a component, 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 component details.

Product details

• Product name: This is your product name.

• Product version: This is your product version.

Component details

• Component name: This is the component (dependency) name (e.g., firmware, software, framework, library, file, operating system, etc.) that is installed on the physical representations of your device (e.g., Windows, OpenSSL). This is the component name from your SBOM.

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

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

• Matched dependency name: During matching, Helm may enrich your component name to increase match accuracy. This field will only display if the name was enriched.

• Matched dependency version: During matching, Helm may enrich your component version to increase match accuracy. This field will only display if the version was enriched.

• Matched dependency supplier: During matching, Helm may enrich your supplier name to increase match accuracy. This field will only display if the supplier was enriched.

• 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 component.

• Matched by:

  • System: Helm automatically matched this 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 component to a suggested match or created a new alias to link it to known software.

Lifecycle details

When building a new device, you can ensure that your component is actively maintained or prioritize upgrading to a more stable version. When updating devices in the field, you can prioritize upgrades for components that are nearing end-of-support or end-of-life. This will help you ensure that the stability and security of your device throughout its lifecycle.

Review details

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

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

• Last reviewed on: Shows the last time a user reviewed this component.

• Last reviewed by: Shows who last reviewed this component.

• Last review: This is the last review note made on this 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 component display, make sure Auto-refresh is on or click Refresh to manually update the page.​​

Auto-enrichment of CPEs and PURLs

Helm will automatically update and enrich your component's CPE or PURL if we are able to detect or derive a more precise match.

• Enriched CPE: If Helm's AI copilot locates a match or a more precise match for your component's CPE, it will automatically populate that information into the Enriched CPE field for that component. If you already had a CPE, that is still retained in the Original CPE field.

• Incomplete CPE: Helm will interpret incomplete CPEs (with at least 5 of the possible 13 segments of a CPE), Helm will now fill in missing CPE segments with a wildcard (*).

• Enriched PURL: If Helm's AI copilot locates a match or a more precise match for your component's PURL, it will automatically populate that information into the Enriched PURL field for that component. If you already had a PURL, that is still retained in the Original PURL field.

This information will be included see this information in the components table in now export this enriched info for any FDA reports that include SBOM components, including your enriched SBOM, FDA SBOM, or VDR report.

Automatically add missing component license information

Helm will detect and automatically enrich missing licenses for any new SBOM components that do not have any license associated with them. You can also have Helm automatically add license information for your existing components.

1. For any component that you want to enrich with license information, click Actions > Reload component.

2. You'll be prompted to confirm this reload, as it will discard any metadata (e.g., review information, match status, associated vulnerabilities, etc.). This will then 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.

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.

Our Azure DevOps extension for Helm enables seamless integration of Helm into your CI/CD workflows, automating the creation of product versions and the uploading of SBOMs to Helm. This extension can be used independently or incorporated into your existing Azure DevOps pipelines, ensuring 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 Azure repository.

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

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

• Seamless integration: Fits naturally into your existing Azure DevOps workflows, enhancing your DevOps practices without disruption.

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