Re: [eclipse.org-architecture-council] Update the EDP to include a Proje

[Mikael Barbero <mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx>]

Gunnar,

Thank you for challenging these changes; these discussions are indeed important.

Having a separate Project Security Team differs from having a separate Project IP Team, as the risks are fundamentally different. A leaked 0-day vulnerability is catastrophic and cannot be remedied after the fact, while a temporary, non-released dependency with an incompatible license is a reversible issue.

Some projects, and I would encourage most to do so, prefer that vulnerability reports be accessible only to individuals with proper security education, limiting access to a minimum number of qualified individuals. This is the only way to mitigate the aforementioned risk. This aligns with industry best practices. Implementing these practices benefits the projects, the organization members, and the Foundation as a whole.

Implementing this practice may require some committers to forgo access to some project resources (considering vulnerability reports as project resources). This is currently not feasible under the existing EDP, as:

All Project Committers have equal rights and responsibilities within the Project. (EDP Section 4.1)

This is the primary reason we believe a change to the EDP is necessary. We need an exception to the equal rights and responsibilities rule because the associated risks are critical, and the stakes are high.

If you have a different interpretation of the EDP and believe our concerns can be addressed at the project level or through the security policy, I would be glad to reconsider this request for changing the EDP.

Thanks again for your engagement.

Mikaël Barbero 

Head of Security | Eclipse Foundation

🐦 @mikbarbero

📅 Book an appointment

Eclipse Foundation: The Community for Open Innovation and Collaboration

On 10 Jun 2024 at 11:53:36, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

On Jun 5, 2024, at 13:23, Mikael Barbero via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

Indeed, this is possible and intentional. We expect that most projects will stick with the default where the Project Security Team equals the Committer team. This works well for projects with well-trained Committers where everyone can handle security.

Mikael, I believe this argumentation is flawed. We are creating an unbalanced treatment/apply of principles here. To emphasize why, just replace security with "IP". Why are we not having a separate Project IP team within the EDP? Because we want every developer to be aware and responsible of third-party licensing/legal risks. 

There is no requirement for committers to do all the work, the clearance and auditing. Yet, we want to be aware of the risk. I think the same principle shall apply to security, or to any other important matter of the EDP.

However, we see the need for an alternative approach, where the security team is a subset of Committers (plus maybe some external security experts), for large and mature projects, for several reasons:

IMO we should not have a:

* Project Security Team

* Project Legal Team

* Project Supply Chain Team

* Project Documentation Team

* Project Community Team

written into the EDP even though they may exist as separate roles and delegation of work at larger projects/organizations.

The EDP is about principles for open source development regardless of project size or maturity. Specifically adapting the process to specifics for a commercial entity is adding unnecessary bloat and bureaucracy IMO. It should be avoid.

• Not all developers have the required security background/training to handle vulnerability reports properly.
  

You can say the same thing about legal/IP handling. Yet we don't have a dedicated project team for this.

• The more people have access to a vulnerability report, the more likely it will leak before responsible disclosure is complete. For widely used projects with many Committers, giving everyone access to a high-profile vulnerability can be risky.

This is an AuthZ implementation thing. We want to keep this out of the EDP. If fine grained AuthZ is needed, the security policy can express such a requirement at the discretion of the management/escalation chain (project leads -> pmc -> emo -> ed). The nature of these things evolving changing should be very decoupled from the EDP revision process.

• When the security team equals the Committer team, a high-profile project may be reluctant to elect new Committers as any new person adds risk. Such a project might add restrictions to Committer elections, requiring security expertise, training in responsible disclosure processes, TLP, and other subtleties. This does not help the project grow its Committer base. We believe allowing projects to have a security team not necessarily composed of all Committers will help foster the onboarding of new contributors as Committers.
  

Please bring specific examples. I cannot understand that argument. Each project can define its own level of playing field with regards to committer requirements and such. We trust committers to do the right thing. Let each project define its own RACI matrix. That's the flexibility we already have  in the EDP. 

I think we really should just capture the case where non-committers can assume security roles within a project. Right now everything is focused on committers. But I am not even sure the current EDP would dis-allow such practice. 

-Gunnar