On 2016-03-31 15:15:23 -0400 (-0400), michael mccune wrote: [...] > * what is the process for performing an analysis > > * how will an analysis be formally recognized and approved > > * who will be doing these analyses
I intentionally didn't specify when writing the vulnerability:managed tag description but instead only gave an example, as the details of who can review a project and how will vary depending on its scope, language, and so on. I was trying to keep it vague enough to be applicable to all sorts of projects, but I see now that lack of specificity is leading to additional confusion (which makes me fear we'll be forced instead to encode every possible solution in our tag description). > * does it make sense to keep the analysis process strictly limited > to the vmt [...] Not at all. Providing security feedback to projects seems beneficial regardless of whether they're going to have vulnerability reporting overseen by the OpenStack VMT or plan to handle that on their own. On the other hand, some volunteers may choose to limit their assistance to projects applying for the vulnerability:managed tag as a means of keeping from getting spread too thin. > ultimately, having a third-party review of a project is worthy > goal, but this has to be tempered with the reality that a single > team will not be able to scale out and provide thorough analyses > for all projects. to that extent, the ossp should work, initially, > to help a few teams get these analyses completed and in the > process create a set of useful tools (docs, guides, diagrams, > foil-hat wearing pamphlets) to help further the effort. > > i would like to propose that the threat analysis portion of the > vulnerability:managed tag be modified with the goal of having the > project teams create their own analyses, with an extended > third-party review to be performed afterwards. in this respect, > the scale issue can be addressed, as well as the issue of project > domain knowledge. it makes much more sense to me to have the > project team creating the initial work here as they will know the > areas, and architectures, that will need the most attention. [...] This seems fine. The issue mostly boils down to the fact that the VMT used to perform a cursory security review (skim really) of a project's source code checking for obvious smells to indicate that it might not be in a mature enough state to cover officially for vulnerability reporting oversight without creating a ton of additional work for ourselves the first time someone pointed an analyzer at it. As a means of scaling the VMT's capacity without scaling the size of the VMT, in an effort to handle the "big tent" model, this sanity check seemed like something we could easily delegate to other interested volunteers to reduce our own workload and help us cover more and a wider variety of projects. -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
