I recently blogged about how the curl project switched to doing all handling of vulnerabilities at severity LOW and MEDIUM in the public.

Let me now describe how you can follow along this process and help out. Add your opinions, comments and assessments to help the curl project stay honest, do even better and manage the load.

Issues

Vulnerability reports are now submitted directly in curl’s issue tracker on GitHub. Judging by the initial set received, the persons submitting them do not particularly highlight the security angle in the title but it is instead implied or specified in the issue description. I hope people react if we somehow miss it.

Tags

We use a set of tags to manage vulnerability reports on GitHub. They are all prefixed by vuln:.

vuln:ASSESS

Every submitted issue that has a claimed or suspected security angle – a possible vulnerability – first gets the vuln:ASSESS tag set (by one of the curl maintainers). This tag marks the issue as one that we should evaluate, assess and determine first if it is a vulnerability, and if it is, what severity.

Anyone is free to leave their comment and thinking to help us come to a conclusion.

This tag is removed again when an assessment has been done.

vuln:NONE

This issue was assessed in regards to its vulnerability risk and we deem that it has none; or it is so low that it is considered to be less than severity LOW. This issue is treated as just a bug.

If someone objects provides a reasonable and convincing argument, we can reassess.

vuln:LOW

This issue is a confirmed vulnerability at severity LOW. We work on a fix for this that we merge as soon as it works and then we close this issue.

If someone objects to the severity and provides a reasonable and convincing argument, we can reassess.

vuln:MEDIUM

This issue is a confirmed vulnerability at severity MEDIUM. We work on a fix for this that we merge as soon as it works and then we close this issue.

If someone objects to the severity and provides a reasonable and convincing argument, we can reassess.

Advisories

Confirmed vulnerabilities get a CVE and a dedicated security advisory that we work on separately from the issue and its fix in the curl-www repository. The CVE and its advisory get published in sync with the pending curl release. They are left as open in-progress pull-requests until then, using vuln:LOW or vuln:MEDIUM tags.

Each advisory has all the information about a single curl vulnerability. A detailed description, all the info, CWE, CVE, affected version ranges, if it is a C mistake, in which curl “area” it happens, a link to the original report, etc. The idea being that this single markdown file has all necessary information anyone might want and need about this specific vulnerability.

Public vs published

The work on these vulnerabilities is immediately public and the second we register and assign a CVE Id (the actual numerical identifier) to a problem, you can learn about its existence.

We do however not publish the issue and all relevant metadata to the CVE database until the publication date, which is the same date as the curl release date when we ship the first release that contains the fix for the vulnerability.

So information is public in the curl repositories early on, but it is not published until perhaps several weeks later, and it is at that later moment that it gets picked up by other tools and ecosystems and then gets widely known.