11–20 of 27 posts
It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.
It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
What's considered critical or difficult to discover is a bit subjective, but: It's easy to forget that alignment is important on some architectures (other than for performance reasons), so be careful when using placement new: https://www.securecoding.cert.org/confluence/display/cpluspl... This may seem obvious, but even the C++ committee got this one wrong when they created auto_ptr (which has since been removed from…
If memory safety is actually important to you, there's now an actual practical solution: SaferCPlusPlus[1].
A tool to automatically retrofit memory safety to existing C/C++ code is in early development (but resources are limited so it might be a while).
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.
[0] https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
[0] https://www.amazon.com/Secure-Coding-2nd-Software-Engineerin...
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
It disturbed me a little because this is the kind of stuff you learn in school, and they all have been there. Maybe they did not paid enough attention. Given the kind of programs we are writing, I could be rejecting candidates who don't cite deadlocks has a classic problem, and give a locking order as a classic solution to avoid them, even if they are right out of school.
All of that to say: IMO "novice" or "experienced" C++ programmer very often bear the risk of not really predicting the ability to write correct and maintainable code, because for the experienced ones, they can very well never have had any serious approach or mentors to get them to a decent mindset, while at the same time a smart and motivated novice can quickly figure out more and more of what matters, given some predispositions, a proper mentor, and/or a project inducing that.
If you find some of the CERT rules basic, you will quickly find most of them in that case. However, they are still useful to be used as a checklist, or for programmers who don't care enough about programming, or simply have been busy implementing piles of features in some kind of spaghetti code (and fixing 10% of the resulting bugs during 75% of their time) during a decade, etc.
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
I've not read through the CERT C++ rules (yet), but I highly recommend reading "Secure Coding in C and C++" [0]. Expectedly, there's a good discussion on bounds checking. But, nearly half the book is dedicated to integer underflow/overflow (and signed/unsigned) issues (which most devs either ignore or are oblivious to). It's not a panacea, but if you're write C/C++ without thinking about security and how things can g…
[1] https://github.com/duneroadrunner/SaferCPlusPlus#cint-csize_...
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
I've not read through the CERT C++ rules (yet), but I highly recommend reading "Secure Coding in C and C++" [0]. Expectedly, there's a good discussion on bounds checking. But, nearly half the book is dedicated to integer underflow/overflow (and signed/unsigned) issues (which most devs either ignore or are oblivious to). It's not a panacea, but if you're write C/C++ without thinking about security and how things can g…
http://www.sis.pitt.edu/jjoshi/courses/IS2620/Spring07/Lectu...
It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.
I thought there was a checker (based on clang) included by the CPP Core Guidelines [0], but I'm not seeing it there currently. Must have been external. I know I saw a tool that provided partial support, at least for GSL [1] (MS's library support of the the CPP Core Guidelines). [0] https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/