[trustable-software] Another straw man...

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Jul 5 08:04:10 UTC 2017


Hi Colin
On 2017-07-04 14:50, Colin Robbins wrote:
> I think the workflow is great for a traditional software development 
> model.
> However, more recently I've been looking at trustable software in the
> contest of containers (Docker and the like).    Let's put aside
> whether containers are a trustable approach for the moment.

Fair enough :) If I understand what follows I think you're highlighting 
the (very common) case where software is offered to a customer, and the 
customer should consider trustability alongside how well the offer meets 
(or can be adapted to) its scope/architecture requirements.
> 
> Within a Docker environment, as the developer I build my container (or
> set of containers) and put them in a registry.
> The customer then decides if they like (and trust) my container, and
> download it for deployment.

I think this is similar to the traditional 'download our software 
product here' or 'here is the install disk for our software product' - 
is there something specific I'm missing in the Docker/container 
situation that you are thinking of?

> As such, I think the model has two separated workflows...
> 
> ( --C1--> indicating Check 1 on your slide set)
> 
> Scope --C1--> architecture --C2-->  development & integration --C3-->
> publication  -- C4A
> 
> Retrieval --C4B-->  validation --C4C-->  deployment  --C5
> 
> In this way I think the validation activity splits into subset.
> C4A - evidence that what is published is what the developer intended
> C4B - evidence that what is retrieved is what the developer intended
> C4C - your original 4.

I agree with the principle you've exposed, i.e. if a we are a customer 
consuming third-party product, then we probably need to split out the 
purchasing/customer validation from engineering validation, not least 
because

- customer scope/arch requirements are likely to be different from what 
the engineering organisation started from
- customer may not be granted access to all of the metadata from the 
engineering organisation's process

> This may be making if overly complicated, but I think adds recognition
> of the supply chain into the model.

Thank you for flagging this - I'm going to give some further thought. We 
clearly need a fork to distinguish what happens for build vs what 
happens for buy.

br
Paul



More information about the trustable-software mailing list