Introduction

The FDA and other regulators are requiring medical device manufacturers (MDMs) provide comprehensive SBOMs (Software Bill of Materials) to track software supply chains and prevent exploits. For many MDMs, integrating SBOMs into their workflows is a recent shift following the release of the FDA’s Cybersecurity Guidance. In order to meet FDA requirements MDMs must first generate SBOMs for all of their products, a process often handled through both manual and automated methods. While tooling increases efficiency, available tools are far from perfect. This blog outlines the most common mistakes seen when it comes to SBOM generation and what you need to look out for when generating your own SBOMs.

1. Missing OS Information

To generate an SBOM of an OS, most SBOM tools will scan a list of all packages or applications that have been installed. This would closely align with a package manifest for a Linux device or the list of programs on a Windows device. However, for any OS most of the vulnerabilities are likely to apply not to the individual packages installed on it, but instead to the OS itself. Simply scanning a list of packages won’t include the OS, hence many tools miss it in their SBOMs. It’s vital to capture a complete list of vulnerabilities that include not only software packages but also the OS and its version.

2. Missing Runtime Environments and VMs

Similar to missing OS information, many SBOM tools will not be able to identify missing runtimes or VMs that a lot of software requires to run. This is due again to how these tools identify packages. For a .NET specific application, the tools will scan the .proj or .solution files to identify the list of third-party software being used.

However, like with OSs these lists don’t include everything you’ll want in your final SBOM. The biggest thing missing is the .NET implementation itself. This can be either the .NET version used to run the application, or the .NET implementation used to compile it. The former is preferred but not always possible to calculate since it can vary based on the user’s device running the .NET application. This can apply to other types of applications as well, such as Java or Node applications.

3. Inaccurate CPEs/PURLs

Most SBOM generation tools will auto generate a PURL (Package URL) for each software component or dependency. Some tools will also generate CPEs (Common Platform Enumeration) for software components as well. These IDs are important, as having an ID for each piece of software in an SBOM is a requirement by the FDA and NTIA minimum elements.

However, it’s important that these IDs are accurate, especially CPEs, as they can cause issues with tools designed to manage/monitor these SBOMs for vulnerabilities. CPEs are used by SBOM management/monitoring tools to identify vulnerabilities that may impact your SBOM. Having an inaccurate CPE that differs from the CPE that was assigned to a software component by the NVD can cause these tools to fail to correctly identify the software component leading to false negatives.

Inaccurate PURLs aren’t as big of a risk, but accurate PURLs can allow for tools to enrich your SBOMs and autofill some fields, such as missing NTIA minimum elements. That isn’t possible when the PURL is inaccurate or generic, meaning it doesn’t link the software back to a major platform like NPM or PYPI.

4. Missing Supplier Names in OS Packages

Another common issue with SBOMs of OSs, particularly Linux OSs, is that by scanning a list of packages installed the final SBOM will often miss key data points like the name of the supplier. These SBOMs may have no supplier listed or may use a generic value for all suppliers, such as Organization: NPM, or OpenEmbedded. Neither of these results meet the requirements of the FDA, the NTIA, or other agencies.

5. Missing Versions in SCA/BCA (Software/Binary Composition Analysis) SBOMs

An alternative to using tools to scan the source code repos is using SCA/BCA tools to scan the binaries built from those source code repos (i.e. the executable for an application). These SCA/BCA tools will perform a variety of strategies to try and identify the software included in the binary. One of the most difficult things to properly identify, however, is the version of software that is included in the binaries. SCA/BCA tools may use hashes or other techniques to try and compare the installed software to a list of known software versions but this can still fail to identify the proper version. As versions are mandatory data to include in all SBOMs this is something you’ll need to double check when using SCA/BCA tools to generate an SBOM.

Solutions

Always verifying that your SBOM isn’t missing any data after generation is the key to resolving these issues. If it is missing data, that data should be manu added to the SBOM. This can be done manually, but there are many ways to automate this with simple scripts too. Internal data sources like SOUP or COTS lists can be compared to the SBOM and used to check for missing components. External data sources like ecosyste.ms or Tidelift can be used to gather data about a package, like licenses that may be missing from the SBOM.

Some tools, such as Helm will automatically check for missing package information using the PURL associated with the software. Helm is Medcrypt’s Software Bill of Materials (SBOM) management and vulnerability monitoring solution. It is built specifically for medical device manufacturers (MDMs), providing full visibility across your entire medical device software supply chain to detect, prioritize, and remediate cybersecurity risk. When it comes to SBOM management, Helm outperformed competitors in monitoring, prioritizing, and remediating software components.

Conclusion

Unfortunately, if you’re hoping to just run a tool to generate your SBOM and have everything you need for a submission to the FDA or another regulator you’re going to be disappointed. The SBOM generation process today is mostly but not fully automated. Starting with existing tooling and verifying/improving SBOMs afterwards remains an important step to meet all of the NTIA minimum elements or other regulatory requirements for any SBOM.

For more on how Medcrypt can support your organization’s vulnerability tracking and SBOM management needs, visit us at medcrypt.com and contact us at info@medcrypt.com to get started.