Reporting and tracking resolution of vulnerabilities in the post-Bugzilla era.

We had been using the "Vulnerability Reports" component on Bugzilla as a means for projects that do not have any other means of confidentially reporting and vulnerabilities. The bugs in that component have been "moved" into the Help Desk GitLab repository. Further, some new issues have been opened by community members and have been marked confidential.

AFAICT, confidential issues are only visible to team members with at least a Reporter level of privilege. This means that we currently have no means of including an arbitrary committer on these issues as long as they are marked confidential.

Help desk doesn't feel like the right place for these sorts of issues. Regardless, I'm assuming that granting Reporter level privileges on the Help Desk issues to arbitrary committers is off the table.

I discuss setting up private security mailing lists for projects in eclipsefdn/emo-team/emo#71 (moved). This is probably also related to #382 (closed).

I'm wondering what GitLab options may be available.

I started down a path of creating a Vulnerability Tracking repository with just an issue tracker, thinking that we could move the strictly project-related issues on Help Desk there and set up individual committers as reporters as necessary (infrastructure issues should go where-ever the IT team wants to put them).

Does anybody have any brilliant ideas?

/cc @mbarbero @cguindon @mward @droy @mdelgado624

added EMO Security labels

assigned to @wbeaton and @mbarbero

A global https://gitlab.eclipse.org/eclipsefdn/emo-team/vulnerability-tracking provides some benefit, as we can limit the access to a subset of EF staff (when help desk has much more than that: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/project_members). However, it does provide any isolation between projects as adding individual as reporter as necessary would grant them access to all issues in vulnerability-tracking. This is undesirable. So I would keep such a shared repo only as a parallel way to report issue to the Eclipse security team, and then delegate (see below) to the proper project. Btw, I think such a repo should be under https://gitlab.eclipse.org/eclipsefdn/security rather than emo-team.

Ideally, for Eclipse Projects on gitlab, we would need a dedicated repo per Eclipse Project, with a subset of committers/pl having access to it (maybe it defaults to all, but we would need the ability to only grant access to a subset of committers who can handle vulnerabilities). Anyone should be able to report a confidential issue in those.

It should probably be complemented with a private, per-project, security mailing list.

However, it does provide any isolation between projects as adding individual as reporter as necessary would grant them access to all issues in vulnerability-tracking

I completely agree. Note, though, that this is no worse that what we've provided in Bugzilla.

Ideally, for Eclipse Projects on gitlab, we would need a dedicated repo per Eclipse Project ...

GitLab supports marking issues as confidential. With that, aren't we done on GitLab? Other than details like issue templates and what-not...

Projects using Gerrit, must also be using Bugzilla which has a means of marking issues as "committers only", so I think that we're done on Gerrit as well. Although, moving issues from Help Desk is a PITA...

AFAIK, GitHub has no means of marking issues as confidential. So I think that what we're lacking is a solution for GitHub. Or am I missing something important?

However, it does provide any isolation between projects as adding individual as reporter as necessary would grant them access to all issues in vulnerability-tracking

I completely agree. Note, though, that this is no worse that what we've provided in Bugzilla.

We should aim for better :D

Ideally, for Eclipse Projects on gitlab, we would need a dedicated repo per Eclipse Project ...

GitLab supports marking issues as confidential. With that, aren't we done on GitLab? Other than details like issue templates and what-not...

Agreed.

Projects using Gerrit, must also be using Bugzilla which has a means of marking issues as "committers only", so I think that we're done on Gerrit as well. Although, moving issues from Help Desk is a PITA...

That's the use case of a dedicated vulnerability-tracking repo here at gitlab. I think we should move away from Bugzilla ASAP.

AFAIK, GitHub has no means of marking issues as confidential. So I think that what we're lacking is a solution for GitHub. Or am I missing something important?

It's true so far. For projects hosted at github, I guess the project-specific private mailing list is a must have. Also, we should convince projects to move out of the github.com/eclipse organization and use their own dedicated organization. This way, we can enable the — still in beta — security managers role for PL or committers. I've tested it in CBI, and beside granting access to some dependabots settings at org and repo levels to security managers, most importantly it provides the ability to create draft security advisories and private fork repositories (without being admin ^^).

added team:security label

marked this issue as related to #376 (closed)

I did some testing for @scorbett today around confidential issues and the behavior that I see, does not match Gitlab documentation. I would like to share this since it might help the conversation:

There are two kinds of level access for confidential issues. **The general rule is that confidential issues are visible only to members of a project with at least the Reporter role. **However, a guest user can also create confidential issues, but can only view the ones that they created themselves. Users with the Guest role or non-members can also read the confidential issue if they are assigned to the issue. When a Guest user or non-member is unassigned from a confidential issue, they can no longer view it.

I was able to create a confidential issue with a user who is not a member of the project: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1566

I also had access to view it without adding myself. However, the documentation state that only gues users can do this.

Did we update the config in GitLab to allow all users to create confidential issues?

Note: I logged in to my chrisguindon test account by using the impersonate admin feature. It's possible that the impersonate feature allows users to do more than what the actual user can do.

I am going to do another test by properly logging in.

I am sharing this information since I do think we want to allow all users to create a confidential issues but I am very perplexed on why this is working while the documentation says it shouldn't.

I think the issue here is a misinterpretation on my part of what is a guest user...

The guest user != a user with the guest role.

I did another test as a non-member and I can confirm that I was able to create a confidential issue: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1567

AFAICT, confidential issues are only visible to team members with at least a Reporter level of privilege. This means that we currently have no means of including an arbitrary committer on these issues as long as they are marked confidential.

This is not entirely true From GL Documentation:

Users with the Guest role or non-members can also read the confidential issue if they are assigned to the issue.

I think a problem we need to solve here is making sure that every committer has a Gitlab account which we can do with some updates to our sync script to allow the person responsible for triage in the security project to assign the right people.

I created a confidential using my main @cguindon account https://gitlab.eclipse.org/eclipsefdn/it/websites/api.eclipse.org/-/issues/7 and assigned it to @chrisguindon (non-member).

@chrisguindon (non-member) can view and post comments.

However, I needed to make the issue public for a few seconds to allow @cguindon to assign @chrisguindon which is not ideal.

I can't seem to be able to assign a non-member if the issue is already confidential...

marked this issue as related to eclipsefdn/it/websites/eclipse.org#153 (closed)

mentioned in issue eclipsefdn/it/websites/eclipse.org#153 (closed)

So, if I try sum up to current discussions, here are the ways we envision for someone to report a vulnerability to an Eclipse Project (from the broadest/most generic way, to the most specific)

Of course, we would encourage projects to specify the most specific way depending in their security policy file, depending on where they are hosted.

• security@eclipse.org
  • create an issue on the appropriate tracker
    • the foundation's vulnerability issue tracker for project at github (until confidential issues are a thing)
    • the project's gitlab vulnerability issue tracker
  • and/or forward to project's security mailing list
• foundation's vulnerability issue tracker.
  • public (anyone can create issues)
  • confidential issues by default
  • current Eclipse security team as developer on it
  • any user can get visibility on issue by assigning the issue to them (via quick actions, as via UI it does not propose non-members)
• per project private mailing
  • members are project's security team + PMC security team
  • important for projects @ github until there is a way to create private issues (soon?)
• per project vulnerability issue tracker
  • for gitlab projects only.
  • located outside of standard project's group hierarchy as only project's security team has privileges (+ pmc security members for oversight?)
  • public (anyone can create issues)
  • confidential issues by default (only members of the projects — aka project's security team — can see all issues)
  • any user can get visibility on issue by assigning the issue to them (via quick actions, as via UI it does not propose non-members)

WDYT?

As GitHub now has the private reporting, we have a very similar flow for both GitHub and GitLab.

unassigned @wbeaton

I think we're done with this one. WDYT @mrybczyn?

removed EMO label

closed