[trustable-software] Safety, Security, and Portability

[Robert Seacord]

Paul,

Thanks for your comments;  there are some useful points here I need to consider.  In particular, I think I need to be a little clearer about portability. The discussion in the study group was mainly around what if any value does portability have when it comes to safety, as I still believe you would want to validate your software on every platform on which it is deployed.  The answer appeared to be mainly in tooling, in that in cases where tooling is not available for your target platform, you can run it elsewhere and detect portability issues that may result in a defect on the target platform.   This seems like less than an ideal way to produce safety-critical systems.

Your main point that I want to refute, you cynic you, are your summary comments.  First, we don't have any plans to solve safety and security, and I sort of go off topic a bit in the paper to point out cases where coding standards don't help.  We are trying to make things incrementally better.  We're not even trying to improve the C language; those are separate efforts.  We're just trying to standardize what types of problems need to be diagnosed by analyzers and compilers that want to go beyond the requirements of the standard, which are non-existent.

As a result, we don't need for developers to adopt this document directly.  We need analyzer and compiler vendors to conform to this standard so these issues are diagnosed in code being developed for one of the markets we are trying to service.

Thanks,
rCs


-----Original Message-----
From: Paul Sherwood [mailto:paul.sherwood at codethink.co.uk] 
Sent: Tuesday, September 12, 2017 5:50 AM
To: Trustable software engineering discussion <trustable-software at lists.trustable.io>
Cc: Robert Seacord <Robert.Seacord at nccgroup.trust>
Subject: Re: [trustable-software] Safety, Security, and Portability

Hi Robert,
On 2017-09-12 04:14, Robert Seacord wrote:
> I’ve written a short white paper on Safety, Security, and
> Portability to support the work of the WG14 Safety and Security Rules
> Study Group that we announced on this list some time ago.
> 
> If anyone has any comments either respond to this list, email me
> privately, or ideally markup the attached word document using track
> changes and return.

Thanks for this. I don't use Word, so can't go that route, but I'm happy 
to make a few comments here. I hope you don't think my comments are 
off-topic... I'm responding to the title, as much as the content :-)

1) title vs ISO content
The title suggests this is a general white paper about the 'Safety, 
Security and Portability'. However lot of the content seems specific to 
standardisation for ISO wrt the C language (there are over 30 mentions 
of ISO, for example). I believe some of the points you are making are 
more widely applicable, no just for an ISO-literate/active audience, and 
I fear that these points will be lost to readers who glaze over at, or 
resist the document because of, the ISO-specific content. Would you 
consider distilling your general content into what would be the core of 
the document, and separating the ISO-specific content into a section, 
appendix or different document?

2) C-specific content
Similarly some of your arguments are applicable for other languages 
besides C, so if it were me I'd represent the C content as examples, but 
that may be counter to your objective. If you choose to stick with the 
current emphasis, I guess another possibility would be a new document 
highlighting the general principles, and possibly referencing your white 
paper.

3) standards vs the real world
As far as I can tell from my own experience and discussions with 
colleagues and executives, official standards are often ignored even in 
'safety critical' industries.

4) portability
I've not followed the study-group discussion on portability in detail, 
but I had believed that there was some reasoning to say that portability 
could expose and help to mitigate against some kinds of problems (eg 
compiler/chipset specific vulnerabilities bugs). Your document seems to 
write off this idea with "Code portability can be divorced from safety 
and security concerns". Maybe I'm misunderstanding your point, since you 
then go on to describe situations where security and safety can be 
compromised by porting.

5) summary
"An International Standard (IS) based on ISO/IEC TS 17961 needs to 
address the requirements for safety-critical systems, security-critical 
systems and safety- and security-critical systems."

Call me a cynic, but I believe the hole is too deep to be plugged by 
creating an International Standard. I remain of the view that most 
software is written by engineers who have neither time nor interest nor 
incentive to even read ISO standards, let alone apply them. This 
increasingly true for software that lands in security-critical systems, 
safety-critical systems and secure-and-safety-critical systems.

br
Paul