A software bill of materials (SBOM) is a list of every component inside a piece of software: each library and package, its version and where it came from. For digital signage, the SBOM that matters is the one for the software running on the device in your building, because that is the part a new vulnerability would reach.
Why buyers ask for one
When a vulnerability is published in a common library, the first question is "are we affected?" With an SBOM, a security team can answer it in minutes by searching the list. Without one, they have to ask every vendor and wait.
- US federal agencies, since Executive Order 14028 (2021) made SBOMs part of selling software to them. State agencies and utilities have followed.
- EU buyers, because the Cyber Resilience Act requires manufacturers of products with digital elements, signage players included, to draw up an SBOM.
- OT security teams at utilities and plants, before a device goes near a control network.
What an SBOM should contain
The US NTIA's minimum elements are a good test: for each component, the supplier, the name, the version, a unique identifier, how it relates to the rest, who produced the SBOM and when. The two common formats are SPDX and CycloneDX, and either one lets a scanner check the list against vulnerability databases.
What to check
- Does it cover the device software, not only the cloud service?
- Is there one for every release, so it matches what your screens actually run?
- Is it signed or attested, so you know it came from the vendor unchanged?
- Can you get it without a sales call?
- How does the vendor tell you when a listed component turns out to be vulnerable?
Where Screenly stands
An SBOM is published for each release of Screenly, the Screenly Player Max models and Anthias, produced and attested for every release, in the trust center at trust.screenly.io. Third-party dependencies are audited regularly, and end-of-life dates for ScreenlyOS are published. Device security covers the rest of the device.
