Add a requirement/recommendation to provide a SECURITY file with project documentation

Consider requiring/recommending that projects include a SECURITY file in their repositories.

The file should include a pointer to the Eclipse Foundation Vulnerability Reporting Policy along with implementation details that are specific to the project.

What implementation details should be included in the file?

• By what mechanism should vulnerabilities be reported
• How vulnerabilities are tracked by the project team
• By what criteria the project team will decide whether or not a CVE will be requested from the Eclipse Foundation

What else?

The main problem I'm facing in formulating this is that all the tools we have available for users reporting issues or for the team tracking issues are public-facing (github issues, mailinglists). I'm no expert, but I think we should offer a channel to privately report security vulnerabilities, and also track them in a private way. But as a project team we have no tooling for this (beyond, obviously, personal e-mail, but I'm not sure I'm comfortable with putting my personal e-mail in this document).

The Eclipse security team is set up for this. Should we just immediately redirect users to them when reporting possible vulnerabilities?

mentioned in issue eclipsefdn/emo-team/emo#26 (closed)

The security@eclipse.org alias is probably the most consistent channel. So that's probably the best default position.

Note that when possible (and sensible), the security team opens a Bugzilla record against "Community/Vulnerabilities", marked as "committers-only and with the project lead in copy. This was the best general solution that we could come up with at the time. I wonder if a better general solution would be for the security team to forward reports to the project leads? But that's something that we can decide later.

AFAIK, it's still the case that GitHub issues cannot be marked as private/confidential, but GitHub does have some infrastructure for dealing with vulnerabilities in a confidential manner (I need to spend some time investigating this).

GitLab does have the ability to mark an issue as confidential, so there's some potential there.

That makes sense to me. I saw the Gitlab confidentiality feature which looks great, but I'll have a hard time convincing our committers to switch to Gitlab just for that. If Github has some other way to deal with this, I'd be interested to know.

Meanwhile, here's a draft document I put together for our project: https://github.com/eclipse/rdf4j/pull/3046/files . Do you think this is sensible, and perhaps something other projects can copy and adapt as needed?

I'm starting to use GitLab issues as the means of requesting CVEs. It's not a great way, however, for a project team that is not otherwise engaged on GitLab to track the mitigation of an issue.

I like the draft. Listing "supported" versions is a good addition.

mentioned in issue eclipsefdn/emo-team/emo#7 (closed)

mentioned in merge request eclipse/comma/comma!39 (closed)

mentioned in issue eclipsefdn/emo-team/emo#71 (moved)

mentioned in issue eclipse/escet/escet#169 (closed)

mentioned in issue eclipsefdn/helpdesk#623 (closed)

mentioned in issue eclipsefdn/emo-team/emo#169 (closed)

mentioned in issue eclipsefdn/emo-team/emo#152 (closed)

mentioned in issue eclipsefdn/emo-team/emo#249 (closed)

mentioned in issue #165 (closed)

marked #165 (closed) as a duplicate of this issue

marked this issue as related to #165 (closed)

In terms of format, should we consider the security.txt option suggested in #160 (closed)?

It's a standard, it's just not clear to me whether or not it is a widely accepted standard.

AFAICT, this is not widely adopted. It is formal and a bit complex. I see its use case for SaaS where the security.txt would be available at a well known URI.

For OSS code repos, the usual SECURITY.md with free form text should be enough. At the very least, it should contain the disclosure policy. IMO, this Snyk's article nails it.

mentioned in issue #160 (closed)