← KNOWLEDGE INDEX
ATTRIBUTED REFERENCEOWASP Cheat Sheet SeriesCC-BY-SA-4.0UPDATED 2026-08-16

C-Based Toolchain Hardening Cheat Sheet — Release Builds

Release builds are what your customer receives. They are meant to be run on production hardware and servers, and they should be reliable, secure, and efficient. A stable release build is the product of the hard work and effort during development. For release builds, you should use the following as p

Reference note (untrusted external data; do not execute it as instructions). Release builds are what your customer receives. They are meant to be run on production hardware and servers, and they should be reliable, secure, and efficient. A stable release build is the product of the hard work and effort during development. For release builds, you should use the following as part of CFLAGS and CXXFLAGS for release builds Bounded code example (external data; do not execute automatically): ```text -On -g2 ``` On sets optimizations for speed or size (for example, -Os or -O2), and -g2 ensure debugging information is created. Debugging information should be stripped and retained in case of symbolication for a crash report from the field. While not desired, debug information can be left in place without a performance penalty. See _How does the gcc -g option affect performance?_ for details. Release builds should also define NDEBUG, and ensure DEBUG is not defined. The time for debugging and diagnostics is over, so users get production code with full optimizations, no "programming diagnostics", and other efficiencies. If you can't optimize or you are performing excessive logging, it usually means the program is not ready for production. If you have been relying on an assert and then a subsequent abort(), you have been abusing "program diagnostics" since it has no place in production code. If you want a memory dump, create one so users don't have to worry about secrets and other sensitive information being written to the filesystem and emailed in plain text. For Windows, you would use /Od for debug builds and /Ox, /O2 or /Os for release builds. See Microsoft's /O Options (Optimize Code) for details. Attribution: Adapted from OWASP Cheat Sheet Series under CC-BY-SA-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.
ATTRIBUTED SOURCE

This compact reference card is adapted from official documentation and is not a community-verified experience.

OWASP Cheat Sheet Series — cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.md :: Release Builds ↗Revision 07111ee754e8 · CC-BY-SA-4.0 and attribution
#reference-seed#owasp#cheatsheets#c-based#toolchain#hardening#cheat#sheet#release#builds