Following up once again directors!
In what seems like a theme, a different group from last week attended the meeting today, and we summarized and revisited the prior two meetings, while also got a quick update on the Eclipse Foundation's efforts to provide input to the EU regulators in regards to the CRA as one of the staff members and a board member were on that call as well.
There was no objection to the basic idea of a high level principle, and more so the discussion shifted into what are the challenges and how can we approach them, which brought us quickly to setting expectations for projects.
For example, we had consensus on the items below. - Communities (under the foundation) are expected to have vulnerability management teams. - These teams need to have named contacts pointing the available contacts for each project or deliverable. In other words, the group of people (note, I said group, not person) who are responsible for an item. - All projects within a community are expected to have this policy apply. For example, Today in OpenStack, it's vulnerability management team only applies to a subset of projects, which is an issue. - Projects should be periodically reporting in as to what is going on related to security aspects.
Jeremy from the foundation staff was quick to note that the OpenStack VMT related policies[1] do somewhat align to the overall ideas presented in the first two items, which is a good sign, and one which we might want to draw from when drafting some sort of policy or written expectation to level set future discussions. The logical next step is to begin to draft a policy or expectation document as a group which sets the high level expectations. I believe the best course of action is to hold another call[0] on June 6th to cross-over the discussion with the other group of attendees and then proceed to putting something into writing.
One of the further aspects that we will need to also drive forward is the top-level information resource in order to relate policies/projects under the foundation and point to the appropriate resources. Jeremy has wanted to consolidate this information for a while, so he is going to begin socializing the overall idea with the staff.
If your interested in joining the discussion, we'll be meeting again on June 6th, 2024 at 1500 UTC.
-Julia
[0]: https://etherpad.opendev.org/p/board-informal-security#L60 [1]: https://security.openstack.org/repos-overseen.html#requirements
On Fri, May 10, 2024 at 11:50 AM Julia Kreger juliaashleykreger@gmail.com wrote:
Greetings,
Yesterday during the informal security working group meeting, we had a lighter and somewhat of a different attendance due to just the nature of schedules.
We didn't end up diving into the high level requirement extraction which is where our first meeting started approaching, and in this meeting we started heading into the question of the principals and high level requirements as a starting point to building consensus.
While we have some core themes we collected in the etherpad[0], what is likely needed is a stated principal or set of principles, much like the four opens. Something to set a tone is what is needed. It was noted in discussion that a principal could be as simple as an item in the project confirmation guidelines, but that might not set the overall tone required. I'm sure future discussion amongst the board will help bring consensus as time moves forward. One interesting aspect we need to keep in mind as we move forward, we're not just talking about aspects which relate to the foundation, but the expectations to have of our communities as well as expectations as it relates to how packagers/distributors engage.
To cover some of the core themes, it was noted:
- Open Infrastructure means a long-term investment in both trust and
security.
- No new release of software from a project should ever take place with a
known vulnerability. This means guidelines and project level processes would be necessary as well, and highlights a need for an upper level principal statement to drive consensus.
- Users should have a forward path they can take, i.e. to upgrade.
One challenge I've encountered writing this email is we can be vague with a principal to set a tone, except any attempt to be specific begins to take us down the path of expectation setting. Setting a requirement is also easy, but expectation setting requires specific dialog in that specific context. As a result, I think the best path to a principal statement is reaching consensus along the lines of "Security is a primary concern for all OpenInfra projects, second only to the project's specific problem it seeks to solve."
With an established principle, we can then begin to set requirements at the foundation level, and then engage projects to ensure requirements are clear, communicated, and are appropriately documented. Documentation is also critical as packagers/distributors and regulatory/market surveillance authorities will need a clear understanding of relationships and how to engage specific projects should issues arise.
Thoughts?
-Julia