Open Stack

Ben has proposed[1] adding manila, manila-ui and python-manilaclient
to the list of deliverables whose vulnerability reports and
advisories are overseen by the OpenStack Vulnerability Management
Team. This proposal is an assertion that the requirements[2] for the
vulnerability:managed governance tag are met by these deliverables.
As such, I wanted to initiate a discussion evaluating each of the
listed requirements to see how far along those deliverables are in
actually fulfilling these criteria.

1. All repos for a covered deliverable must meet the criteria or
else none do. Easy enough, each deliverable has only one repo so
this isn't really a concern.

2. We need a dedicated point of contact for security issues. Our
typical point of contact would be a manila-coresec team in
Launchpad, but that doesn't exist[3] (yet). Since you have a fairly
large core review team[4], you should pick a reasonable subset of
those who are willing to act as the next line of triage after the
VMT hands off a suspected vulnerability report under embargo. You
should have at least a couple of active volunteers for this task so
there's good coverage, but more than 5 or so is probably pushing the
bounds of information safety. Not all of them need to be core
reviewers, but enough of them should be so that patches proposed as
attachments to private bugs can effectively be "pre-approved" in an
effort to avoid delays merging at time of publication.

3. The PTL needs to agree to act as a point of escalation or
delegate this responsibility to a specific liaison. This is Ben by
default, but if he's not going to have time to serve in that role
then he should record a dedicated Vulnerability Management Liaison
in the CPLs list[5].

4. Configure sharing[6][7][8] on the defect trackers for these
deliverables so that OpenStack Vulnerability Management team
(openstack-vuln-mgmt) has "Private Security: All". Once the
vulnerability:managed tag is approved for them, also remove the
"Private Security: All" sharing from any other teams (so that the
VMT can redirect incorrectly reported vulnerabilities without
prematurely disclosing them to manila reviewers).

5. Independent security review, audit, or threat analysis... this is
almost certainly the hardest to meet. After some protracted
discussion on Kolla's application for this tag, it was determined
that projects should start supplying threat analyses to a central
security-analysis[9] repo where they can be openly reviewed and
ultimately published. No projects have actually completed this yet,
but there is some process being finalized by the Security Team which
projects will hopefully be able to follow. You may want to check
with them on the possibility of being an early adopter for that
process.

6. Covered deliverables need tests we can rely on to be able to
evaluate whether privately proposed security patches will break the
software. A cursory look shows many jobs[10] running in our upstream
CI for changes to these repos, so that requirement is probably
addressed (I did not yet check whether those
unit/functional/integration tests are particularly extensive).

So in summary, it looks like there are still some outstanding
requirements not yet met for the vulnerability:managed tag but I
don't see any insurmountable challenges there. Please let me know if
any of the above is significantly off-track.

[1] https://review.openstack.org/350597
[2] https://governance.openstack.org/reference/tags/vulnerability_managed.html#requirements
[3] https://launchpad.net/~manila-coresec
[4] https://review.openstack.org/#/admin/groups/213,members
[5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
[6] https://launchpad.net/manila/+sharing
[7] https://launchpad.net/manila-ui/+sharing
[8] https://launchpad.net/pythonmanilaclient/+sharing
[9] https://git.openstack.org/cgit/openstack/security-analysis/tree/doc/source/templates/
[10] https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml

-- 
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/20160830/d8ab7463/attachment.pgp>