This is the default for repositories in this organization that do not have a SECURITY.md of their own. A repository handling something unusual — a network edge, stored credentials, a published package — should have its own, describing what is in scope for it.

Do not open a public issue for something exploitable. A public issue is a disclosure, and it lands before there is a fix.

Where the repository offers a private security advisory — its Security tab → Report a vulnerability — use that. It is the only channel here that is private end to end.

Where that form is not there, because the repository is private or the feature is off, open an issue saying you have found something and asking how to send it privately. Keep the technical details out of that issue.

Include what you would need in order to reproduce it: the version or commit, the steps, and what you saw against what you expected. A proof of concept helps and is not required.

These are maintained by one person. A reply usually arrives within a week, and no response time is guaranteed. A fix may take longer than the reply; you will be told which is happening.

There is no bounty programme.

In scope: the code in the repository, the artifacts it publishes, and the build that produces them.

Out of scope: third-party platforms these projects run on or integrate with — report those to the platform. Also out of scope: a project's own content where its author is the only writer, social engineering, and anything requiring access to an owner's account.

• Access, modify, or delete data that is not yours.
• Degrade a running service, or test against one where a local instance would do.
• Publish details before a fix is out, or a decision not to fix has been explained.