Security Policy Amendment for allowing new security members

Hi everyone,

I’m opening this proposal because we noticed some exceptions related to the documented practice in the policy and I’d like to clarify current process.

As you probably know XWiki SAS is currently the main sponsoring company of XWiki, I’m an employee of this company and I have colleagues hired in XWiki SAS also working on security topics. And so I started to grant access to a few of those colleagues (2 of them AFAIK) based on a simple request on XWiki Matrix channel, instead of going to the full process of requesting the access on this forum.

In order to be transparent, we will ask those people to present themselves on the forum to formalize those access.

But I’d like to propose to amend the process to allow people having a security position in a sponsoring company of XWiki to be able to get more easily access to the security resources. The way I see it would be like that:

  • each sponsoring company defines one or two security delegates, responsible of handling this (which are documented on the policy page)
  • those delegates grants access to the employees following rules already defined in the policy like for other security members
  • after the fact, delegates publish on the forum the list of new people that got access for sake of transparency

WDYT?

In general, +1, but I would like to specify/clarify some points:

  1. The security delegates need to be committers.
  2. The security delegates need to remove the security access again when an employee leaves the company (unless the employee should be a committer).

Further, I feel like we should introduce an (internal) audit trail who got security access for what reason that cannot easily be tampered with that allows us to easily remove that security access again, even when, e.g., a company should stop being a sponsoring company. Sure, we have the forum threads, but it feels very cumbersome to get all the information from that, in particular as it might not be obvious which usernames are associated with a person.

An interesting option could also be to introduce a requirement to renew security access, say, once per year (this could again be handled by the security delegate for sponsoring companies) - basically to perform a quick check/confirmation that the access is still needed, to avoid that we have an ever-growing list of people with access who might not need the access anymore and whose accounts might be compromised.

Thank you very much!

I like the idea. But someone has to be assigned this task.

How will the people (outside the sponsoring companies) be contacted for the review?

I think we do need that indeed to handle also properly the offboarding. But we should make a dedicated proposal for it with a clear process, I’ll try to write that soon. It might also be related with offboarding / check of committers status that we don’t do often right now: same person could do both tasks at same time. (actually it’s a good hackathon idea to have some kind of app for managing this)

So as said above we need to clarify this, but IMO we’d use email.