diff --git a/docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md b/docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md
index 54809ccb..92e6bece 100644
--- a/docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md
+++ b/docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md
@@ -54,6 +54,8 @@ In this guide, we use the term *production code* for executable code intended fo
 
 Developers should ensure that both their production code and their instrumented test code pass their automated test suite with all their relevant options. We encourage developers to consider it a bug if the program cannot be compiled with these options. Those who build production code may choose to omit some hardening options that hurt performance if the program only processes trusted data, but remember that it's not helpful to deploy programs that that are insecure and rapidly do the wrong thing. Existing programs may need to be modified over time to work with some of these options.
 
+Flags can help counter some attacks, but not all. For more information on how to develop secure software, see the OpenSSF [Concise Guide for Developing More Secure Software](../Concise-Guide-for-Developing-More-Secure-Software). For more information on how to select secure open source software, see the OpenSSF [Concise Guide for Evaluating Open Source Software](../Concise-Guide-for-Evaluating-Open-Source-Software).
+
 ## Background
 
 ### Why do we need compiler options hardening?