Open Stack

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
-------------- 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/20150901/ee29ddd6/attachment-0001.pgp>