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.

Open Sourcing the Census Project

By Blogs

The Census  Project, developed by David Wheeler and Samir Khakimov of the Institute for Defense Analyses (IDA), goes live today! CII co-funded the Census Project to automate analysis on a large number of open source projects to come up with a quick way to prioritize which projects to look at more closely. The Census Project calculates a “risk score” based on a number of metrics about the project, some of which are relatively static (language, website, network access) and some of which change over time (contributor count and popularity).

The results are fascinating.The Census Project is very, very good at identifying projects which are still widely popular, but which are hardly maintained. This is the sweet spot for the Core Infrastructure Initiative to look into to try to identify lurking issues and help find a way to fix them before they become problems for our core infrastructure.

The development team did an amazingly comprehensive overview of prior art before settling on the metrics in the program (check it out yourself in Section 2 of the whitepaper), but it is fun to speculate and even experiment with alternative metrics. For example, Florian Weimer suggested including the Fedora ABRT crash statistics, which I think is an inspired idea because, in aggregate, the crash reports are less game-able than CVE counts, include a nod to popularity, and show whether or not potentially critical issues are actually being fixed by projects.

We hope that this is the beginning of the discussion about which (automatable) metrics are important to assessing a project’s risk. I would like to invite you to provide feedback on the project, propose new projects to assess, help clean up the input data, and experiment with different metrics.

A big thank you goes out to Black Duck’s Open Hub and the Debian project for allowing the Census Project to use data from their sites to perform the calculations.

For more information, you can visit the websitedownload the code, and read the paper (in short form if you are in a hurry).

Introducing Myself to the CII Community

By Blogs

I am very excited to be joining The Linux Foundation as the senior director of infrastructure security to work on The Core Infrastructure Initiative. The challenge of securing software is not new, nor is it isolated to open source. What is unique right now though is how everyone has increasingly come to rely upon shared code to foster innovation and speed time to market. Research shows 90 percent or more of modern applications, both commercial and non-commercial, contain third-party open source code. As adoption grows, we have to ensure that critical open source software is supported, protected, and fortified.

Fortunately, without a moment’s hesitation last year, many rallied around the Linux Foundation to create the Core Infrastructure Initiative, a multi-million dollar project comprised of technology companies, security experts and developers, all of whom are committed to working collaboratively to identify and fund critical open source projects in need of assistance.

This is an incredibly important time for CII. The stakes have never been higher for open source software. Working together, I believe CII has the potential to make a major impact on the security of technology that we all use every day. And CII has made a difference already. Since CII started, we’ve seen improvement in the bug closure rate on funded projects.

Open source software encompasses a whole range of projects, some of which have strong vibrant communities around them and some which scratched a single developer’s itch. Our mission is to identify which of the most critical projects are the weakest and would benefit from help to become stronger. Beyond the initial triage, we’ll be focusing on industry best practices for secure open source development to further foster a culture of secure coding practices.

CII recently announced nearly $500,000 in new grants to support three very different, but important projects: 1) a new testing project leveraging Frama-C, 2) the Reproducible Builds initiative from Debian, and 3) the Fuzzing Project. Tools can be very expensive to create and use but can be a very effective force multiplier. I hope that CII’s investments in tooling will pay off in improved security for many projects. With these investments, CII is moving beyond ad-hoc, reactionary bug fixes to advance tooling projects that a wide number of projects can leverage to proactively improve security.

I am grateful to the Linux Foundation and the CII Steering Committee for entrusting me with this mission. When I first heard of the creation of the Core Infrastructure Initiative back in April 2014, I took the long overdue step of joining the Linux Foundation as an individual member, never dreaming that I would get this opportunity to actively foster the initiative. I have been advocating for, using, and contributing to open source software for a long time. I believe that open source software is more secure than people give it credit for (especially during the dark days of Shellshock and Heartbleed) and simultaneously not secure enough – more must be done. Open source software is not unique in this regard. It is a pet peeve of mine when people make bold proclamations about the security of open source without acknowledging that there exists a wide range of requirements, capabilities and practices in open source projects, just as in closed source. What is important is that we all come together to make sure that our most critical open source software is being cared for at a level that will ensure that it is responsive to vulnerability disclosure, proactively identifying and refactoring problematic code, performing positive and negative testing appropriately, and using the best tools available.

Improving cyber security will never be light work; our members know that many hands are needed to dramatically reduce global threats to online security.  I’m honored to be working with the industry’s largest tech giants — Amazon Web Services, Bloomberg, Cisco, Dell, Facebook, Fujitsu, Google, Hitachi, HP, Huawei, IBM, Intel, Microsoft, NetApp, NEC, Qualcomm, RackSpace,, and VMware — on this critical endeavor.

CII is committed to fostering open source innovation and secure development practices. We have an amazing program in the making and we can make a difference. We need your help to make this work. Whether your interest is in best open source development practicessurveying open source communitiesdeveloping new toolssuggesting a grant or just general discussion about CII – we want to hear from you.


Emily Ratliff

Deep Dive on CII’s Best Practices Badge Program on

By Blogs

Earlier this month, we announced the Core Infrastructure Initiative (CII) Best Practices Badges Program, a free program that seeks to determine security, quality and stability of open source software.

We received many inquiries from interested companies and developers for additional information about the CII badge program after its launch. Addressing the program’s most pressing questions on are Emily Ratliff, senior director of infrastructure security at The Linux Foundation and Dr. David Wheeler, open source and security research expert.

Determining software security is an industry-wide challenge for both proprietary and open source. The CII Best Practices Badge Program addresses this challenge by helping projects determine if they meet open source best practices quickly (generally, in less than an hour) and through a trusted source. Projects displaying a CII badge showcase the project’s commitment to security.

Read the Q&A here.