Including tc and kolla Michael,
Sounds good. I'll get the governance changes rolling for debate at the next TC meeting. Note I added this cross project topic for discussion Tuesday at summit (last item in the list) https://etherpad.openstack.org/p/newton-cross-project-sessions Regards, -steve On 3/31/16, 12:15 PM, "michael mccune" <m...@redhat.com> wrote: >hey all, > >at the most recent ossp meeting[1], there was some extended discussion >about threat analysis and the work that is being done to push this >forward. > >in this discussion, there were several topics brought up around the >process for doing these analyses on current projects and how the ossp >should proceed especially with respect to the "vulnerability:managed" >tag[2]. > >as for the threat analysis process, there are still several questions >which need to be answered: > >* what is the process for performing an analysis > >* how will an analysis be formally recognized and approved > >* who will be doing these analyses > >* does it make sense to keep the analysis process strictly limited to >the vmt > >* how to address commonalities and differences between a developer >oriented analysis and a deployer oriented analysis > >these questions all feed into another related topic, which is the >proposed initial threat analysis for kolla which has been suggested to >start at the upcoming austin summit. > >i wanted to capture some of the discussion happening around this topic, >and continue the ball rolling as to how we will solve these questions as >we head to summit. > >one of the big questions seems to be who should be doing these analysis, >especially given that the ossp has not formally codified the practice >yet, and the complexity involved. although currently the >vulnerability:managed tag suggests that a third party review should be >done, this may prove difficult to scale in practice. i feel that it >would be in the best interests of the wider openstack community if the >ossp works towards creating instructional material that can empower the >project teams to start their own analyses. > >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. > >as the ossp build better tools for generating these analyses they will >be in a much better position to guide project teams in their initial >analyses, with the ultimate goal of having the ossp, and/or vmt, perform >the third-party audit for application of the tag. i have a feeling we >will also discover much overlap between the developer and deployer >oriented analyses, and these overlaps will help to strengthen the >process for all involved. > >finally, the austin summit, and proposed kolla review, provide a great >opportunity for the ossp to put "rubber on the road" with respect to >this process. although a full analysis may not be accomplished during >the summit, we can definitely achieve the goal of defining this process >much better and creating more guidance for all projects that wish to >follow this path, as well as having kolla solidly on the way to having a >full threat analysis ready for third-party review. > >thoughts? > > >regards, >mike > > >[1]: >http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31- >17.00.log.txt > >[2]: >http://governance.openstack.org/reference/tags/vulnerability_managed.html > >[3]: https://review.openstack.org/#/c/220712/ > >__________________________________________________________________________ >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 __________________________________________________________________________ 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
