Lecture
From Firmware Build to CRA Evidence: A Reproducible SBOM and Vulnerability Workflow
- at -
- Hall C5C5.100
- Language: English
- Type: Lecture
Lecture description
"Generating an SBOM for one firmware build is increasingly straightforward. Maintaining a defensible chain between the shipped firmware, its components, vulnerability findings, engineering decisions, and later security updates is much harder.
Using a small connected Zephyr application, this session demonstrates a vendor-neutral workflow from build to reviewable CRA evidence. The build produces an SPDX inventory and build provenance. Open tooling validates and normalizes the component data, maps public vulnerability records, and creates a review queue. A VEX-based decision then records whether a finding is affected, not affected, fixed, or still under investigation, together with the rationale, supporting evidence, reviewer, and product versions concerned. A simple policy gate determines whether the release can proceed without treating scanner output as an automatically approved engineering decision.
The demonstration also covers failure modes common in embedded products: ambiguous component identifiers, supplier patches not reflected in public databases, a CVE that matches a library but not the compiled configuration, changed components between firmware versions, and a new advisory published after release.
Attendees will leave with a reproducible reference architecture, sample SPDX and VEX artifacts, a minimum data model for traceable vulnerability decisions, and a practical checklist for adding the workflow to an embedded CI/CD pipeline. The session focuses on engineering implementation and human-governed evidence, not legal theory or a commercial platform."
Using a small connected Zephyr application, this session demonstrates a vendor-neutral workflow from build to reviewable CRA evidence. The build produces an SPDX inventory and build provenance. Open tooling validates and normalizes the component data, maps public vulnerability records, and creates a review queue. A VEX-based decision then records whether a finding is affected, not affected, fixed, or still under investigation, together with the rationale, supporting evidence, reviewer, and product versions concerned. A simple policy gate determines whether the release can proceed without treating scanner output as an automatically approved engineering decision.
The demonstration also covers failure modes common in embedded products: ambiguous component identifiers, supplier patches not reflected in public databases, a CVE that matches a library but not the compiled configuration, changed components between firmware versions, and a new advisory published after release.
Attendees will leave with a reproducible reference architecture, sample SPDX and VEX artifacts, a minimum data model for traceable vulnerability decisions, and a practical checklist for adding the workflow to an embedded CI/CD pipeline. The session focuses on engineering implementation and human-governed evidence, not legal theory or a commercial platform."
