Announcement: Per-Project Security Teams

[mbarbero]

In response to requests from various projects and after discussions between the Eclipse Foundation Security Team and the Architecture Council, we are pleased to announce the creation of Project Security Teams.

Project Security Teams allow projects to explicitly designate individuals responsible for handling vulnerability reports. Project Leads can define membership in PMI.

This initiative represents a significant step forward in enhancing visibility and communication around security issues within the Eclipse Foundation community.

If all Committers in your project are involved in addressing security issues, nothing will change for you. All Committers will automatically be considered part of your Project Security Team, and no further action is required on your part.

However, if your project has a more complex structure with only a limited number of individuals managing vulnerability reports, Project Leads can establish a dedicated Project Security Team.

Additionally, please be aware that in early September, all members of Project Security Teams for projects hosted on GitHub (in an organization other than https://github.com/eclipse) will be granted the Security Manager role. If your project does not make any changes in PMI by then, and in line with the default setting where the Project Security Team equals all Committers, all Committers will be granted the Security Manager role in their respective organization on GitHub.

The Foundation's policy of openness remains unchanged: all security issues will continue to be eventually disclosed, and the Eclipse Foundation Security Team will ensure that this practice continues.

For detailed information on the introduction of Project Security Teams, including the specific permissions granted to members, please refer to the updated Handbook.

(announcement also posted to the eclipse.org-committers mailing list https://www.eclipse.org/lists/eclipse.org-committers/msg01448.html)

[scottslewis]

However, if your project has a more complex structure with only a limited number of individuals managing vulnerability reports, >Project Leads can establish a dedicated Project Security Team.

Questions:

How can project leads without resources establish such a Security Team?
Who will be on the Project Security Team?
What will be done for security issues that are from the use of third-party libraries?

[scottslewis]

Our goal is not to burden existing project committers with additional responsibilities, but rather to empower them by providing access to resources they previously couldn't access—such as through the GitHub Security Manager role.

And I'm telling you/EF: no matter how many 'authorities' you consult, you ware not 'empowering' anyone. By denying them the resources that are actually needed (actual people who know how to deal with the issues that inevitably arise), you are making it worse by throwing on more 'management'.

The reason committers didn't have this access before was due to the lack of flexibility in selecting a restricted, need-to-know group within projects. The introduction of the Project Security Team concept makes this feasible, allowing projects to assign security-related tasks to a subset of committers with the right expertise to handle vulnerability reports.

Right. That works really well when there are people (not 'projects') with that expertise available to do the actual work (instead of...or at least in preference too...the 'management' of that work). And for those projects (not just ECF) that have no 'subset of committers with the right expertise'? (see @fedejeanne comment today)?

Here's an idea: train a AI model to fix security issues and do bug fixing/maintenance of the platform. Maybe the corps will support that.

I understand that the resource constraints of the ECF project are challenging.
However, this discussion might not be the right place to address those concerns.

As I said, I've been personally making these points to the working group and others for literally years now to deaf ears. I'm finished with that. It's now the IDE people, EF people, and the committer people's problem, not mine.

[scottslewis]

Relevant to our discussion about security and open source maintenance:

https://www.theregister.com/2024/09/18/open_source_maintainers_underpaid/

[mbarbero]

I’ve read Tidelift's report thoroughly. Please take a look at the 'Fellowship for Maintainers' program at Sovereign Tech Fund (https://www.sovereigntechfund.de/programs/fellowship). It might be an interesting opportunity for you.

[scottslewis]

I’ve read Tidelift's report thoroughly. Please take a look at the 'Fellowship for Maintainers' program at Sovereign Tech Fund (https://www.sovereigntechfund.de/programs/fellowship). It might be an interesting opportunity for you.

Thank you @mbarbero for this reference. I have applied for a fellowship at STF for ECF including the ECF filetransfer/p2/Eclipse IDE maintenance, and including ECF's transport independent and multi-provider impl of OSGi Remote Services specification. If this support comes through, then it will allow me to maintain ECF's contributions to the Eclipse IDE (filetransfer/transport-level security), other projects and consumers that use other parts of ECF (e.g. remote services), and the Project Security Teams effort.

[mbarbero]

Thank you for the update. I'm glad this helped and sincerely hope it will work for you!

[jerboaa]

If all Committers in your project are involved in addressing security issues, nothing will change for you. All Committers will automatically be considered part of your Project Security Team, and no further action is required on your part.

Do I understand this correctly that the default Project Security Team will be all committers? Wouldn't that be a wrong default, going against the best practise of strictly need-to-know on security issues? Would it make sense to make the default only be the project leads - who would then be able to loop in required experts and only those? Thoughts?

[mbarbero]

Do I understand this correctly that the default Project Security Team will be all committers?

Yes, that is correct.

Wouldn't that be a wrong default, going against the best practise of strictly need-to-know on security issues? Would it make sense to make the default only be the project leads - who would then be able to loop in required experts and only those? Thoughts?

We also recommend limiting the Project Security Team to a small, need-to-know group of individuals. However, this decision should be made at the project level to align with the Eclipse Foundation Development Process, which emphasizes the following:

All Project Committers have equal rights and responsibilities within the Project. Partitioning of responsibility within a Project is managed using social convention.
— Eclipse Foundation Development Process, Section 4.1

and

Project Leads are responsible for ensuring that their Project’s Committers adhere to the Eclipse Foundation Development Process and that the Project is engaging in activities that foster vibrant communities of users, adopters, and contributors.
— Eclipse Foundation Development Process, Section 4.6.2

Given this framework, restricting access to certain information, such as vulnerability reports, is not something that can be universally enforced across all projects. Instead, it is a decision to be made by each project.

Project leads do have the option to implement what you’ve suggested. After consulting with the committers, they can go to their project's PMI page, uncheck the committers box, and check the project leads box to define the membership of the Project Security Team accordingly:

I hope this clarifies our reasoning for making all committers the default members of the Project Security Teams.

[jerboaa]

OK. Thanks for this clarification. Much appreciated. I second the recommendation for leads to manually change this - unfortunate - default.

[fedejeanne]

Hello @mbarbero,
thank you very much for your (and your teams') continuous work on this important topic!

Are there any trainings you recommend, or someone we (committers) can reach out to to ask and learn how to solve the issues? I have the feeling that most of the issues would be solvable if the teams started building expertise, but the whole topic of security is sometimes daunting and sometimes simply ignored because "who has the time?", right?

Don't get me wrong: I consider it to be very important, but I never find the time to start going about it and I feel I'm not the only one on that boat. So maybe some guidance (links to articles, trainings, learning paths in some study platform, etc) would help. Is there any recommendation from the security team about this? Or from the EF itself?

[mbarbero]

Thanks, @fedejeanne, for your kind words. This is truly a team effort, and I'll be sure to share the kudos with everyone involved.

For any security-related questions, you can always reach out to the Eclipse Foundation Security Team. If the topic shouldn't be discussed publicly, you can send an email to [email protected]. Otherwise, feel free to use this forum to ask your questions.

Regarding training, we've started compiling information in what we call the Eclipse Foundation Security Handbook: https://eclipse-csi.github.io/security-handbook/. This is still a work in progress, but the content will grow over time.

We will also begin offering committer training in Q4 2024 through a series of webinars. @mrybczyn can provide more details about this.

Do you think this combination of written materials and live training (with recordings available) would meet your needs?

[fedejeanne]

Thank you for the pointers! I'll be definitely taking a look at what you mentioned and I'll be looking forward to the webinars from Marta :-)

Do you think this combination of written materials and live training (with recordings available) would meet your needs?

I think it would 👍

[mrybczyn]

@fedejeanne I will jump on the opportunity :) Do you have ideas of subjects that you would like to see covered first?

[fedejeanne]

@fedejeanne I will jump on the opportunity :) Do you have ideas of subjects that you would like to see covered first?

Well in my particular case, information on how to assess the real risk of a finding would be useful. I understand the theory of the findings just fine (they are thoroughly described in the advisories) but I struggle to answer questions such as:

• Is this really reproducible in our environment?
• If it is, which level of access should an attacker already posses in order to exploit this vulnerability? (which begs the following question:)
• If someone needs access to my computer/environment just to exploit this vulnerability, isn't all the damage already made?

Take SSRF for example:

• CodeQL: https://codeql.github.com/codeql-query-help/javascript/js-request-forgery/
• OWASP: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

It is clear to me that if the URL is manipulated then bad things may happen. The part I struggle with is: if the URL is in localhost and the service "simply" displays the documentation in an embedded browser then:

1. Is it worth protecting a very simple server that merely serves HTML documentation?
2. Doesn't the attacker have to be in the system before even being able to exploit such a vulnerability?

In my very reduced understanding I would answer like this:

1. It's not worth it, worst case scenario the documentation is wrong and I have to search somewhere else
2. Yes. All hope is lost already.

But an expert might answer very differently. Which is why I usually leave those findings unattended out of fear of leaving some big security hole unattended :-\

I hope I could answer your question @mrybczyn :-)

[mbarbero]

Just a heads up: Project Security Team members have now been granted the Security Manager role within their respective GitHub organizations.

[scottslewis]

For everyone's information...wrt open source security trends:

https://www.theregister.com/AMP/2024/12/10/ai_slop_bug_reports/

[scottslewis]

This comment is intended to provide awareness among EF project leads, committers, and contributors

In fall 2024, the EU passed the Cyber Resilience Act: https://en.wikipedia.org/wiki/Cyber_Resilience_Act

The Eclipse Foundation has created an Open Regulatory Working Group for orgs and committers collaborate on compliance: https://orcwg.org/. See also Mike's Blog and posts: https://blogs.eclipse.org/post/mike-milinkovich/securing-future-open-source-launching-open-regulatory-compliance-working.

The CRA has a new concept of an 'open source steward' that is intended to shield free and open source projects and communities from some of the liability

The OR working group has created a mailing list here:

https://accounts.eclipse.org/mailing-list/open-regulatory-compliance

...and there has been some recent discussion on this list of how the open source steward role is defined by the CRA, and what stewards, manufacturers, orgs, and others will be responsible for in terms of compliance. It's very early in figuring these things out...for the EF umbrella of OSS communities, but a good time for open source community input.