[C-safe-secure-studygroup] Meeting Minutes - Wednesday 16 January - 2018

Laurence Urhegyi laurence.urhegyi at codethink.co.uk
Tue Jan 16 11:16:24 GMT 2018


Clive's walkthrough of his homework paper on 'Markets'.

3) Conclusions
I’m going to argue that the distinction that we should be making is not 
between safety and security, but between the development of bespoke code 
and the adoption of existing code. In this view, our rules have two roles:
	* in the development of bespoke code, static analysis can be applied to 
the code as part of the V&V process to ensure the rules have been 
followed to ensure that the code is free of undefined behaviour and 
avoids issues that are known from past experience to cause problems – if 
not immediately, then for future maintenance. It’s also possible that 
the rules may be incorporated into the compiler.
	* in the selection of existing code for adoption into a project, then a 
static analysis tool can be applied to check that the code is free of 
major issues, such as constructs that may lead to undefined behavior.

ACTION: We'll need to decide and agree on which definitions to use for 
Safety Critical Software, Safety Related Software and Security Critical 
Software. We should re-use one that already exists, maybe use the ISO 
definitions.

Discussion on whether our set of rules are supposed to address safety 
related and safety critical?
Gavin: Where's the data to distinguish between these terms? They're 
ambiguous atm. If we class something as safety related and it is then 
deemed safety critical, this could be problematic.
Clive: pragmatic option might be that safety critical should be a small 
subset, so things that will be an issue, ie, undefined behavior. Safety 
related is everything in safety critical related plus more, ie, things 
that are syntactically legal but anecdotally known to cause issues.
Robert: We're not establishing requirements for end products, we're 
saying if you're building an analyzer, here's the set of analysis you 
need to ensure your analysis tool or compiler is conforming to this 
standard. So there's a level of abstraction here. MISRA addresses safety 
critical software, as we are aiming to do.
Martin: there are some industries which are both safety and security 
critical and the implications are felt in both. We must be careful not 
to draw a line in the sand.
Clive: yes, the distinction between the two is very unclear.
Roberto: I agree, it is unclear, and I agree with Clive's distinction 
between bespoke code and existing code.
Robert: original intent was to address 3 markets: Safety Critical, 
Security Critical, Both. We've talked about these profiles a lot so far. 
The third profile is relevant here.

## Rule 10.7

See here:

https://gitlab.com/trustable/C_Safety_and_Security_Rules_Study_Group/wikis/misrarule10.7



More information about the C-safe-secure-studygroup mailing list