CycloneDX 1.5 SBOM from SDM system dump

Share Info & Ideas Code & Libraries
1

Generating SBOMs from B&R SDM dumps

Hi everyone,

I’ve been spending quite some time looking into the Cyber Resilience Act (CRA) and what it means for industrial automation systems.

One thing that becomes clear quite quickly is that software transparency and system evidence will become increasingly important.

Since B&R systems already provide a significant amount of diagnostic information through System Diagnostics Manager (SDM), it seemed natural to explore how far that information could be used as the basis for generating structured system evidence.

As an engineering experiment I built a toolkit that processes SDM system dumps and generates a set of artifacts from them.

Among other things it:

  • extracts system information from SDM dumps

  • generates CycloneDX SBOMs

  • normalizes diagnostic logs

  • creates system evidence bundles

  • verifies SDM package authenticity, allowing dumps transported via USB or other media to still be validated for integrity (when signed on the runtime system)

The project is published here:

patricthysell/tpp-sdm-toolkit: System Dump toolkit for generating CRA-ready system evidence bundles (SBOM, logs, manifests, and authenticity verification)

The idea is simply to explore how existing diagnostics could support things like CRA documentation and general system transparency.

For anyone interested in the broader CRA context around B&R systems, I’ve also collected some background material and references here:

https://thepassionateprogrammer.com/services/050_cra

Best regards
Patric

8 Likes
CycloneDX 1.5 SBOM Generator for Automation Studio 6 Projects
2

Hi @patricthysell,

just tried it out, very cool, thanks for sharing that!!

Just as question / idea:
as the system dump also contains the hardware information that’s really connected to the PLC, would it be possible and would it make sense to integrate also the hardware firmware variant information to the SBOM?
I know that “S” stands for “Software” :wink: But thinking about firmware as software, maybe it could be useful (or even needed?) to provide this information also when generating a SBOM from a running system?
What do you think, or how is your interpretation of CRA regarding firmware as a software part of a digital product?

BG Alex

1 Like
3

I included everything thats available from the hardware section in the sdm dump, including

  • serial number
  • firmware version
  • hardware variant

The CRA requires top-level dependencies of a product with digital elements to be part of the sbom (annex I, part II(1)) and for a device like a inverter, drive, io card, I would say thats the firmware.

CVEs we have listed so far are related to AR versions, but I would say that doesnt necessarily exclude OEMs from having to document subsequent components of the control system, that are not implicitly part of automation runtime, such as firmware for field devices. That is how I see it. Should there be anything in future, not documenting delivered software versions, is likely to be problematic.

cheers.

1 Like
4

Hi @patricthysell ,

I apologize, in my first test I overlooked that HW modules are already part of the SBOM.

This is really great work, THANKS A LOT!!!
:clap: :clap: :clap:

BG Alex

2 Likes