Compiler Options Hardening Guide for C and C++

Posted by pjmlp 3/31/2025

Compiler Options Hardening Guide for C and C++(best.openssf.org)

232 points | 77 commentspage 2

MITSardine 3/31/2025|

If my C++ project is a simple utility supposed to take some files, crunch numbers, and spit out results, is there still the possibility it can be used for nefarious purposes?

kibwen 3/31/2025||

It doesn't matter what the tool does, what matters is 1) whether it is ever exposed to untrusted input, 2) what permissions it has.

If you don't ever expose something to untrusted input, then you're probably fine. But be VERY careful, because you should defensively consider anything downloaded off the internet to be untrusted input.

As for permissions, if you run a tool inside of a sandbox inside of a virtual machine on an airgapped computer inside a Faraday cage six stories underground, then you're probably fine.

rramadass 4/1/2025|||

It depends on what exactly your program does and equally important, where it is deployed and used. Security is a matter of degree based on context i.e. there are levels of Security. It is not a all or nothing proposition.

If your program is going to be used for some non-critical work internally you don't have to bother much about attack surface/vectors etc. Just use some standard "healthy" compiler options and you are good.

If you would like to know more on this subject, i recommend reading the classic The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities by Mark Dowd et al.

duped 3/31/2025|||

Read/write access to a filesystem is a pretty large surface area for attack, so yes.

thfuran 3/31/2025||

How does it get its input files? Where does it run? What's the output used for?

dapperdrake 3/31/2025||

Related: Rob Pike on programming style, especially his note in include files: http://doc.cat-v.org/bell_labs/pikestyle

See also: SQLites amalgamation. Others (iirc Philippe Gaultier) have called this a Unity build: https://sqlite.org/amalgamation.html

Rob Pike on systems software research: http://doc.cat-v.org/bell_labs/utah2000/utah2000.html

EDIT: typo

z_open 3/31/2025|

His opinions on include files have fallen out of favor because compiling is faster and it adds needless work. Are there organizations that still do this? All the style guides I've seen do not.

csb6 3/31/2025|||

I believe clang and gcc avoid reading in and re-processing include files that are already included, so his advice is unnecessary and creates a lot of maintenance burden, especially for C++ where a lot more code is in header files. It may still be useful for old compilers, though.

kevin_thibedeau 3/31/2025||

They recognize include guards and skip any further inclusions for those cases. There are scenarios where you may want multiple inclusion and you can still have that.

dapperdrake 3/31/2025||||

If your filesystem and disks are fast enough, then maybe Rob's assumptions don't apply.

ryandrake 3/31/2025|||

I still adhere to this for personal hobby projects, more out of a sense of craftsmanship than anything practical at this point.

klysm 3/31/2025||

It would be really nice if we had a versioning scheme that enabled developers to get secure by default and opt into performance tradeoffs

tuananh 3/31/2025|

Wolfi OS (by Chainguard) is one of a few decided to adopt openssf compiler options

https://github.com/wolfi-dev/os/blob/main/openssf-compiler-o...

rurban 4/1/2025|

No, he does not. He skipped most warnings