Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160412/ac81c430/attachment.pgp>