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
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