A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information
Extracted elements (30)
Both encrypted (https, coaps) and unencrypted (http, coap) retrieval methods are included as a matter of pragmatism, acknowledging that some constrained IoT device classes cannot implement TLS. Encrypted methods are strongly preferred.
SBOM and vulnerability information are intentionally separate because they change at different rates: SBOMs change with software updates while vulnerability information may be updated more frequently as new CVEs are discovered. MUD's cache-validity node helps tooling track refresh cadences.
The model specifies only how to locate and retrieve SBOM and vulnerability objects, not their format. This keeps the discovery mechanism neutral and allows format choices (SPDX, CycloneDX, CSAF, CVRF) to be made by bodies such as the Linux Foundation, OASIS, and ISO.
Three retrieval methods (on-device, cloud URI, out-of-band contact) are provided to cover distinct deployment scenarios: IoT devices with direct interfaces, devices without interfaces but manufacturer web presence, and suppliers who need to individually evaluate requests.
Clients MUST observe the Content-Type header on HTTP/CoAP responses to determine which SBOM or vulnerability format is being transmitted, since multiple formats (SPDX, CycloneDX, CSAF) may be served from the same endpoint.
Backend tooling SHOULD silently discard SBOM information sent with a media type that is not understood, rather than failing or producing errors.
If a client attempts to retrieve an SBOM via HTTP or CoAP and is not authorized, the server MUST produce an appropriate error response with instructions on how to register that client.
If vulnerability information is released early to select customers, appropriate access controls and authorization SHOULD be applied to that information.
Implementations SHOULD offer a means to configure endpoints to use TLS or DTLS, because unencrypted communications allow manipulation of retrieved SBOM and vulnerability information.
The http and coap identity values for local-well-known retrieval are explicitly NOT RECOMMENDED because they use insecure, unencrypted transports; they are provided only because they may be unavoidable for certain constrained device classes.
The sbom-contact-uri leaf MUST carry a tel, http, https, or mailto URI schema; this constraint is enforced via a YANG pattern restriction on the inet:uri type.
The vuln-contact-uri leaf MUST carry a tel, http, https, or mailto URI schema, as enforced by the YANG pattern constraint on inet:uri.
To mitigate device attacks, manufacturers SHOULD recommend network access controls (e.g., MUD ACLs) for devices that expose transparency information.
Use of a specific Accept header in HTTP or the Accept Option in CoAP when retrieving SBOMs is NOT RECOMMENDED, because IoT devices have limited capabilities. Backend tooling is expected to handle multiple formats.
When an endpoint hosts SBOM information at the well-known URI, the endpoint SHOULD NOT provide unrestricted access to that URL by default, since SBOM data reveals the software inventory and can aid attackers in identifying exploits.
When both vulnerability and software inventory information are available from the same URL, both the sbom-url and members of the vuln-url list MUST indicate that. Network management systems MUST take note and not retrieve the resource a second time.
SBOM data provides a detailed software inventory that may reveal sensitive implementation details. The specification recommends not exposing the well-known SBOM endpoint without access controls to limit unintended disclosure.
The 'cloud' case for SBOM retrieval uses a keyed list 'sboms' with version-info (string) and an optional sbom-url (inet:uri constrained to coap/coaps/http/https schemes). Multiple SBOMs for different software or hardware versions may be listed.
The ietf-mud-transparency YANG module augments the MUD model (/mud:mud) with a 'transparency' container that exposes SBOM and vulnerability discovery information. The grouping can be used independently of MUD. The module is versioned 2023-10-10.
The 'local-well-known' SBOM retrieval case carries an identityref selecting from the mudtx:local-type identity base, with defined values: http, https, coap, coaps. The selected identity specifies which protocol is used to retrieve SBOM from the device's well-known endpoint.
The 'sbom-contact-info' case exposes a leaf sbom-contact-uri (inet:uri) constrained by pattern to tel, http, https, or mailto schemes, enabling out-of-band requests to the supplier for SBOM information.
The transparency container defines two top-level choices: sbom-retrieval-method (cases: cloud, local-well-known, sbom-contact-info) and vuln-retrieval-method (cases: cloud, vuln-contact-info). An optional sbom-archive-list leaf provides a URI pointing to a JSON list of previously published SBOMs.
The well-known URI '/.well-known/sbom' is defined for application-layer discovery, allowing management and orchestration tools to retrieve SBOM information directly from a device endpoint. The precise response format is determined by the Content-Type header.
IANA added the URI suffix 'sbom' to the 'Well-Known URIs' registry (RFC 8615) with status 'permanent', enabling the well-known endpoint /.well-known/sbom for SBOM retrieval.
IANA added the value 'transparency' to the 'MUD Extensions' registry (defined by RFC 8520), with reference to RFC 9472.
IANA registered the YANG module 'ietf-mud-transparency' in the 'YANG Module Names' registry (RFC 6020) with namespace urn:ietf:params:xml:ns:yang:ietf-mud-transparency and prefix mudtx.
A skew can exist between the SBOM listing on a manufacturer's server and the actual software on a device that has not yet been upgraded. A unique mapping of device software version to its SBOM minimizes this risk.
Access to SBOM data hosted on other servers MAY be restricted using HTTP authorization mechanisms such as client certificates issued after a registration process or OAuth-based flows.
An attacker who modifies the transparency model elements may misdirect automation to retrieve false information or URLs pointing to malware. Mitigations include testing cloud URLs against a reputation service and requiring administrator approval when the authority changes.
SBOMs enumerate software inventory including versions; this information can help an attacker identify or develop exploits. However, if the software itself is available to the attacker, they may already be able to derive the same inventory independently.