[trustable-software] Trustable Software Engineering

Colin Robbins colin.robbins at qonex.com
Wed Jul 20 11:49:12 UTC 2016


Hi Paul,

> it seems to be UK-centric.

It is currently - but note the use of the word currently, I'll share news as 
soon as I can.

> I'd be very concerned if TSI (or any other organisation) manage to brand 
> 'Trustable' to cover something which should not >actually be considered 
> 'trustable' in the normal english sense. Do you think that's a possibility?

I don't think the TSI is trying to brand Trustable.   The focus on 
Trustworthy.

> I'm only aiming at (my non-technical interpretation of) trustable, for 
> now... and I believe even that requires context (provenance) and deployment, 
> so I think we agree.

Absolutely, I believe any software can only be considered trustable in the 
context of a specific deployment.

> Is the GCHQ scheme public, by any chance? It would be fantastic to consider 
> their work here.

Yes - it can be found here: 
https://www.cesg.gov.uk/scheme/commercial-product-assurance-products-foundation-grade
The model has been used for the UK Smart Metering Programme, to ensure the V2 
Meters are "Trustable".

Cheers,


Colin Robbins
Qonex (the consulting arm of Nexor)

Tel: +44 (0) 115 953 5541

-----Original Message-----
From: trustable-software [mailto:trustable-software-bounces at lists.veristac.io] 
On Behalf Of Paul Sherwood
Sent: 19 July 2016 09:22
To: discussion about trustable software engineering 
<trustable-software at lists.veristac.io>
Subject: Re: [trustable-software] Trustable Software Engineering

Colin
thanks for this... please see my comments inline

On 2016-07-18 10:12, Colin Robbins wrote:
> As you know Nexor & Qonex have both been long term supporters of the
> Trustworthy Software Initiative (TSI): http://www.uk-tsi.org/

Yes, I've not had a chance to look into this properly so far. A couple of 
early hurdles for me:

- it seems to be UK-centric. Although I'm proud to be British, much of what 
I'm involved with and care about has international implications.

- it quickly asks for money (e.g. purchase PAS 574). Throughout my career so 
far, my experience with official Standards for software have been rather 
disappointing, so I am reluctant to fork out cash for this one.

> This has some academic roots, so they are quite picky on words. I
> suspect they would distinguish Trustworthy and Trustable, with
> Trustworthy being a generalist term, and Trustable being very
> specific.

I'm picky on words too, and normally I push back on people (academic or
not) who try to appropriate or redefine existing words.

By trustable here, I'm meaning software which meets technical criteria (it 
works, and so on...), and therefore someone may consider whether or not to 
trust it based that and on other factors. I'm avoiding 'trustworthy' since 
those other factors may override the technical criteria. e.g. geopolitical 
implications such that someone in country A would distrust software provided 
by organisations from country B, no matter how rigorously it could be 
demonstrated to work.

> As an example, a firewall may be trustworthy - it has the potential to
> stop network traffic.

So here I fall at the first hurdle.

'has the potential to stop network traffic' is nowhere near enough for me to 
consider a firewall as trustworthy. Whatever its official function, it can 
(and probably will) do other things that I'm not aware of, e.g. the Juniper 
issue last year. And depending on who manufactured it, I might distrust its 
claimed official functions entirely.

> However if I mis-configure with a rule that say "allow all traffic",
> that specific instance of the firewall is trustworthy, but not
> trustable.

Not for my uses of these words, and far as possible I'm trying to stick with 
the popular (non-technical) interpretations. I'll be happy to adjust my use of 
particular words here if/when consensus is established.

One of my pet hates is when technical/marketing people appropriate important 
existing words for their initiatives. Consider the LTS (Long Term Stable) 
kernel work. By default LTS is released every couple of weeks, and is End Of 
Life after 2 years. By most people's understanding it is neither stable 
(dealing a couple of hundred patches a week is a significant rate of change) 
nor long term (many important devices have a lifespan of 10 years or more)

I'd be very concerned if TSI (or any other organisation) manage to brand 
'Trustable' to cover something which should not actually be considered 
'trustable' in the normal english sense. Do you think that's a possibility?

> So I think the attributes you define under the "trustable software"
> heading are really trustworthy attributes. To become trustable, you
> need to bring in context and deployment attributes. This is very much
> what the GCHQ scheme for "Commercial Software Assurance" tries to
> achieve - a product is only trustworthy if it has the whole product
> environment to enable a trustable deployment.

Well, as is probably clear, trustworthy is a *very high* bar for me...
I'm only aiming at (my non-technical interpretation of) trustable, for now... 
and I believe even that requires context (provenance) and deployment, so I 
think we agree.

Is the GCHQ scheme public, by any chance? It would be fantastic to consider 
their work here.

> One of the challenges the Trustworthy Software Initiative has to face,
> is that fundamentally following a trustworthy process is more
> expensive that just hacking code.

True.

> In some markets this is acceptable (aircraft, defence), but others not
> acceptable (free mobile phone apps).

Again, true. However I imagine that improvements in education, thinking, 
approaches, processes and tools in general would be welcomed even in the app 
economy (they're not really *free*, in the sense that they still require 
effort to create)

> In my view, the industries that care are already doing stuff here -
> yes there is more, much more to be done, but the direction of travel
> is encouraging.

We'll see :)

> The big gap is in industries that don't care - to the detriment of the
> end user / consumer. I am convinced the solution here is economic, and
> not technical. Somehow the economic models need to change such that
> the economic impact of developing poor software is outweighed by the
> time-to-market advantages.

Another thing I don't trust is economics :) [1]

My main concern about this argument is that the feedback loop is too slow to 
actually regulate anything. For significant projects, the work can take years 
to deliver, by which time the key decision-makers and engineers have probably 
left the building.

> I welcome the initiative, and am happy to participate.

Excellent. Please could you share links to specific TSI or other content that 
you think is particularly relevant for readers here?

br
Paul

[1]
https://www.amazon.com/Things-They-Dont-About-Capitalism/dp/1608193381

_______________________________________________
trustable-software mailing list
trustable-software at lists.veristac.io
https://lists.veristac.io/cgi-bin/mailman/listinfo/trustable-software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4833 bytes
Desc: not available
URL: <https://lists.veristac.io/pipermail/trustable-software/attachments/20160720/d0746854/attachment-0001.bin>


More information about the trustable-software mailing list