Once Upon a CVE: Managing Security Events as an Upstream

As an upstream software provider, it is your duty to ensure your software’s consumers are educated and notified when security issues are uncovered. Even when everything goes well, security events disrupt work and distract teams. When things go poorly, users can be attacked and lose faith in your software, causing long-term damage to your project’s reputation. This talk will dive into handling security events from the moment they’re discovered until new packages are released, including:

Validating issues

Conducting impact analysis

Working with Mitre to get a common vulnerability exposure (CVE) number assigned

Communicating with downstream distributions, such as Fedora, Debian, and Ubuntu

Communicating with end-users

Conducting post-mortems

What to do if a vulnerability isn’t responsibly disclosed

Recognizing those trying to make your project more secure

Relying on other components that may have security vulnerabilities

Creating a security response process for your project

After we discuss high-level process, we’ll walk through several scenarios Puppet has encountered in the last 18 months, detailing how we partnered with Linux distributions to distribute patches, how we practiced responsible disclosure, and how we’ve dealt with the downstream impacts of some well-known (and sometimes vulnerable) Ruby libraries.

People planning to attend this session also want to see:

Michael Stahnke

Puppet Labs

Michael Stahnke is the Director of Software Delivery at Puppet Labs, where he was previously the Community Manager and where he built out the Release Engineering team as Release Manager. He came to Puppet Labs from Caterpillar, Inc. where he was an Infrastructure Architect, system administration team lead, and open source evangelist. Michael also helped get the Extra Packages for Enterprise Linux (EPEL) repository off the ground in 2006, and is the author of Pro OpenSSH (Apress, 2005).