Jeremy hit all the major points there.
What we do is basically model things based on a best-practice use case, we
rely on the project to make good choices in this regard with a view to
configurations, protocols etc.
Then we conduct an asset-oriented threat review, during which we create
documentation that looks a lot like
It's not overly heavyweight and provides us with enough information to make
some reasonably in-depth judgements and provide advice on areas where a
project might have some weaknesses in design or implementation.
A good first step is to say hello during one of our IRC meetings, 1700 UTC
On Thu, Sep 1, 2016 at 4:38 PM, Ben Swartzlander <b...@swartzlander.org>
> Thanks fungi. I misunderstood the full scope of the requirements for
> vulnerability management and since we don't yet have volunteers willing to
> perform all the required duties, I'm going to withdraw the tag request.
> As soon as interested community members step up to take on the
> responsibilities I'll reapply for the tag.
> -Ben Swartzlander
> On 08/30/2016 01:07 PM, Jeremy Stanley wrote:
>> Ben has proposed 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 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 (yet). Since you have a fairly
>> large core review team, 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.
>> 4. Configure sharing 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 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
>> 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 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.
>>  https://review.openstack.org/350597
>>  https://governance.openstack.org/reference/tags/vulnerabilit
>>  https://launchpad.net/~manila-coresec
>>  https://review.openstack.org/#/admin/groups/213,members
>>  https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnera
>>  https://launchpad.net/manila/+sharing
>>  https://launchpad.net/manila-ui/+sharing
>>  https://launchpad.net/pythonmanilaclient/+sharing
>>  https://git.openstack.org/cgit/openstack/security-analysis/
>>  https://git.openstack.org/cgit/openstack-infra/project-confi
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)