A software bill of materials (SBOM) for a machine should list every software and firmware component with its supplier, name, version, unique identifier, dependency relationships, author of the SBOM data, and a timestamp. For power line repair equipment, ask each vendor for one per model and firmware release, in SPDX or CycloneDX.
What are the minimum fields?
The NTIA's minimum elements report groups the baseline into three parts: data fields, automation support, and practices and processes. The data fields it lists per component are Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.
Automation support means the SBOM is machine readable and can be generated automatically, so it scales. The practices part covers how often you update it and how you share it.
CISA reports that a 2025 draft update of the minimum elements guidance was released for comment, with comments closing on 3 October 2025, and that 2026 joint guidance adds new fields and practices. Check CISA's SBOM page for the current version before you write a contract clause.
Which format should you ask for?
Two formats dominate.
- SPDX is an open standard driven by the Linux Foundation for bill of materials data about software, AI models, datasets and other components. SPDX 2.2.1 is published as ISO/IEC 5962:2021.
- CycloneDX is developed by OWASP and Ecma International and published as ECMA-424. Version 1.7 was released on 21 October 2025. It describes components, services and dependencies across software, hardware, cryptographic assets and operational configurations, and can carry vulnerability exploitability data (VEX).
Either is fine. What matters is that the vendor delivers one consistently and that your tools can read it.
What is different about firmware?
Firmware sits below the operating system, often on boards and sensors from several suppliers, and updates arrive less often. Three practical points follow.
- Layers. A machine has a vendor application, an operating system, libraries, and firmware on separate boards. Ask for each layer, or for a tree where each component can have its own SBOM, as the NTIA report describes.
- Versions that match the field. An SBOM for the model is not the SBOM for the unit in your yard. Tie it to firmware version and serial range.
- Updates change the list. Every firmware release should come with a new SBOM, and old ones kept.
How does this help during a vulnerability event?
When a flaw in a common library is announced, the question is whether your machines include it. Without an SBOM, you email vendors and wait. With one, you search. CISA's guidance for the Log4j event told operators of industrial control systems to enumerate vulnerability status against product advisories, and a standing SBOM turns that from a project into a query.
A VEX statement from the vendor then says whether the flagged component is actually exploitable in the product. CISA's VEX minimum requirements document was published on 21 April 2023. That separates "this component is present" from "this flaw can be used here," which is the question operators need answered.
How can you read what you receive?
The Safeguard CLI can validate an SBOM against the SPDX and CycloneDX specifications and scan an existing SBOM document for known vulnerabilities, so a vendor file can be checked on arrival. See the companion post on generating and reading an SBOM with the CLI.
What to do
- Add an SBOM clause to purchase and support contracts: format, fields, delivery per firmware release.
- Request VEX statements for high severity advisories.
- Store each SBOM next to the asset record, with firmware version.
- Validate each file on arrival, and reject files missing the minimum fields.
- Scan the SBOM against known vulnerabilities on a schedule.
- Keep old SBOMs, since units in the field may run old firmware.
Quick check
Is an SBOM the same as a vulnerability report?
No. An SBOM lists components. You match that list against vulnerability data separately, and a VEX statement says whether a flaw is exploitable in the product.
Does a vendor need to publish the SBOM publicly?
Not necessarily. Many customers receive it under contract. What matters is that you get a machine readable one for each release.
Sources
- NTIA: The Minimum Elements for a Software Bill of Materials (PDF)
- CISA: Software Bill of Materials
- CISA: Minimum Requirements for VEX
- SPDX: overview
- CycloneDX: specification overview
- CISA: Apache Log4j vulnerability guidance, advisory AA21-356A
- Safeguard CLI
Last reviewed: 18 October 2026.
