摘要：在当今高度互联的数字世界中，软件安全问题从未像现在这样紧迫。特别是使用C和C++这类系统级语言开发的应用程序，因其直接操作内存的特性，时常暴露出缓冲区溢出、空指针解引用和释放后使用等一系列内存安全问题。微软和Chrome团队的统计显示，这类问题长期占据所有安全
开源安全基金会（OpenSSF）最佳实践工作组 | 2025年3月28日
在当今高度互联的数字世界中，软件安全问题从未像现在这样紧迫。特别是使用C和C++这类系统级语言开发的应用程序，因其直接操作内存的特性，时常暴露出缓冲区溢出、空指针解引用和释放后使用等一系列内存安全问题。微软和Chrome团队的统计显示，这类问题长期占据所有安全漏洞的70%比例。
虽然业界已开始呼吁逐步用内存安全语言（如Rust）重构现有代码库，但考虑到全球C/C++代码库规模可能高达2.4万亿美元的置换成本，这种转变注定是个渐进过程。在此过渡期内，掌握编译器安全强化技术成为每个C/C++开发者的必备技能——这正是本指南的核心价值所在。
以下选项组合适用于绝大多数GCC/Clang项目，建议作为项目构建的基准配置：
bash -O2 -Wall -Wformat -Wformat=2 -Wconversion -Wimplicit-fallthrough \ -Werror=format-security \ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 \ -D_GLIBCXX_ASSERTIONS \ -fstrict-flex-arrays=3 \ -fstack-clash-protection -fstack-protector-strong \ -Wl,-z,nodlopen -Wl,-z,noexecstack \ -Wl,-z,relro -Wl,-z,now \ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
开发阶段：建议全局启用-Werror将警告视为错误，强制解决问题代码发布时：应移除全局-Werror，改用-Werror=形式，避免工具链版本兼容性问题典型案例：强烈建议将1999年C标准已废弃的语法警告升级为错误（如隐式类型转换），这类问题通常需要开发者主动修改源码才能解决。
生产代码(Production Code)：追求最高可靠性和性能，可适当裁剪影响性能的防护选项（仅限处理可信数据时）测试代码(Instrumented Test Code)：应启用更多调试插桩，即使会降低运行速度也要确保缺陷检出率两者都必须通过完整的自动化测试套件验证。若代码无法通过这些安全选项编译，应视为需要修复的缺陷——这代表着现代C/C++开发的基本要求。
编译时防御：通过静态分析和代码插桩（如_FORTIFY_SOURCE）运行时防护：包括地址空间布局随机化(ASLR)、控制流保护(CFI)等硬件辅助：如Intel CET、ARM PAC等处理器级安全特性这些机制虽然不能完全消除崩溃，但能有效阻止攻击者将内存错误转化为可 exploit 的漏洞。正如Linux内核开发者Kees Cook所言："崩溃优于被攻陷"(Crashing is better than compromising)。
随着RISC-V等新架构的兴起和C23/C++26标准的演进，我们预期编译器安全技术将持续发展。OpenSSF计划未来扩展本指南，覆盖MSVC等更多编译器生态。
在完全过渡到内存安全语言之前，合理配置编译器选项仍是保护C/C++应用程序最具成本效益的方案。正如网络安全领域的铁律：防御需要层层设防，而攻击者只需突破一点——这些编译选项正是构建纵深防御体系的重要基石。
来源：發哒哒哒财
