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 #openstack-meeting-alt


On Thu, Sep 1, 2016 at 4:38 PM, Ben Swartzlander <>

> 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[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]
>> [2]
>> y_managed.html#requirements
>> [3]
>> [4],members
>> [5]
>> bility_management
>> [6]
>> [7]
>> [8]
>> [9]
>> tree/doc/source/templates/
>> [10]
>> g/tree/zuul/layout.yaml
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> e
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack Development Mailing List (not for usage questions)

Reply via email to