Secure development with C++ - Lessons and techniques - Helge Penne - NDC TechTown 2023

This talk was recorded at NDC Techtown in Kongsberg, Norway. #ndctechtown #ndcconferences #cplusplus #security #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndctechtown.com/
Subscribe to our KZbin channel and learn every day:
/‪@NDC‬
We will look at lessons learned through developing security products using C++.
Writing secure C++ code is hard. We will try to take a lesson from other industries where security is important and see what measures we can put in place to make our C++ code more secure.
We will talk about practical tools and techniques, language features to use and to avoid, fuzzers and sanitizers, hardening using compiler options, methodology, some UB to be aware of, and the general feasibility of using C++ where security is important.

[@mogenshansen7210]

Thanks a lot for the presentation. It is really good and practical. I have been involved developing parts of safety critical safety critical systems in C++ for many. To various degrees (depending on the context) I have been doing and/or promoting most of what you are describing for years. There is one thing I don't fully agree on in your presentation, and that is the use of operator[] vs at(). If we assume that the system is not intended to try to do out-of-bounds access (like, we do not intensional use the exception thrown from at() to say terminate a loop), then regardsless of whether we use operator[] or at() we are by definition outside the scope of the intended state machine - we are executing a Weird Machine - if the program attempts to do out-of-bounds access. The question is: if we are in a unknown state, how can an exception be handled in such a way that garantees that we get back to a known state. I think that is impossible in general. The requirement must be that we get into a known state - which as described in the presentation may well be to terminate (and maybe restart) the application. Thus a reasonable implementation of operator[] could be to terminate the application in case of out-of-bounds access - which is well inside what is allowed from undefined behavior.