Vulnerability Response


Vulnerability Response response is a very important part of secure development. Rather than pro-active security it lays down the rules and procedures about how to handle an incident, when a security flaw has been found by someone, how to report such an incident, track them, fix them, make them public if required and how to document them so that they can be easily consumed by users.

Documenting where probable security flaws are to be reported

This should be present on the front page of the project site or wherever its web presence is.

What should a security report contain:

At the very minimum, what the issue is, what version it affects, how it can be reproduced, what environment the researcher used to reproduce the issue and if they has any Proof of Concept.

For example, refer to Red Hat’s security page on how to contact the security team and what information Red Hat would need. You don’t have to have an efficient and large security team, but the basic information remains the same. ![Red Hat Security Advisory](/secure-development-guide/images/rh-security.png)

Security advisory

Now that you have resolved the security issue with your software and released a fixed version, how do you let the users know that a new version which fixes security issues is available? One way of doing this is to write a security advisory page for each issue found. The advisory should contain at the minimum, some basic information about what the security flaw was, what is the possible risk to the users, which version fixes it, any other mitigating factors and some metadata like CVE id if required.

The diagram below shows a typical security advisory, this one is from the LibreOffice project and has all the essential information users would require: Libreoffice advisory Most people think you need some security background to write a good advisory, but that is not the case. An advisory is supposed to be consumed by the users of the application and not some security engineer, so keep it simple and provide all the important information which is required.

Set a proper lifetime for your software

If you are working on various versions of your software, you will eventually reach a point where you may not continue maintaining all of them. Therefore it may be necessary to sunset older versions at some point in time. Ensure you have a plan for this, as this is important from a security perspective, for example, end users may still be using older versions not aware of the fact, that you don’t backport security issues to the older versions anymore.


A basic Vulnerability Response program is very important. It can be a web page informing readers how you handle security and does not need to be fancy, just a simple process which is operational.