| I think this should be a topic of the next architecture council meeting on Thursday. So I don’t think you can assume silent agreement (yet)… ;-)
Cheers Martin Am 10.06.2024 um 10:44 schrieb Mikael Barbero via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>:
Should I assume silent agreement, or are there still some points you would like to address in the proposed changes?
Thanks! Mikaël Barbero Head of Security | Eclipse Foundation
Sorry for the late reply. I'll try to address each concern and then reiterate the goals explaining why we believe these changes are necessary.
I think I don't like that project committers can "opt-out" themselves from the project security team. I recommend further change to the language to prevent that and protect from responsibility delegated away. We should make membership of committers implicit and never be removable. Specifically it should be impossible for project committers to have a vote for a construct allowing them to remove themselves or any other committer from the security team. As it's written right now it seems possible.
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. 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:
- Not all developers have the required security background/training to handle vulnerability reports properly.
- 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.
- 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.
I am not sure about the change. I think creating another team adds confusion as the members may not be committers. Where would the project recruit the members from? I suggest adding the requirements to the projects to comply with security policy might be sufficient. Creating a separate is implementation details. If Eclipse Foundation amends the policy to force each project to comply with security requirements, it is clear enough. I am not sure forcing the creation of a separate team is a good idea.
Projects already have to comply with the security policy (see an overview of https://www.eclipse.org/security/policy/: This Vulnerability Reporting Policy applies to all software distributed by the Eclipse Foundation), this is not what we are trying to solve here. We reference the security policy in defining the Project Security Team to explain its mission and scope, not merely to add a requirement for a project to comply with the security policy, as this is already the case.
If all committers are part of the security team, then how is it a separate team? Furthermore, which "team" wins in an argument?
We want to keep it simple for projects that are still incubating, in maintenance mode, with a small number of Committers, or just not yet widely successful. In these cases, the Project Security Team equals the Committers. For the reasons above, it’s important not to limit projects to just that.
Regarding arguments: ultimately, only Committers have write permissions to the repository, so they decide what goes into the code. We see the security team as the people receiving vulnerability reports, communicating with security researchers, and involving the most relevant Committers in resolving a vulnerability. Once the fix is made by Committers and ready to be released, the security team is also responsible for requesting a CVE and ensuring responsible disclosure (no reference to the vulnerability in the commit, preparing an advisory with the release...).
I think adopting a policy approach with each team have a security point of contact would work better. This can still be codified in the EDP.
We already have a policy approach. See comments above. The security team is exactly about defining the point of contact. To minimize risks, it is important that this point of contact is as small as possible for some projects.
If I read the email thread correctly, then the motivation for this change is to allow external security people (eg. Eclipse Foundation staff or other security folks) manage the security process for a project. So maybe the solution to this problem is something else than adding a new team? @Mikael, can you share a bit more about the problem? Right now it's only stating that the Project Security Team is responsible for implementing the Eclipse Foundation Security Policy. Why should this be a separate team but not the project committers?
Hopefully, the motivation for this change is now clearer from my comments above. However, I would like to reiterate: the goal here is to define a group to which we offer access to vulnerability reports. The larger the number of people with access to these reports (especially high-profile ones), the riskier it is. It is an industry best practice to limit access to a well-defined team. By default, we believe that the group of Committers is sufficient for most projects. However, we must also acknowledge that this approach cannot work for all projects. The risks associated with giving visibility to vulnerability reports to all Committers are unacceptable for some. This is why we want to bring this flexibility, gated by a Committer vote and PMC approval.
Additionally, we want to enable Committers to elect security team members without requiring them to be Committers first. The primary reason is that a security expert does not necessarily contribute code, so it would be difficult for them to demonstrate a contribution record for a successful election. Secondly, not all software engineers are well-versed in vulnerability management, and thus, limiting Project Security Team members to only a subset of Committers could be detrimental to the project's security posture.
Let me know if you have further concerns.
Thanks! Mikaël Barbero Head of Security | Eclipse Foundation
I think Jay and Emily raise good points. Especially the one about winning an argument is an interesting one.
If I read the email thread correctly, then the motivation for this change is to allow external security people (eg. Eclipse Foundation staff or other security folks) manage the security process for a project. So maybe the solution to this problem is something else than adding a new team?
@Mikael, can you share a bit more about the problem? Right now it's only stating that the Project Security Team is responsible for implementing the Eclipse Foundation Security Policy.
Why should this be a separate team but not the project committers?
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
|
