Brian Mullen
Senior Manager, Global Security Software Group
As supply chains become increasingly complex, so too does the potential for firmware-related attacks. Firmware is the software that controls a device’s hardware. It’s embedded in everything from computers and smartphones to routers and industrial control systems. And because it’s so critical to the functioning of a device, it’s also a prime target for attackers.
Now, imagine that you are the CIO of a large company, and your job is to manage the security of the software supply chain for all of the company’s products. You would need to track not only the dependencies and origins for each component, but also keep tabs on who authored and maintains them, as well as when they were last updated. In addition, you would need to know about any known vulnerabilities and licenses in use. And finally, you would need to be able to authenticate each component.
Fortunately, there is a tool that can help with this: SBOM (Software Bill of Materials). SBOM is a machine-readable file that contains information about the dependencies, origins, authorship, maintenance, and update history.
An SBOM lists all the software components used in a device and their version number and other relevant information. The idea behind SBOM is that by knowing exactly what software is in a product, it will be easier to identify any potential security vulnerabilities. This is especially important for firmware security, as the firmware is often one of the most critical and vulnerable parts of a product. In addition, requiring SBOMs from suppliers can help ensure that they comply with the best security and quality control practices. So, while implementing an SBOM is not a cure-all for the challenges of firmware security, it can help improve your overall security posture. By requiring an SBOM, we can take a big step toward making sure our devices are safe from malicious attacks.
AMI sees the potential for SBOM to make a huge impact on supply chain firmware security and is encouraging the broader community to get behind this initiative. So far, the response has been encouraging, with many firms seeing the value. AMI is excited to be moving into the next phase of our PoC with supply chain partners. We’re looking for enthusiastic and innovative collaborators to help us make this project a success.
If you’re interested in working with us, please contact us at ami.com/contact. We can’t wait to hear from you!
Resources
Executive Order Related: Why we must do it:
- https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity
- https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
Ripple20: Why we should do it.
Who is using SBOM and why:
Good intro to SBOM use cases:
Good info on industry wide proof-of-concepts and much more generic SBOM info
Methods/Tools for associating SBOMs with binaries:
- https://github.com/hughsie/python-uswid (LVFS/Redhat/Richard Hughes’ embedded coSWID tags solution)
- https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-21.txt
- https://uefi.org/node/4261 (Intel’s approach with TPM/RIM)
Proof of concept
- https://toml.io/en/v1.0.0
- https://en.wikipedia.org/wiki/CBOR
- https://www.ntia.gov/files/ntia/publications/ntia_sbom_sharing_exchanging_sboms-10feb2021.pdf(Advertisement and Discovery)
VEX
SBOM Tooling Info: