Security reporting procedures not on community repos nor this meta repo

[alesandroortiz]

Question

How can we make security contacts and procedures clear in community repos?

There is no security contact listed in most if not all community repos.

Adding the security info for community repos in a SECURITY.md in each repo and in this meta repo would help security researchers find the appropriate security contact.

Based on info in this Twitter thread, community repos are not in scope for Facebook's security program. However, this is not indicated anywhere in the community repos.

A SECURITY.md in each repo and in this meta repo with text similar to this would suffice:

To report security issues in React Native Community repos, please check the repo's SECURITY.md or contact each repo's listed maintainers directly via email. Community repos are out of scope for Facebook's security program. To report security issues in React Native, contact Facebook's Security team at facebook.com/whitehat.

For a more concrete example, I had difficulties identifying who to contact for a security issue in a react-native-community repo which was previously part of React Native core. Having clear reporting info in each repo would have helped, because the security scope distinction between the community repos and core repos was not immediately clear to me. I almost reported the issue to Facebook's security team thinking it was in scope of their security program, before being told otherwise on Twitter.

I filed a parallel issue for the https://reactnative.dev website since some community repos have old docs still hosted on there, and the website was my second stop after not finding info in the community repos: https://github.com/facebook/react-native-website/issues/1889

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.

[kelset]

oh hi @thephpjedi - sorry for not seeing this issue before, let me reply to your points:

Adding the security info for community repos in a SECURITY.md in each repo and in this meta repo would help security researchers find the appropriate security contact.

Cool, is this one of the files that gets automatically propagated to the repos if put in this one?

this is not indicated anywhere in the community repos.

TBH it kind of is, they are in a dedicated org which is not owned by FB and the README in this very repo says that too. And to be fair even on the main org page "Quality code from the React Native Community" indicates how this is by the community and not FB.

I had difficulties identifying who to contact for a security issue in a react-native-community repo which was previously part of React Native core.

(A) Have you checked the maintainers file in this repo? (B) Why did you decide not to open directly an issue on the repo itself?

[alesandroortiz]

Hello @kelset, I also missed your reply earlier!

Cool, is this one of the files that gets automatically propagated to the repos if put in this one?

Based on the GitHub docs, adding .github/SECURITY.md in this repo should propagate automatically to other repos in the org if the file doesn't already exist in the repo. Haven't tested this myself.

For context on the items below, I'm not a React Native developer and didn't know the distinction between GH orgs in terms of security coverage. Sometimes security coverage differs from code owners/maintainers. This made it plausible that the security contact was still the FB Security team instead of the current community maintainers, especially because in the past it was covered by FB Security.

The lack of a SECURITY.md or any mention of security contacts made it guesswork as to whether reach out to maintainers or FB Security. With many vulnerabilities, time is of the essence, so I try to identify an explicit security contact to immediately send a report to. If a security contact is not publicly listed, I try to discern who would respond most quickly to a request for a security contact. I only send the report after confirming the security contact. This causes unnecessary delay, guesswork, and extra effort for security researchers. It also delays patches for vulnerabilities.

the README in this very repo says that too

(A) Have you checked the maintainers file in this repo?

For both items above: This meta repo wasn't discoverable from the component repo I was looking at, and it isn't pinned in the organization page. I found it by chance after reaching out to identified maintainers. In fact, right now this repo doesn't show up anywhere in the first page of the org page (it's at the end of the 2nd page). It's also wasn't clear to me this meta repo would contain useful info for security reporting such as the global maintainers file. The global maintainers file was also inconsistent with the repo's maintainer list, and both lists were inconsistent with the recent commit authors, which were missing all three possible maintainers. This is why it took me over 5 days to perform initial uncertain outreach, instead of minutes.

Adding a SECURITY.md in each repo referencing an up-to-date maintainers file works for me. Ideally, there's a backup contact listed there for security issues, in case repo maintainers become unavailable or the maintainers list becomes outdated.

(B) Why did you decide not to open directly an issue on the repo itself?

For the missing SECURITY.md, since it seemed like an issue with most if not all repos in the community org, I filed this issue here to have it clarified for all repos. Hopefully it helps improve the security of all software in these repos and makes it easier for other security researchers (plus myself in the future).

Regarding the specific vulnerabilities, my absolute last resort for a GitHub-hosted project is to open a public issue requesting a security contact. Some maintainers and organizations don't like it when a random stranger publicly states their software has a vulnerability before they can fix it. And I don't like that either. Some projects also do not review their public issues in a timely manner. Therefore, it didn't seem like an effective outreach method given the available, albeit uncertain, alternatives.

[kelset]

I see, thanks for clarifying your process.

That said, there are some internal conversations happening around the entire nature of the RNComm org itself and one of the likely outcomes is that the org itself will not be just quite as it is today (I can't really say much because I wasn't involved in the decision nor it's my role to communicate it).

In that sense, I think that we should close this issue in favour of the one you posted in the website repo (maybe you can add a comment there and copy paste from your comments here your main points / feedbacks). And I'll try to point the people that maintain the website to it so that they can decide how to act on it.

[alesandroortiz]

@kelset Fair enough. If in the future I run into reporting difficulties after the org changes, will follow up then in this issue (or a new issue if this repo is deprecated).

Will wait for comments on the website repo issue.

Thanks for reviewing!