Proposal: Gives Security Manager role to the Security team in Github xwiki and xwiki-contrib organizations

Development
,
1

Hi everyone,

we currently have a Github Security Team in both Github Organizations xwiki and xwiki-contrib. Those teams have been primarily created to allow people belonging to those teams to have access to the draft advisories: this is done right now by manually adding the team as collaborator of each new draft security advisory created.

But we never really discussed who should be able to open draft security advisories on our repositories. In https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/#HWhat2019stheprocesstohandlesecurityissues3F we say that ones should ask a committer to take ownership of a security issue, but we don’t say anything regarding the creation of the draft advisory.

In practice right now only the administrators of the repositories have the capabilities to create them: right now it means it’s the committers (or admins of contrib repositories).

My proposal is to extend that, to allow all members of the Security teams to be able to open draft advisories, by giving to the team the Security Manager role.

In practice, it still mean a committer will have to take ownership of security issues, to actually push the fixes, but a security contributor might be able to do the actual work, create the draft advisory, open a fork and propose the fix inside the fork.

The Security Manager role also gives a more rights to the people (taken from Github’s official doc):

  1. Read access on all repositories in the organization, in addition to any existing repository access
  2. Write access on all security alerts in the organization
  3. The ability to configure settings for security features at the organization level, including the ability to enable or disable GitHub Advanced Security features
  4. The ability to configure settings for security features at the repository level, including the ability to enable or disable GitHub Advanced Security features

One interesting side effect that I’m seeing, is that this role also gives people belonging to the group immediate access to all draft advisories, without needing anymore to add the group as a collaborator. So it simplifies a bit the creation of advisories.

Also I consider that people in this group are already people we trust, so giving them a bit more power should be ok IMO.

WDYT?

2

+0

Thanks,
Marius

3

Afaics this proposal has now drawbacks, so +1

4

+1

5

This means that a non-committer (ie a contributor with security access) would be able to create an advisory without creating a confidential jira issue. That doesn’t look great to me. It’s not an issue for committers since they know the workflow and that we need a jira issue.

So they’d be able to work in the advisory branch but without posting a PR for the jira issue?

I’m failing to see what is the reason for this proposal and what it fixes. Right now, anyone can create a confidential jira issue and open a PR for it. The only problem (and maybe this is what you wan to fix) is that if they’re not careful in the wording in the PR, they’ll disclose the issue publicly before we’re reading to disclose the CVE. But if that’s the issue you’re trying to fix, they’d still be able to provide a PR so not sure it would fix that issue.

Not sure what this does and what are the UCs where we’d want security contributors to send “security alerts”. I need to research what they are.

Why would we want to allow contributors to do that? That seems like a bad idea.

Right now I’m close to -1. Let’s say I’m -0 strongly. Especially because being able to change our security settings is a no go for me (without being a committer).

That’s probably because I don’t understand the need and what triggered this proposal.

Thanks

6

I think you probably meant “no” (and not “now”) :wink: I do see several drawbacks (see my post above).