Luke Hinds wrote: > On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley <[email protected] > <mailto:[email protected]>> wrote: > >> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote: >>> [...] >>> I think the Security project team would benefit from becoming a >>> proper SIG. >>> [...] >> I tend to agree, though it's worth also considering what the >> implications are for vulnerability management under the new model. >> The VMT tended to act as an independent task force in the >> beforetime, until the big t^W^Wproject reform of 2014, and then >> allied itself with the newly-formed Security Team while continuing >> operation autonomously under a fairly independent mandate. Does this >> still make sense in a Security SIG context, or should we be >> considering alternative (perhaps more formal?) governance for the >> VMT in that scenario? I don't have especially cogent thoughts around >> this yet, so interested to hear what others in the community think.
So the activity of the Security project team can be split into a number of things: - Security advisories for supported projects (ossa by the VMT subteam) - General security notices / information (ossn) - Promotion of secure coding practices (bandit, syntribos) - Promotion of secure operations (security-doc, anchor) - Audit activities (security-analysis) The only thing here that is not performed by an open group is the VMT stuff. It also happens to be the most "upstream" of all the team activity: it's closely related to stable branch maintenance. Personally I think the VMT would be better split off from a Security SIG -- it's suboptimal to have a part of a SIG to be a restricted group. It could be made it's own team, or attached to an existing group (stable branch maintenance) or converted to a TC-owned "workgroup" (a TC delegation of power, like it's always been). > We discussed the SIG proposal on the security meeting and I planned to > invite you in for a session to discuss Thierry (apologies for being late > for getting this together). > > Overall folks thought it an idea worth while enough to explore further. > > My own view is that if its leads to getting more eyes on security, then > its a good thing. With that in mind, I had the idea that we could run a > "Security SIG" in parallel to the security project and see if it gains > traction and security minded people from the wider community do actually > come forward to get involved and merit the change worth while (and it's > not just the Security Project rearranging the furniture). We could then > review how its gone at the end of the Queens cycle and if a success (not > sure how we would define that as yet), then implement the change at the > juncture of a new release. Sure, we can definitely try it out and keep the project team around while we try. The only issue I see with that approach is that it's a bit confusing, and not as strong of a statement compared to saying "all the security activity now happens there". But if you feel more comfortable that way, we can definitely follow that road. -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
