Open Stack

On Tue, Aug 30, 2016 at 6:07 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 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.

Given that all the drivers live in the Manila repo, will this
requirement for security audits is going to apply to them?  Given the
variety of technologies and network protocols involved in talking to
external storage systems, this strikes me as probably the hardest
part.

John

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>