Re: [open-regulatory-compliance] Open Source Steward: Role description

[Tobie Langel <tobie@xxxxxxxxxxxxxx>]

Hi Sarah,

It's really interesting to think of the implementation of the CRA requirements in terms of extending existing OSPO structures. This makes it very concrete. Thank you for sharing it.

My understanding is that the open source stewards role is really focused on open source foundations. I guess some for profit organizations could be stewards to a project, but this seems like a corner case rather than the norm (I might be wrong, however).

We're discussing opening matrix channels and more dedicated calls for different constituencies to be able to discuss how they're impacted by the CRA. Is this something people would be interested to participate in? We're currently thinking of the following topics:

- Open source stewards (open source foundations)
- Open source users (this is the OSPO-case discussed below)
- Single-vendor open source

Do these resonate? Do you have other ones in mind?

Thanks,

--tobie

---

Tobie Langel
Tech Lead Open Regulatory Compliance WG, Eclipse Foundation

Principal, UnlockOpen

On Thu, Jun 13, 2024 at 9:31 AM Moser Sarah RDL DISDS3 via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Internal

Internal

Thanks, Dirk.

To me the Steward role seems like an extension to existing compliance officer/OSPO roles with a focus on sec.

Sharing some hands on ideas, I plan to extend our OSPO roles with the interface description to the existing CySec org (VA teams, PSIRT, Governance structures).

Would like to collect feedback on this idea.

 

Vulnerability handling and risk based triage. – mapped to the role of a Cyber Security Engineer, but on OSPO side, we’ll have defined interface (VA, triage, reporting, tooling) based on the identified vulns

CVEs and solid/stable identifiers for CPEs; - CySec org

dealing with EOL’s; - mix of engineering and CySec org

dealing with retired packages and reports against these; - will be added to License Analyst role with scope foss

dealing with things like version numbers & what happens when you need to burn a release/never release it, and so on.

 

In addition, I see:

 

+ consult projects how to deal with unstable, unsupported versions (operational risks)

+ reporting (projects/repos with license/security risks)

+ support of PSIRT events (interface to SW inventory)

+ development and conduction of trainings

+ consult in the selection process which FOSS to use

+ maintenance of the governance system

+ cooperation with CySec, legal/IP and quality depts on policies and processes

 

Sarah

 

From: Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx>
Sent: Wednesday, June 12, 2024 7:58 PM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Moser Sarah RDL DISDS3 <Sarah.Moser@xxxxxx>
Subject: Re: [open-regulatory-compliance] Open Source Steward: Role description

 

On 12 Jun 2024, at 16:41, Moser Sarah RDL DISDS3 via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Maybe I am bit too deeply focused on details, but are there any initiatives to agree on and define the role of an Open Source Steward?

It would definitely help the industry to find the right people or to develop them.

 

That would be most useful - and get to the core of the mater; vulnerability handling and risk based triage. CVEs and solid/stable identifiers for CPEs; dealing with EOL’s; dealing with retired packages and reports against these; dealing with things like version numbers & what happens when you need to burn a release/never release it, and so on. A lot of practical work to be done.

 

All things we do today; often with solid risk/impact/etc driven approaches. But not well documented or described.

 

Dw

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org