Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Root cause analysis – to identify common causes and learn how to reduce future introduction of similar vulnerabilities. Questions to ask include the following: How did this vulnerability make it into the released product without being detected? How could it have been found and fixed earlier, before release? How might the vulnerability have been avoided entirely?
  • Automated testing – to find vulnerabilities sooner, ideally before release. Continuous integration (CI) systems and DevOps practices provide excellent opportunities to incorporate automated security testing. For example, a CI server could initiate a fuzzing campaign on each nightly build of a product. An automated release process might require that code pass all static analysis tests with no significant findings before proceeding.
  • Threat modeling – to identify high-risk portions of a product earlier in the development process so potential vulnerabilities can be found and addressed at design time, before they are even implemented.


< 3.2. Reporter | 3.4. Deployer >


  1. NTIA Awareness and Adoption Working Group, "Vulnerability Disclosure Attitudes and Actions: A Research Report from the NTIA Awareness and Adoption Group," 15 December 2016. [Online]. Available: [Accessed 6 June 2017].
  2. ISO/IEC, "ISO/IEC 29147:2014 Information technology—Security techniques—Vulnerability disclosure," 2014.
  3. ISO/IEC, "ISO/IEC 30111:2013 Information technology—Security techniques—Vulnerability handling processes," 2013.
  4. Microsoft, "Microsoft Security Response Center," [Online]. Available: [Accessed 23 May 2017].
  5. Cisco Systems, "Security Vulnerability Policy," [Online]. Available: [Accessed 23 May 2017].
  6. FIRST, "FIRST Teams," [Online]. Available: [Accessed 16 May 2017].