Security group required for Tractus-X for internal Catena-X security team

Summary

Hi guys,

as discussed in this ticket here with netomiThomas Neidhart we currently have no committers by the security team that CAN SEE the security advisories due to view rights. To solve this we would like to be added to each product in the Tractus-X repo with READ rights.

Our Request To EF:
To achieve this efficientely it was suggested to create a separate team for the organization for all security team members and add that team as security managers for the organization.
Otherwise each product owner has to add each one of us with view rights to his product repository.

The following GitHub Handles have to be added:

@szafrugr

@RoKrish14

@DnlZF

@ZFLokesh

@ssirkc

@PiotrStys

@Gitleena

@klaudiazf

@mm73628486283

@guenterban

@szymonkowalczykzf

Kind regards
Kristian Cicka

Priority

• Urgent
• High
• Medium
• Low

@sigi + @sebastianbezold can you approve this request?

This has been created by the sig-security team of Tractus-X.

Kind regards

Kristian Cicka @ssirkc

Hi @ssirkc,

I think this should be approved by project leads: @sigi, @dmiehle and @bjoeroy.

added IT-prioritylow IT-severitylow ~16280 labels

So I checked the GitHub handles, and all of them are contributors to the project only.

We can certainly create a team within the organization but I am unsure what permissions we can give the team.

Rather than granting this team the security manager role in the organization, we can grant them access to security alerts on a repo level:

@mbarbero @wbeaton can you chime in here?

@netomi can repository owners still add this kind of group then to the repo collaborators? Our goal is to get advisories visible for this group of people, without adding each one of them to all repositories. Not sure how much rights would be needed for the default config of this group then.

changed the description

From what I can tell, the situation seems to resemble the one described in #1709. It's important for us to progress on this matter since it's frequently requested by mature projects.

The primary concern is ensuring that members of the security team are given access in a way that aligns with the Eclipse Development Process (EDP), particularly its core values like vendor neutrality, meritocracy, and transparency.

This is infact a very similiar request from what I take from the linked issue. Especially this description:

"We have people we wish to include in evaluation of vulnerability disclosures, advise on solutions, and contribute to disclosure records and fix implementations. These are not project leads and in fact may not all be committers on the project code (e.g. analysts). This is a project-level parallel to the current eclipsefdn-security team membership who have required rights at the foundation level.

I would not force the overlap with existing groups (committers/PMC members), but rather allow for the group of security managers to be defined at the project level in a flexible fashion to allow for managing security alerts."

In our case the security team is vendor neutral and consists of people from all companies that take part in this publicly funded project. These and of course any commited project collaborateur can participate in this group, if the skills in regards of security are there. The access mainly would aim to give only the tools necessary to view advisories and help with any kind of security incident.

I would not force the overlap with existing groups (committers/PMC members), but rather allow for the group of security managers to be defined at the project level in a flexible fashion to allow for managing security alerts."

How do we decide who is a member of this "security managers" group? IMHO, having committer status (i.e., being a member of the committer team) is a minimum requirement.

The current security group consist of about 10 people, who also do capacity planing and onboarding of new members. This group checks on the necessity if more people are needed and at some point will also do all the checks of voluntary members. For now this process is given. The group can currently perform these decisions within themselves.

@wbeaton thats our current issue: If you are activly working as a security person, the chances are you do things in the background like security scans, analysing results, telling people to change things etc.

We had this discussion internally and i did propose a sig-security which could suggest committers which are not as visual active in the community as developers, but it might help/make it easier if committers could thumbs up on people from the security team as the sig-security approach would mean giving them more permissions than they need (they could merge PRs)

@mbarbero & @wbeaton how do you like the sig-security idea? Do you have experience in how other projects do it? Do all others always do a committer election for their security experts?

@mrybczyn and I made a proposal in our latest comment in #1709 (comment 1702323). Would such an implementation would work for you?

Absolutly: "We should consider establishing a process that allows a project to determine if all committers are automatically included in the security team, eliminating the need for a separate election. Perhaps this could require approval from the PMC?"

I would also prefer a separate election/security team.

mentioned in issue #1709