Bringing OpenStack vulnerability management processes to the Big Top started a couple months ago with creation of a deliverable tag called vulnerability:managed, the definition of which can be found at:
http://governance.openstack.org/reference/tags/vulnerability_managed.html Its initial application is based on a crufty old wiki page which previously listed what repos the VMT tracks for security vulnerabilities with no discernible rationale (later extended from repos to deliverables, as the TC decided against having per-repo tags). As such, the requirements to qualify for this tag are currently a rather dissatisfyingly non-transparent "ask the VMT and we'll finalize it with the TC." It's past time we fix this. In the spirit of proper transparency, I'm initiating a frank and open dialogue on what our criteria for direct vulnerability management within the VMT would require of a deliverable and its controlling project-team. In the past a number of possible requirements have been mentioned, so I'll enumerate the ones I can recall here along with some pros and cons, and others can add to this as they see fit... 1. Since the vulnerability:managed governance tag applies to deliverables, all repos within a given deliverable must meet the qualifying criteria. This means that if some repos in a deliverable are in good enough shape to qualify, their vulnerability management could be held back by other repos in the same deliverable. It might be argued that perhaps this makes them separate deliverables (in which case the governance projects.yaml should get an update to reflect that), or maybe that we really have a use case for per-repo tags and that the TC needs to consider deliverable and repo tags as separate ideas. 2. The deliverable must have a dedicated point of contact for security issues (which could be shared by multiple deliverables in a given project-team if needed), so that the VMT can engage them to triage reports of potential vulnerabilities. Deliverables with more than a handful of core reviewers should (so as to limit the unnecessary exposure of private reports) settle on a subset of these to act as security core reviewers whose responsibility it is to be able to confirm whether a bug report is accurate/applicable or at least know other subject matter experts they can in turn subscribe to perform those activities in a timely manner. They should also be able to review and provide pre-approval of patches attached to private bugs, which is why they are expected to be core reviewers for the deliverable. These should be members of a group contact (for example a <something>-coresec team in launchpad) so that the VMT can easily subscribe them to new bugs. 3. The PTL for the deliverable should agree to act as (or delegate) a vulnerability management liaison, serving as a point of escalation for the VMT in situations where severe or lingering vulnerability reports are failing to gain traction toward timely and thorough resolution. 4. The bug tracker for the repos within the deliverable should be configured to initially only provide access for the VMT to privately-reported vulnerabilities. It is the responsibility of the VMT to determine whether suspected vulnerabilities are reported against the correct deliverable and redirect them when possible, since reporters are often unfamiliar with our project structure and may choose incorrectly. For Launchpad, this means making sure that https://launchpad.net/<tracker-name>/+sharing shows only the OpenStack Vulnerability Management Team (openstack-vuln-mgmt) with sharing for Private Security: All. It implies some loss of control for the project team over initial triage of bugs reported privately as suspected vulnerabilities, but in some cases helps reduce the number of people who have knowledge of them prior to public disclosure. 5. The deliverable's repos should undergo a third-party review/audit looking for obvious signs of insecure design or risky implementation which could imply a large number of future vulnerability reports. As much as anything this is a measure to keep the VMT's workload down, since it is by necessity a group of constrained size and some of its processes simply can't be scaled safely. It's not been identified who would actually perform this review, though this is one place members of the OpenStack Security project-team might volunteer to provide their expertise and assistance. I still have a few open questions as well... A. Can the VMT accept deliverables in any programming language? OpenStack has a lot of expertise in Python, so it's possible for us to find people able to confidently review Python source code for unsafe practices. We have tools and workflows which make it easier to set up development and testing environments to confirm reported vulnerabilities and test fixes. For Python-based deliverables we have lots of solutions in place to improve code quality, and could for example even require that proposed changes get gated by bandit. On the other hand, all the VMT's work is on a best-effort basis, so it may simply be that non-Python deliverables interested in VMT oversight are willing to accept these shortcomings and the inefficiencies they imply. B. As we expand the VMT's ring within the Big Top to encircle more and varied acts, are there parts of our current process we need to reevaluate for better fit? For example, right now we have one list of downstream stakeholders (primarily Linux distros and large public providers) we notify of upcoming coordinated disclosures, but as the list grows longer and the kinds of deliverables we support becomes more diverse some of them can have different downstream communities and so a single contact list may no longer make sense. C. Should we be considering a different VMT configuration entirely, to better service some under-represented subsets of the OpenStack community? Perhaps multiple VMTs with different specialties or a tiered structure with focused subteams. D. Are there other improvements we can make so that our recommendations and processes are more consumable by other groups within OpenStack, further distributing the workload or making it more self-service (perhaps reducing the need for direct VMT oversight in more situations)? -- 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
