Could we specify a steward.md file?

[torgo]

It came up in our workshop in Amsterdam in December and since has been raised on a number of calls and side-discussions, so I am registering it here. Because of how the CRA talks about open source "stewards", it may be useful for open source projects to be able to declare what organisation is the steward of that project. This seems to be analogous to funding.yml, license.md, security.md, or other mechanisms OSS projects are using to declare governance systems that are related to their project. If this is a good idea, then it would make sense to write down what is expected to be in a steward.md file to enable crawlers and other mechanisms to detect and parse them.

[torgo]

Related:

• https://github.com/publiccodeyml/publiccode.yml
• https://github.com/codemeta/codemeta
  • https://github.com/codemeta/codemeta/blob/master/crosswalk.csv
• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository

[torgo]

see also #10

[martingo]

Thanks for bringing it up here :)
How about adding it to https://github.com/ossf/security-insights-spec ?

[torgo]

I opened an issue there. Whatever we end up with, in my view it needs to be easy for maintainers and it also needs to be aligned with the other ways projects specify this kind of metadata.

[martingo]

There is also a discussion with some ideas of additional information which can be included
#15

[sjn]

The CycloneDX project has a working group exploring ways to communicate OSS Sustainability metadata. Information related to the Cyber Resilience Act (e.g. selected steward, or if a project is intended for commercial use) are in-scope. And since the sustainability of a project can have direct impact on the long-term security posture and short-term responsiveness of a project, so I'd like to propose taking a look at the ongoing work there, to see if it may make sense to approach this issue from that direction.

Meetings are bi-weekly and open, and this spec may end up at ECMA for formal standardization.

• Project overview: https://cyclonedx.org/participate/working-groups/

[torgo]

Considering Security Insight's work on this has now merged, perhaps we can close this issue and resolve that the (or at least a) recommended approach would be to specify the steward in the security insights YML file?