Skip to content

Minutes 20 Feb 2025

Jump to bottom
Paul Albertella edited this page Feb 20, 2025 · 1 revision

Host: Paul Albertella

Participants: Pete Brink, Daniel Krippner, Mikel Azkarate, Gabiriele Paoloni

Agenda

  • Updates on documents
  • Daniel K: OSS Software Supply Chains
  • Trustable Software Framework

Discussion

Updates on documents

  • Igor is unavailable today
  • Pete has no updates for his document

OSS Software Supply Chains

Daniel K has sent a visualisation of his topic

What are the software supply chain models that apply for OSS?

https://lists.elisa.tech/g/osep/topic/for_discussion_this_week/111228651

  • Paul: Might the OSS Supplier in this model also make changes to the OSS component?
  • Daniel: Assuming an ideal model where this is all contributed upstream
  • Pete: Is some of the source material for the ‘safety provisioning’ expected to come from the OSS Community?
  • Daniel/Paul: Yes, but the value/extent/sufficiency of this may vary a lot

Daniel: Product company are ‘first line of defence’ for product liability

  • Product company may have a safety liability claim on the commercial suppliers of both OSS and proprietary components
  • Both suppliers have a codebase; only difference is that one is public, one is not
  • Both take a level of responsibility / liability for the supplied components

Pete: The OEM takes responsibility (at least in automotive) for the product liability

Gab: There will not always be an OSS supplier in the model - the Product Company might consume OSS directly

  • Daniel: This is indicated by the direct supply arrow to the commercial product
    • (Added a label to state this)

This can be simplified into an individual supplier in the chain, and their possible responsibilities, the claims that they make, etc

Software Engineering can cover a lot of different things

Pete: Isn’t that what the standards are for?

Paul: Yes, but suppliers are not always willing or able to use or engage with the standards

Trustable Software Framework (TSF)

Aiming to define a common framework of evidence that we need to determine the extent to which we trust software

Software in a product that has a critical role needs to provide evidence for all of the identified areas, but contributing suppliers may provide only a subset

  • Wish: If open source projects (and commercial suppliers?) adopt the TSF, then software integrators and product creators can have a basis for making their own determinations
  • Idea is to provide evidence to support the claims you are making about software, including the claims you are making about it, why you have confidence in those claims, and what a consumer can do to have the same (or greater) level of confidence
  • Proprietary software suppliers may be unwilling to provide some of this evidence, so instead integrators / creators must rely on other evidence that the software can be trusted (e.g. independent assessment against safety standards)

Clone this wiki locally