[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