Skip to main content


Vulnerability Handling

By Blogs

Standards get a bad rap. Too often, they are used as a stick to compel compliance. Not all standards follow this model, however. Sometimes, they offer help and pointers for best practices which were learned the hard way. ISO/IEC 29147 Information technology – Security techniques – Vulnerability disclosure (2014-02-15) and ISO/IEC 30111 Information technology – Security techniques – Vulnerability handling processes (2013-11-01) are two standards for vulnerability handling and disclosure that follow this latter model. They contain helpful pointers to examples of vulnerability disclosures that were particularly well done that can be used as templates. ISO standards are priced out of reach for open source developers but there are some fantastic resources available from the authors of these standards on the web. One of my favorites is Katie Moussouris’ RSA 2013 presentation slide deck called “A Tale of Two Standards“. Every open source project whether major or minor should put some thought into how they will handle vulnerability notification, handling and disclosure. Mishandling vulnerabilities puts users at risk and has the chance of alienating the people that you are most trying to help.

The standards describe the relationship between the two documents: “While ISO/IEC 29147 deals with the interface between vendors and those who find and report potential vulnerabilities, ISO/IEC 30111 deals with the investigation, triage, and resolution of vulnerabilities, regardless if the source of the potential vulnerability was external to the vendor, or from within the vendor’s own organization, typically security, development, or testing teams.”

Immature organizations sometimes shy away from releasing vulnerability notifications because these are admissions of failure which often get over-hyped in the news. It is important to understand that the goals of vulnerability disclosure according to ISO/IEC 29147 are to

  • ensure that vulnerabilities are fixed
  • minimize the risk from vulnerabilities
  • provide users with enough information to evaluate risk
  • promote positive communications

The last point is often overlooked. If you provide security researchers an easy way to get a hold of you, you are less likely to be surprised by an unforeseen vulnerability disclosure. If you give users, an easy-to-process notification so that they are not surprised, nor unexpectedly called in to work during holidays, then they will feel happier about your project.

The first step is to establish a vulnerability reporting process which makes it easy for security researchers to report vulnerabilities that they find in your project. Have a security link on your front page. Reserve for vulnerability notification. Provide a way for the security research to give the information to you in an encrypted format – most projects publish one or more PGP keys. I’m not a big fan of shared keys because it is too easy to lose control over this critical key as people come and go from your project, but if you are already using shared keys in your project and it works for you, then you can use a similar approach for creating a security notification shared key. Alternately, you could handle initial disclosure via an https protected web form. Establish a mutually respectful dialog with the security researcher. Let the researcher know of your findings and when/how you plan to remediate the defect. Ask the researcher when they plan to go public, if the researcher hasn’t already offered the information. Ask the security researcher whether they would like credit for finding the vulnerability.

The next step is to establish a vulnerability handling process. Who is informed of the vulnerability so that they can help create, review, and test the fix? How will you track the patch which performs the fix? Code checked in to your public repository to make the fix acts as early notification to those who are watching carefully, so the code release should be coordinated with the release of the fixed version and your security advisory.

Finally, to continue maintaining positive communication flows with your users, you should make it as easy as possible for users to get and process security information about your project. Establish a template for security advisories that you use every time that is easily readable by humans. Establish a pre-notification process for critical security vulnerabilities whereby you notify your users that a critical security patch is coming at a certain time on a certain date. This allows users to plan maintenance windows without pre-disclosing details of the vulnerability which would render the users vulnerable to attack.

ISO/IEC 30111 recommends that security advisories include

  • a unique identifier for the advisory/issue,
  • a title for the advisory,
  • an overview and general description of the issue,
  • the impact of the issue,
  • a severity rating for the issue, for example, CVSS score or qualitative ranking,
  • references (CVEs or other security advisories),
  • a list of affected versions (if applicable),
  • any workarounds or alternative remediation which exist other than just upgrading the software,
  • credit for the person who found the issue (if applicable and desired),
  • revision history for the advisory,
  • contact information (if needed, may be a pointer to the project’s Contact page),
  • terms of use for the advisory (if needed, may be under same license as rest of the site’s documentation),
  • description of intended audience for the advisory (if needed, assumed to be the project’s users).

Advisories should have a consistent format and be signed by one of the PGP keys which is published on the Security page. Consistent format is important for rapid scannability by humans. Aggregate the security advisories on a single page with the pre-notifications on the same page. Bonus points if there is a subscription mechanism available for the information on this page. Don’t publish your advisory on a weekend or holiday if you can possibly avoid it. If your project is packaged by one or more distributions, let them know ahead of time that the fix is coming and coordinate with the distro embargo process.

You know your project better than anyone, so if these recommendations don’t work for your project, think about what does work and document your process. Remember the goal is to minimize risk and promote positive communication about vulnerabilities.

While nothing described here is novel nor unique, many open source projects are on the leading edge of working out the best practices for vulnerability disclosure. OpenSSH handled a recent vulnerability by openly recommending that users adopt a simple workaround hours before the vulnerability was disclosed. The Xen Project has thought long and hard about their vulnerability handling process which includes early notification to trusted cloud providers who would be disproptionally impacted (along with millions of cloud customers) by a serious vulnerability. And OpenSSL’s security policy nicely describes the rationale behind their vulnerability process.

I’m always happy to talk to anyone who is starting to develop (or document) the security project for their own project. Hit me up at eratliff at linuxfoundation dot org or ejratl at gmail dot com. You may be able to find me on IRC as ratliff.

CII Publishes 2016 Annual Report

By Blogs

The Core Infrastructure Initiative recently published a 2016 Annual Report that takes stock of our progress last year on all fronts — developers, audits and projects funded including OpenSSL, Open Source Best Practices Badge program, and Reproducible Builds; events held; and process changes to expedite the review and approval of funding requests.

Of particular interest is the chart on page 12 that visualizes CII funding by project, plotting each one by category – developer library or tool, educational effort, testing tool or project, system tool or application – as well as just how strategic or tactical each investment is. CII will continue updating this diagram moving forward.

Click here to check out the full report and to hear from our Executive Director Nicko van Someren and Programme Director Marcus Streets. We look forward to continuing this work in 2017.

Update on tis-interpreter

By Blogs

Pascal Cuoq has written an informative and amusing update on how the tis-interpreter is coming along. He hints at the power of false-positive free testing and talks about some of the results (and tribulations) that the team has seen so far while developing and testing the tool. They are currently honing the rough edges (usability and “embarrassing” bugs)  in preparation for a 2016 release as open source. I can’t wait to try it out.

Mozilla Announces “Open Source Support Program”

By Blogs

On Friday, Mitchell Baker, the Chair of the Mozilla Foundation, announced the creation of the “Mozilla Open Source Support (MOSS)” program. The program is being launched with $1m in seed money to support open source projects upon which Mozilla relies. The cool thing about this is that they are including projects which support Mozilla’s infrastucture in addition to code dependencies (i.e. they are including the suricata IDS project in the list of projects upon which they depend). They will be picking 10 projects to support by December 12, so be sure to check it out soon.

Kudos and thank you to the Mozilla Foundation for launching this program!

How to submit a proposal for a Core Infrastructure Initiative grant

By Blogs

One question which come up frequently is “How do I submit a proposal for a Core Infrastructure Initiative (CII) grant?” Grant proposals come to CII via many different avenues:

  • individual Steering Committee or Advisory Board members submit proposals or ideas
  • ideas get submitted to the cii-discuss mailing list for public review
  • proposals get submitted via the form on the website
  • informal contacts are made through networks.

The difference between an idea and a proposal is that an idea typically takes the form of “CII should do xyz” whereas a proposal takes the form of “John Doe would like to do the following work. It will have this effect and take this long. It will cost $x”. We are always happy hear both ideas and proposals.

If you have an idea for a grant for yourself and you need help formulating it into a proposal, I will personally be glad to help you. Submit the idea via the CII contact form and I will contact you to work together to craft a proposal.

If you have an idea for a grant for someone else, please contact that person and bring them along for the discussion.

If you have an idea for a grant, but you don’t know who the recipient should be, then this is a perfect topic for the cii-discuss mailing list. Ideas like ‘CII should fund a source code audit for the foo framework’, or ‘Project bar is used by everyone and they don’t even have an automated test suite’ are perfect for discussion on cii-discuss.

There are a couple of quirks to bear in mind when submitting a proposal. CII has a policy of providing grants to individuals rather than organizations, so each grant proposal must have the person’s name (or multiple people’s names) associated with the proposal. Funding decisions can be made on a rolling basis, so there is no deadline for proposal submission. Proposals can be made at any time. The term “core infrastructure” means different things to different people. CII uses a very broad definition of the term, but CII is primarily focused on improving the security and maintainability of open source software, so most successful grant proposals have some element of secure coding advocacy, testing, software development (whether of core infrastructure itself or of software development tools), or managing open source projects associated with them.

Finally, CII is not the only organization providing grants. If you have an idea or a proposal that doesn’t quite fit CII, but you want some information or contact to other funding organizations, then shoot me a mail or submit a question via the CII contact form and I will be glad to work with you to direct your inquiry in the most useful way that I can.