Worth reminding yourself about this one and using it as a case study for your developers…:
Seven years later, Heartbleed still has important lessons for all of us.
Know your code
First, managing open source software components is critically important for application security. While using open source components is a practical and fruitful strategy for application developers, those components do have to be managed properly. You have to know which components you’ve used in your applications, and you must be aware of any known vulnerabilities in those components. When new vulnerabilities are published about the software components you’ve used, you need to know right away so you can take action if necessary. (Likewise, you should know the software licenses of those components to ensure you are not using something improperly, but that is not the focus of this article.) A software composition analysis (SCA) solution like Black Duck automates much of this work.
Security is everyone’s responsibility
Second, you cannot rely on anyone upstream for security. While open source components often provide high-quality implementations of functionality that your application needs, mistakes do happen, and open source developers might have a different idea of acceptable risk than you do. For the software components you use in your application, it is your responsibility to understand what kind of security testing has been done and decide if you need to augment that testing with your own evaluations. For critical components like openssl that are part of the attack surface of your applications, performing your own security testing is prudent. Depending on the type of component, security testing can include static analysis (Coverity, for example), software composition analysis (Black Duck), interactive analysis (Seeker), and fuzzing (Defensics). It was Defensics fuzz testing, in fact, that uncovered Heartbleed.
Application security is critical in application development
Finally, application security is inseparable from application development. When you are designing new applications or new features of existing applications, you must harden your design by doing threat modeling to think about threats, exploits, and security controls. During development and testing, you must automate and integrate security testing tools so that developers fix security defects as they go. Deployment practices should follow the same rigor, with special attention given to cloud configurations, container base images, and application configuration. Finally, after release, newly discovered vulnerabilities, in either the application itself or its supply chain of open source components, must be promptly identified, evaluated, and addressed.