Over the last 10 years, OpenSSL has published advisories on over 100 vulnerabilities. Many more were likely silently fixed in the early days, but in the past year our goal has been to establish a clear public record.

In September 2014, the team adopted a security policy that defines how we handle vulnerability reports. One year later, I’m very happy to conclude that our policy is enforced, and working well.

Our policy divides vulnerabilities into three categories, and defines actions for each category: we use the severity ranking to balance the need to get the fix out fast with the burden release upgrades put on our consumers.

• HIGH severity issues affect common configurations and are likely to be exploitable. The most precious OpenSSL component is the TLS server, and of the four HIGH severity bugs we had in the last year, two were server DoS. The third was the RSA EXPORT downgrade attack, and the fourth a certificate forgery attack, which luckily was discovered and reported to us very fast and so only affected OpenSSL for one release cycle. When a HIGH severity report comes in, we drop whatever we were doing, investigate, develop patches and start preparing for a release. We aim to get the fix out in under a month.
• MODERATE severity issues are likely to affect some subset of the OpenSSL users in a notable way. Examples from past year include DoS problems affecting clients and servers with client auth, crashes in PKCS7 parsing, and an array of bugs in DTLS. MODERATE issues don’t kick off an immediate release; rather, we pool them together. But we also don’t wait for a HIGH issue to come along (of course we hope one never does). We’ve been releasing pretty regularly on a bi-monthly basis to get the patches out.
• LOW severity issues include crashes in less common parts of the API and problems with the command-line tool (which you shouldn’t be using for security purposes!). For those, we’re reasonably confirmed that usage patterns that could lead to exploitation are rare in practice. We do due CVE diligence on every issue that may have a security impact, but in order to reduce the complexity of release and patch management, we commit these fixes immediately to the public git repository.

The graph below (raw data) shows the number of days from first report until the security release for each of the CVEs of the past year. You can see the policy in action: serious vulnerabilities do get fixed faster. (The first 9 issues were released in August 2014, just before adopting the new policy, and don’t have a severity ranking.)

![OpenSSL CVEs Aug 2014-Aug 2015] (/images/blog/openssl-security.png)

The acceptable timeline for disclosure is a hot topic in the community: we meet CERT’s 45-day disclosure deadline more often than not, and we’ve never blown Project Zero’s 90-day baseline. Most importantly, we met the goal we set ourselves and released fixes for all HIGH severity issues in well under a month. We also landed mitigation for two high-profile protocol bugs, POODLE and Logjam. Those disclosure deadlines weren’t under our control but our response was prepared by the day the reports went public.

We’ve also made mistakes. Notably, the RSA EXPORT man-in-the-middle attack didn’t get the attention or execution speed it deserved. We underestimated the impact and gave it the LOW treatment, only reclassifying it to a HIGH in a later advisory, once we realised how prevalent EXPORT cipher suite support still was. A couple of times, we scrambled to get the release out and introduced new bugs in the process: better release testing is definitely something we need to work on, and we’re grateful to everyone who’s helped us with continuous integration tests.

Of course, the true goal is to not have any CVEs in the first place. So I can’t say it’s been a good year: too many bugs are still being found in old code. But we’re working hard to improve the code quality going forward, and we’ve set the baseline.

Finally, a special thanks to all the security researchers who’ve sent reports to openssl-security@openssl.org: the quality of reports is generally very high and your collaboration in analysing the vulnerabilities has been tremendously helpful.