Talk

Architecting for Safe Embedded Systems that Integrate Open Source Components

Watch Now

36:58

EOC 2024

Login to Watch

Kate Stewart

Kate Stewart works with the safety, security and license compliance communities to advance the adoption of best practices into embedded open source projects. Kate was one of the founders of SPDX, and is currently the specification coordinator. Since joining The Linux Foundation, she has launched the ELISA and Zephyr Projects, among others, and oversees other embedded projects hosted by the Linux Foundation. With over 30 years of experience in the software industry, she has held a variety of roles and worked as a developer in Canada, Australia, and the US and for the last 20 years has managed software development teams in the US, Canada, UK, India, and China. She received her Master's in computer science from University of Waterloo and Bachelor's of computer science from the University of Manitoba.

View full profile

Topics Covered

High Reliability Software Architecture Software Design Open Source

Talk

Architecting for Safe Embedded Systems that Integrate Open Source Components

Kate Stewart

36:58 EOC 2024

Kate Stewart

36:58

Products are no longer created from monolithic code bases, they are composed of components that are integrated over time, and maintained by different entities, some of which are open source communities. For a system to be dependable (maintainable, safe, secure, etc.) all the components need to be integrated together and tested as updates occur to demonstrate they still adhere to the necessary requirements. Effective system engineering depends on requirements being tested for the system as a whole and for the individual components. However, open source projects frequently don't have requirements expressed in a form that is consumable for this level of analysis.

This talk will discuss a proposed framework for a "system" bill of materials that will enable those components providing requirements to be integrated so that product lines can be managed, and open source components that are able to surface up their requirements can be integrated.

1 / 4

Please log in or create an account to test your knowledge and see the answers.

What main problem does the speaker say creating a "system" bill of materials (extending SBOM/HBOM) is intended to solve for modern embedded systems?

A Enable integrated, point-in-time visibility and risk analysis across software, hardware, data, and services so updates and interactions can be tested and traced (correct).

B Replace the need for any safety engineering work by providing a single inventory document auditors can review.

C Serve only as a licensing compliance list that tracks open-source licenses used by the product.

D Centralize vendor contracts and procurement details so purchasing teams can manage suppliers.

E Act purely as a runtime monitoring tool to detect and block attacks in production systems.

According to the talk, when should component metadata (SBOMs, build info, dataset provenance) be captured to enable effective analysis and avoid expensive reconstruction?

A Capture metadata at the time the work is performed or the artifact is created — i.e., at creation/build time (correct).

B Wait until a security incident or safety audit occurs, then reconstruct the metadata from logs and memory.

C Only capture metadata once the product is deployed to field devices to avoid changing development workflows.

D Collect metadata only annually during compliance reviews to minimize overhead.

E Rely on developer recollection and informal notes after the project completes to assemble the SBOM.

What role does SPDX 3.0 play in the proposed framework for managing safety-relevant metadata for embedded systems?

A Provide a standardized, modular metadata framework (with new AI, data, build, and security profiles) to represent components and relationships so systems can be assembled into a queryable knowledge graph (correct).

B Act only as a license-declaration format with no capability to represent build, data, or hardware relationships.

C Serve as a proprietary commercial tool that replaces all existing open-source tooling for embedded builds.

D Be a runtime enforcement agent that automatically patches vulnerable components on devices.

E Function only for software in source form and cannot represent products, tests, or evidence used for safety cases.

What specific change does the speaker argue open-source projects must make so their components can be integrated into system-level safety analyses?

A Surface explicit requirements and traceability (requirements linked to tests/evidence) and export/import that metadata (e.g., via SPDX) so integrators can perform system analysis (correct).

B Stop publishing source code publicly and provide only binary artifacts to simplify certification.

C Avoid documenting requirements to maintain agility; downstream integrators should infer requirements during integration.

D Rely solely on spreadsheets and paper artifacts created by integrators rather than machine-readable metadata.

E Claim a project distribution is "safe" for all uses so integrators do not need to perform their own analysis.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
inline code	surround text with single `backticks`
code block (multi-line)	wrap on its own lines with three backticks: ``` your code here ```
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

No comments or questions yet. Be the first to start the conversation!

Partners & Sponsors

STMicroelectronics

Memfault

NXP

Micro Digital, Inc.

MySQL

Become a Sponsor