Software Bill of Materials

Think of a software bill of materials as an official ingredient list for a piece of software within a device. These parts, such as libraries and modules, can be open-source or owned, free or paid, and the information can be easily accessible or limited.

Industry experts refer to XIoT devices as black boxes because there is little visibility into what is running inside them. Firmware and software components are largely unknown without creating an SBOM, and not knowing what is running within the devices on your network puts your organization at risk for cyber threats, noncompliance, loss of business, and more.

SBOM creation via the NetRise platform starts with inspecting the current build of the product or firmware with Binary Composition Analysis (BCA). This deep, proprietary analysis provides visibility into all the components used to create software or firmware. The automated reverse engineering capabilities of the NetRise platform can provide organizations with as much as a 99.98% reduction in time expenditure, per DoD, GSA, and NASA estimates. The machine learning-powered scalability, comprehensiveness, and efficiency of the NetRise platform are unmatched in the current SBOM management market.

Think of SBOM generation like a ZIP file. To open it, you have to unzip and decrypt it. There may be one file or it may have many files. The same is true of an XIoT device. The NetRise platform unpacks it, decompresses it, and decrypts it to understand the components.

What should be included in an SBOM?

An SBOM should contain the following information: 

• Author 
• Supplier 
• Component name 
• Version string 
• Component hash 
• Unique identifier and relationship 
• Licensing 
• Pedigree 
• Provenance (if available)

How often do I need to update an SBOM?  

An SBOM should be updated whenever there are changes to the components that make up software within a device. If new software/firmware is released or a patch is made, an SBOM should be generated.  

How SBOMs Help During Cyber Attacks

Most often, an attacker compromises the supply chain where the firmware is created, which is why firmware security is so important. Once the firmware is compromised, the device can be leveraged in a number of ways. Signs of breach may include noticing the device exhibiting abnormal behavior or being unable to login to or control the device. Oftentimes, the compromised device represents an open door into the rest of your organization.

Security teams can leverage SBOMs to find vulnerabilities in device firmware and software before, during, or after a cyber incursion. The NetRise Platform continuously scans the National Vulnerability Database (NVD), the CISA Known Exploited Vulnerabilities Catalog (KEV), Threat Actor Groups, BOTNETs, and more to provide insight into the exploitability of risks. NetRise also alerts you to vulnerabilities within your network and prioritizes risks based on the potential for impact, enabling quicker and more effective mitigation efforts.

Identifying vulnerabilities allows:

• Device manufacturers to release patches or other remediation options 
• Asset owners to find and undertake mitigations independently of device manufacturers 
• Identification of affected software across all devices

The NetRise platform helps security teams understand their risks, prioritizes vulnerabilities, and recommends a path to remediation. With NetRise Trace, users can quickly trace impacted assets with a single query, creating a comprehensive graph of affected software supply chain components and their associated vulnerabilities.

The Vulnerability Exploitability Exchange (VEX) provides additional information on whether a product may be affected by a specific vulnerability and, if affected, whether there are actions recommended to remediate it.

VEX is highly flexible and can be used to communicate vulnerability information to users in a number of ways. For example, a VEX may be used to assert the vulnerability status for all known vulnerabilities in a given product or to communicate that a single, high-profile vulnerability isn't applicable to a product. VEX consumers should communicate with their suppliers to understand the specific use case a particular VEX document is meant to achieve.

While they are designed to work together, VEX does not require an SBOM and SBOMs do not require VEX. The increased transparency afforded by SBOMs makes VEX a useful way to communicate with stakeholders at scale.