Document the Kata vulnerability reporting and processing procedures

[grahamwhaley]

Kata should have a formal method, and team to back that method, for reporting vulnerabilities via a responsible disclosure process. Document in this repository:

• how to submit a report
• the privacy of such reports
• who receives and handles the reports
• how are the reports handled
• what are the expected timelines
• how are vulnerabilities fixed
  • along with any mitigation details or backports
• how are vulnerabilities disclosed and published
  • to downstream stakeholders
  • publicly

Where possible, diagram the flows and timelines and provide example templates for reporting and disclosing.

[grahamwhaley]

@annabellebertooch @jessfraz @tallclair @egernst I see a couple of paths forward here. Either: 1) I mostly clone an existing vulnerability reporting flow, most likely from either OpenStack or k8s here and here, and edit as appropriate. 2) Or I write up our own, initially probably slightly simpler, flow, deriving much inspiration from the above links.

I started down (2), as I suspect taking (1) might drop us immediately into something potentially a bit heavy for the project at this point in time - but I'd like to garner your input and previous experience here from putting such things together. If you think we can basically clone one of the above (or if you have any other suitable flows that might fit better), and make that workable for Kata, then let me know.

Otherwise, I'll continue on (2) for now and see how it pans out.

[fungi]

As I'm on the OpenStack VMT and also heavily involved with the Zuul project, I'm working on adapting a derivative of the OpenStack VMT process for use by Zuul. The initial change with reporting guidelines is at https://review.openstack.org/554352 but will be followed by guidelines for vulnerability managers and for developers working on embargoed patches.

I gave a talk about free/open software community vulnerability management at OSCON a few years ago you might also want to have a look at, wherein I cover some of the dynamics and inherent contradictions you need to juggle: https://www.safaribooksonline.com/library/view/oscon-2015-video/9781491927991/video218413.html http://fungi.yuggoth.org/presentations/2015-oscon.rst

[ttx]

I would say the two paths are valid - starting from an existing policy and weed out the irrelevant parts, or drafting your own looking at others for inspiration. It might be easier to do the former, as you're pretty sure not to overlook anything that way.

FWIW, the OpenStack embargoed vulnerability process is an evolution of the process I originally wrote for Gentoo a long time ago. Its key aspect is defining steps in the process at which to add more "people in the know", balancing the number of humans needed to resolve the bug with the inevitable risk of leak as you add people. The rest of just process (written-down to limit human error) and policy (choices in terms of embargo windows etc.).

[grahamwhaley]

Thanks @fungi @ttx . I'm most of the way through taking the OpenStack doc and reworking it for Kata. @fungi - I don't suppose you drew the diagram with some nice open source tooling, and have the original sources for that do you? (as in something more 'editable' than a png that I can check into github as the source to the diagram/png?) - before I go re-create it ;-)

[ttx]

It was done in 2013 using LibreOffice Draw, let me see if I can dig the source version from my backups :)

[ttx]

Oh actually that was a Google drawing. I can share it with your preferred Google address.

[grahamwhaley]

Thanks @ttx that'd be great. email is (break apart to avoid the robots....) firstname.lastname@gmail.com - so that'll be graham.whaley :-)

[ttx]

Done!

[grahamwhaley]

Thanks @ttx Got it. Exported as svg, and inkscape seems pretty happy editing it. If that pans out, I'll put the svg into the PR.

[grahamwhaley]

First draft uploaded in PR #39 . There are FIXMEs littered around at places where we need to decide what to do or put some infra in place to then reference. many thanks to @ttx @fungi and all others involved in the OpenStack VMT page, from which this PR is heavily derived...

Having worked through this document, I don't think it is 'too heavy' for Kata to follow - but, open to opinions here.

@annabellebertooch - please CC in others as you feel necessary - either from the arch or the working committee etc.

[fungi]

One thing that merits mentioning, don't let hammering out the details of automation delay you putting your process into practice. For example, the OpenStack VMT originally followed an entirely manual process and over time added increasing amounts of automation where we saw we were spending more time and could realize some worthwhile gains. When you're first starting out it's totally reasonable to write up advisories and post them somewhere (a blog, a wiki, whatever's easy) and send copies to some mailing lists to let people know. Whatever process you're going to follow needs to be possible to perform in a completely manual fashion anyway so that your automation doesn't delay publication if it's broken. We even found it useful to prove out new processes manually at first before automating, providing an opportunity to fine-tune them and avoiding the trap of premature optimization.