S4x23 Presents: SBOMs Galore
It seemed like a week didn’t go by in 2022 without the mention of Software Bill of Materials (SBOM) in our newsfeeds, from a client, or from a colleague, so the announcement that S4x23 would feature an SBOM challenge piqued our interest.
Although SRA does not develop commercial SBOM-related tools like several of the other participants such as aDolus, NetRise, Cybeats, or Finite State, we often deal with SBOMs within the context of their “ecosystem” during the delivery of several of our standard Cyber Physical Systems Security (CPSS) services, including Supply Chain Risk Management, Vulnerability Management, and Device Assessments.
Despite having no ambitions to create products to market in this space, we do have a unique perspective from our experience helping medtech, healthcare, manufacturing, and device manufacturer clients leverage SBOMs in conjunction with several services we offer. From that, we have been able to build up a collection of trusted open-source tools, methodologies, and experience that we call “SBOM as a Capability.”
We knew it would be interesting to join the S4x23 challenge through representing the capability of free, open-source tools, extending them as necessary to support proposed standards SBOM formats as required by the challenge. The opportunity to deep dive into the world of evolving SBOM standards, up and coming OT security tools, and get an in-depth look at the state of this very active segment was one that we could not pass up for too many reasons. One of those reasons being to recognize the impact and potentially contribute enhancements to the open-source community upon which we rely.
We pitched our somewhat unconventional proposal to the challenge organizers, who agreed that this would be a worthwhile endeavor. Read on to see how that turned out.
SBOM as a Capability
We recognize the impact of third-party and firmware software vulnerabilities on overall device and site security postures, especially OT/ICS systems that bridge the cyber and physical worlds. The recent introduction of new tools into this space and the adoption of SBOM standards such as CycloneDX and SPDX are very positive indications that the industry may be ready for something new.
SRA has always partnered with our clients to operationalize security practices through people, process, and technology. We apply our own SBOM capabilities to enable clients to build or implement their own while remaining agnostic to specific tools or solutions.
For example, we often help implement commercial tools along with process development, staffing, and socialization of their benefits. We take a crawl, walk, run approach to build up appropriate SBOM capabilities depending on where our clients’ security programs are on the maturity curve.
SRA has provided related vulnerability management services for our clients to help them define and operationalize such practices in their OT environments, and to realize meaningful risk reduction. This includes the development and adoption of vulnerability identification capabilities for devices built using a blend of passive tooling, SBOMs, and manufacturer advisories.
SBOMs play a part in several CPS security principles
Clients have also engaged SRA to develop, enhance, and implement their supply chain risk management processes, helping to identify risks in their upstream (producer) supply chain and provide vulnerability details to downstream stakeholders (consumer) by way of a formal information sharing process. The adoption of machine-readable SBOMs and vulnerability applicability data provide an opportunity to optimize this process both in terms of efficiency and accuracy.
What SBOM means to us
Despite creating software inventories and vulnerability management programs for various client projects, keeping up with the intricacies of various defined SBOM standards is tricky. Due to time constraints, we chose to limit support to a single standard, rather than supporting SPDX, CycloneDX, and SWID. Each seems to have their own drawbacks, strengths, and use cases. In our consideration, we only compared SPDX and CycloneDX as they appeared to be mature, stable, and were better supported by open-source tools and libraries.
SPDX comes with functional parsers, seemingly leading the charge on machine readability and automation support, whereas CycloneDX does not. It does however allow for vulnerability information to be encapsulated directly in the SBOM document itself.
The argument has been made that vulnerability information does not have a place in the SBOM standard due to the dynamic nature of vulnerability data as opposed to the static nature of firmware and software components. However, we see the support of vulnerability information as a net benefit as it is represented in an entirely isolated section of the document and only provides additional information without removing integrity from the more static components of the document. In either case, both standards are valid, yet suffer from the same major issue: the proper naming of components (more on this later).
Much like the SBOM document, the Vulnerability Exploitability eXchange (VEX) document has multiple standards to choose from. The most prominent two being CSAF’s VEX profile and CycloneDX VEX. The approach taken by CycloneDX is quite similar to their SBOM documents, and suffers from similar parsing issues due to lack of robust support.
CSAF’s VEX profile seems to have some public support, but most of what we have seen does not strictly adhere to the profile defined in their specifications. CycloneDX VEX doesn’t appear to have much public support that we were able to identify. Despite this, it does not seem fair to evaluate these standards based on their public adoption due to the overwhelming lack of support for VEX in general
Enabling SBOM and VEX Capabilities
Having covered SBOM and VEX standards, we can now consider how they work together towards the goal of supply-chain vulnerability management. SBOMs provide operators and owners of firmware/software to keep an accurate inventory of the components that comprise it. This is vital information, just like having the list of ingredients for a cake you just bought. What if you were allergic to gluten and the ingredients list has a type of flour you don’t recognize on it? This is where you would check the allergen contents at the bottom, which in this case is our VEX document. The VEX will provide us not only with vulnerability data (your gluten allergy), but also determine whether it applies to the components in our SBOM (allergen contents). Sounds like a dream come true for owners/operators of OT/ICS environments, right? That was the goal with the executive order given in May of 2021, yet the adoption of these standards is very much like the lack of gluten free options back in the early 2000’s, slim to non-existent.
This is a more prominent issue for firmware products since they are usually monolithic and often distributed without metadata or manifests that we would normally turn to for composition analysis. When composition information is not provided by the manufacturer, the industry answers with software composition analysis (SCA) tools aiming to pick apart a piece of firmware by utilizing various techniques to crawl, search, and emulate the firmware image itself. Performing this sort of composition analysis is akin to trying to create our ingredients list simply by tasting the cake. There are commercially available solutions for this, but our goal was to highlight the open-source community and bootstrap a solution.
Enter FACT
FACT (the Firmware Analysis and Comparison Tool) is “intended to automate most of the firmware analysis process…” through various methods of unpacking, analyzing, and comparing pieces of firmware uploaded to the application. It is an open-source project created and maintained by the Cyber Analysis and Defense department of Fraunhofer FKIE. FACT proved to be of interest to our team before even considering SBOMs as reverse-engineering components from firmware and software is often a big part of our device assessments, supply chain risk management services, and vulnerability management services. We are no stranger to creating, consuming, and analyzing “SBOMs” in the form of device and component inventories for our clients and have often done so by manually analyzing or reverse-engineering the firmware/software in question during hardware device assessments. Our teams will often use this information as the basis for theoretical vulnerability applicability analysis.
When performing these types of assessments, SRA uses SBOMs as a capability to enhance our hardware device assessments and to act as a basis for our supply chain risk management and vulnerability management services. If/when the sharing of standardized, machine ingestible SBOMs becomes a more common practice, we will greatly benefit from additional composition details in each of these scenarios.
Throughout the development process, it became clear that SCA tools fill the void created by a lack of SBOM support from device manufacturers. In an ideal world, operators and owners would receive an SBOM directly from the manufacturer in addition to a regularly released VEX feed. This is not possible in some cases, like if a manufacturer no longer exists or a product has reached end of life. When it is an actively developed and delivered piece of firmware however, SBOMs should be a standard delivered to the customer.
Why should you consider our opinion? As previously stated, we often perform assessments that would greatly benefit from SBOM and VEX documents, not just for our work, but for our client’s security posture. We have seen similar strategies at vulnerability and inventory management, but in most cases, they fall short. It is quite common for us to receive inventories from our clients that are either incomplete (due to lack of documentation or ineffective tracking) or lacking enough information from the manufacturer that they don’t offer much value beyond identifying the actual device itself. This leaves many companies we work with in an information deficit regarding technology that they own and/or operate. The onus should be on the manufacturers, if not to patch, to at least inform the operators/customers of their risk. This is especially true in this space as risk can often correlate to a compromise of operator safety or harm to the operation of the core business unit.
FACT, meet SBOM and VEX
After deciding we were interested in extending an open-source project to add SBOM capabilities, we began to investigate the “how”. Our team began by combing through open-source solutions, where a simple GitHub search for firmware analysis tools turned up plenty of options as alternatives to FACT. Many tools aimed to produce an SBOM directly from your source code (Microsoft’s sbom-tool, CycloneDX’s python library, etc..). Another popular approach was generating an SBOM from the packages in your Docker (or other) container’s manifest (Syft). Then there were those that offered a cobbling together of disassemblers, unpackers, binwalk analyzers, emulators, and a mountain of analysis rules and logic. The last category of tool aimed to take a piece of firmware, break it apart, and divulge its juicy secrets. Only one problem, most didn’t produce standards-based SBOMs intended for machine consumption, but rather took the approach of displaying the information within the tool.
FACT falls into the third category alongside a few other options. We decided to pursue FACT over the other strong contenders (like EMBA) for a few reasons; the project maintainers agreed to support our efforts, the baseline functionality of the tool provided the best starting point for our purposes, and its documented, modular plugin design spoke to faster development efforts on our part. These were important justifications for the team to start development towards a proof-of-concept extension to an open-source tool. Our goal in extending FACT was simply to meet the requirements of the standards (SBOM and VEX) to assess if a free, open-source offering could prove viable as an SCA tool.
The purpose of FACT is to automate a large piece of the firmware analysis process. It achieves this by implementing or wrapping several unpackers and provides analysis modules to describe certain characteristics (file hashes, software components, known vulnerabilities, etc..) of the unpacked firmware. All of this can be run on a single system as a collection of docker containers and the code base is almost entirely Python, making it easy to extend and develop. The main features of interest to us were the modules targeting identification of software components, as we could simply extend these to represent the results in an SBOM format.
Seems like an easy enough task, right? We thought so, too. Working with the CycloneDX python library allowed us a bit of abstraction, but working with the SBOM standard itself left us with more data manipulation than expected.
The SBOM standard seems straightforward, but when it comes to properly converting existing data into the format, some issues arise. For example, naming components is a challenge since the industry doesn’t have an easy solution for a standard naming-scheme, like referring to a component as “OpenSSL 1.2” vs “OpenSSLv1.2”. Another problem arises with dependencies when you are performing software composition analysis, since you won’t always map dependencies during the unpack step, but rather may be stuck rebuilding them later. These are common issues with extending any existing tool but are valid concerns when trying to build SBOMs yourself. The format also proves difficult when it comes to parsing, since CycloneDX doesn’t have a valid JSON parser in Python, despite having the library to support the object types.
Once we developed a solution for getting the FACT-generated data into an SBOM format, the team turned their attention to ingesting VEX documents. The VEX standard could benefit from more stringent definitions, as the few documents we found available seemed to take some liberties. A good example of this was some documents had the product version in the ‘product_name’ field, some did not. The issue with this looser interpretation of the standard is lack of broad parser support. When the standard allows the document author to define fields differently, the effort of support then falls to the operator or owner responsible for ingesting and processing the vulnerability information. With a stricter defined standard, a public parser could be made available that would empower product owners and operators to immediately make use of vulnerability information when it is made available.
Simplified diagram depicting existing FACT functionality and SRA enhancements
SRA’s developers successfully extended FACT to produce CycloneDX SBOMs with vulnerability data and enabled VEX ingestion as a proof of concept. Look for the upcoming pull-request that we’ll be submitting to the FACT_Core GitHub. We look forward to trying it out during the SBOM challenge and are excited to see what the future holds for open-source SCA tools.
FACT User Interface showing software component plug-in with SBOM enhancement output (JSON data)
Hopes for S4x23
We have a few things on our minds as we excitedly pack our bags with sunscreen, flipflops, and swag, that we hope to better understand by the end of S4x23.
- It appears that the industry may not be ready to let the robots automation take over just yet, but we’ll take a close look at the state of the tools, and the mindsets of the SBOM producers, and the willingness of consumers to adopt this burgeoning area into their vulnerability management practices. We hope to get a general sense of where the stakeholders stand and the technological capabilities at their disposal.
- Are device manufacturers (SBOM producers) actively working to distribute software bill of materials (SBOMs) and vulnerability applicability data to their customers (SBOM consumers)?
- On the flipside, will end users demand software bill of materials (SBOMs) and vulnerability applicability data from manufacturers? To the extent that it would influence purchase decisions.
- Are the SBOM-related products, such as software composition analysis (SCA) tools able to deliver the functionality the industry has been hoping for? Affordable? At scale?
- How might SRA enhance our services related to device vulnerability management to help our clients leverage the maturing SBOM and vulnerability applicability standards and tooling?
- Is the industry heading toward a consensus on competing standards such as SPDX and CycloneDX, or will they need to co-exist?
- How much will the increased adoption of encrypted firmware limit the reach of SCA tools? Will those manufacturers encrypting firmware be more willing to provide SBOMs?
- How well do commercial SCA tools perform the qualification of vulnerabilities that have been cross-referenced? Depending on the method applied, these are potential vulnerabilities. It can be extremely difficult to confirm that such suspected vulnerabilities are exploitable without device manufacture involvement or device testing.
We look forward to meeting those of you attending S4x23, so be sure to stop by our booth in the SBOM Pavilion and let us know your experiences with SBOMs, vulnerability management, OT/ICS vulnerability management, or anything related to device security. And whether we’re fortunate enough to meet in Miami, you can read our post conference follow-up blog post here soon after.
Walker Hines
Walker focuses on long-term red team operations, external and internal penetration testing, and spearphishing. Walker is a member of SRA’s R&I team, which researches and develops tools, techniques, and public content.
Walker has worked for clients in several industries including banking, pharmaceutical, insurance, entertainment & media, healthcare, manufacturing and retail.
Walker’s background includes Windows, Linux, System Development, and Software Development. Walker is a graduate of the University of Rochester's Computer Science program. He also is a Certified Red Team Operator (CRTO).
Gabe Siftar
Gabe specializes in securing IoT solutions, cloud environments, and hardware. Gabe has strong experience working with clients managing large deployments of IoT, medical devices, and Industrial Control Systems.
Prior to SRA, Gabe worked as a Systems Engineer for a global medical device manufacturer. This experience provides a deep pool of knowledge available to clients who design, manufacture, and manage secure hardware and IoT solutions. Gabe worked at the intersection of medical hardware, IoT and hospital IT systems, where he facilitated the development, deployment, and maintenance of critical healthcare systems.
At SRA, Gabe has applied that breadth of experience to client security assessments and as an advisor for client projects that span from on-premise to the cloud, and from low level hardware security to system architecture.
You must be logged in to post a comment.