Thank you to everyone who attended the call yesterday.
I captured some notes during the call and have captured them in the
wiki.
Marta Rybczynska from the Eclipse Foundation's Security Team joined us and provided a short overview of some of the activities that the team is working on in service to Eclipse open source projects.
She briefly discussed the team's work with OWASP Dependency Track, which we're planning to use to warehouse SBOMs generated by (and for) projects. The idea is provide a home where we can keep track of them, so that -- in the event that a significant vulnerability along the lines of Log4Shell comes around -- we'll be able to quickly assess the scope of the problem and implement a mitigation strategy. We're also investigating how we might use this to add missing (or fix incorrect) licence data in SBOMs.
The Security Team is also engaged with some Eclipse projects to determine what we need to provide/support in various ecosystem pipelines, help them generate SBOMs, etc.
They've started engaging with a small number of Eclipse projects on "Mini security reviews". The idea is to spend a fixed amount of time reviewing the security posture of the project and provide feedback. These "mini" reviews are high-level. The intention is to identify key risk factors like projects with one active developer, no CI, etc. Their intention is to set up calls with projects to introduce the review, and then follow up with results. We're doing our best to align these with with progress reviews initiated by the EMO to try and keep the process as streamlined as possible (e.g., avoid bothering the project twice). This is all still experimental and will be refined as the team gains experience.
Finally, the Security Team is investigating an optional committer id verification feature for projects. The IT and security teams are working with various providers. Our thinking is that this is an optional feature that we can make available for those projects for which it makes sense. There are a lot of things to consider, including whether or not we feel that this sort of feature aligns with the open source rules of engagement, and how we fund this sort of activity. We did briefly discuss whether or not we felt that this aligns with the open source rules of engagement, and my take away was that the group all agreed that it does. If there's interest, we can make this a topic for more discussion at a later date.
We spent time discussing SBOMs. Mostly we have questions. This is a topic that we should expand on in a future discussion. Some questions that were asked:
- Are SBOMs just going to be used to put a check mark on a list?
- Do we include information about the build environment in the SBOM?
- How do we leverage Eclipse IP data to improve the quality of licence information in SBOMs?
- Do SBOMs make sense for a JAR file? (or do they really only make sense for a "product"?)
- What does an SBOM for the Eclipse IDE look like? Does, and how does the SBOM change when you install a plug-in?
We did note that there is some work in progress by the Eclipse IDE WG to resolve the last point.
We talked about the notion of end of life of a development stream and what that means in open source. We discussed that the notion of an absolute end of life doesn't really make sense, since it's relatively easy for a project team to accept a pull request, or for the content to be forked and worked on elsewhere. The forking option may have trademark implications that we need to think about: if somebody forks an Eclipse project with the intention of providing support for that version, can they use the project name? Jesse and Wayne are going to discuss this and maybe make this a topic for conversation in the next call.
It was pointed out during the conversation that we need to be careful using the word "support". When we talk about supported versions and end-of-life, it gives a mistaken impression that the output of open source projects are "products" in a traditional sense. We have to keep in mind that the Eclipse Foundation is not a software vendor, our open source projects do not produce products in the traditional sense, and what we mean when we say "support" is very different from what an organisation that regards us as a software vendor thinks it means.
Anyway, I hope that those of you who were in attendance believe that this adequately captures the spirit of the discussion. Please feel free to fill in any gaps.
Thanks,
Wayne
