Report vulnerabilities upstream first

CONTRIBUTING.md

@@ -1,25 +1,34 @@
-# Reporting Vulnerabilities
+# Create an Advisory
 
 To add an advisory to the RustSec database, open a [Pull Request] against
 [this](https://github.com/RustSec/advisory-db) repository containing the new advisory:
 
+### Prerequisites
+
+1. Report the vulnerability upstream according to their security policy. RustSec
+   maintainers do not have expertise in every crate's internals and so a crate
+   maintainer can much more efficiently respond.
+2. Wait for the maintainers to confirm the vulnerability exists.
+3. Engage in coordinated disclosure (as applicable) so the vulnerability isn't revealed
+   publicly before responsible parties are ready to respond.
+
 ### Required Steps
 
-1. Create a file named `RUSTSEC-0000-0000.md` in the `crates/<yourcratename>`
+4. Create a file named `RUSTSEC-0000-0000.md` in the `crates/<yourcratename>`
    subdirectory of the repository (you may need to create it if it doesn't exist)
-2. Copy and paste the [TOML advisory template] from the README.md file in this repo.
+5. Copy and paste the [TOML advisory template] from the README.md file in this repo.
    Delete the comments and additional whitespace, and fill it out with the
    details of the advisory. Surround the TOML data with <code>\```toml</code> and <code>\```</code> markers.
-3. Write a human-readable Markdown description in the same file, after the <code>\```</code> marker and a newline. Use [this example advisory][example] as a reference.
-4. Open a [Pull Request]. After being reviewed your advisory will be assigned
+6. Write a human-readable Markdown description in the same file, after the <code>\```</code> marker and a newline. Use [this example advisory][example] as a reference.
+7. Open a [Pull Request]. After being reviewed your advisory will be assigned
    a `RUSTSEC-*` advisory identifier and be published to the database.
 
 ### Optional Steps
 
 Feel free to do either or both of these as you see fit (we recommend you do both):
 
-4. [Yank] the affected versions of the crate.
-5. Request a CVE for your vulnerability. See for details:
+8. [Yank] the affected versions of the crate.
+9. Request a CVE for your vulnerability. See for details:
    https://cve.mitre.org/cve/request_id.html and https://cveform.mitre.org .
    Alternatively, you can create a GitHub Security Advisory (GHSA) and let them request
    a CVE for you. In this case, you can add the GHSA ID to the RustSec advisory via the
@@ -52,9 +61,9 @@ When in doubt, please open a PR.
 
 **Q: Do I need to be owner of a crate to file an advisory?**
 
-A: No, anyone can file an advisory against any crate. The legitimacy of
-    vulnerabilities will be determined prior to merging. If a vulnerability
-    turns out to be fake, it will be removed from the database.
+A: No, anyone can file an advisory against any crate. However, this should only be
+   done after the mainainters have confirmed the legitimacy of the vulnerability.
+   If a vulnerability later turns out to be fake, it can be removed from the database.
 
 **Q: Can I file an advisory without creating a pull request?**
 
@@ -63,7 +72,7 @@ A: Yes, instead of creating a full advisory yourself, you can also
 
 **Q: Does this project have a GPG key or other means of handling embargoed vulnerabilities?**
 
-A: We do not presently handle embargoed vulnerabilities. Please ensure embargoes
+A: We do not handle embargoed vulnerabilities. Please ensure embargoes
    have been lifted and details have been disclosed to the public prior to filing
    them against RustSec.
 

MAINTAINERS_GUIDE.md

@@ -5,12 +5,12 @@ Reviewing a pull request, step by step:
 ## See if CI passes
 
 This is something first-time submitters may struggle with.
- 
+
 You can usually make changes directly to the submitter's branch. It's a great way to make CI pass and help out first-timers, but avoid making substantial changes to content this way without consulting the submitter.
 
 ## Make sure the developers of the crate in question are aware of the issue
 
-If no upstream issue has been filed, ask the reporter to file one first.
+If no upstream issue has been filed, remind the reporter that they need to follow the upstream security policy before creating an advisory.
 
 ## Check if there are any fixed versions
 We don't want to carry a non-actionable advisory if a fix is forthcoming. It's alright to delay by a day or two and then publish it once the fix ships. If a fix has been applied in git but not released to crates.io, ask the upstream for a new point release.
@@ -61,4 +61,4 @@ It could be also useful to [radiate the intent] when dealing with PRs - Especial
 
 Time period of Objection to either Merge or Close depends on the controversial aspect and / or urgency of the PR.
 
-[radiate the intent]: https://github.com/rustsec/advisory-db/discussions/1325
+[radiate the intent]: https://github.com/rustsec/advisory-db/discussions/1325

README.md

@@ -24,9 +24,10 @@ and reporting (send PRs to add yours):
 * [trivy]: A simple and comprehensive vulnerability/misconfiguration/secret scanner for containers and other artifacts. Trivy detects vulnerabilities of OS packages and language-specific packages. Works via [OSV](https://osv.dev).
 * [dependabot]: Dependabot can fix vulnerable dependencies for you by raising pull requests with security updates. Works via [GHSA](https://github.com/advisories).
 
-## Reporting Vulnerabilities
+## Create an Advisory
 
-To report a new vulnerability, open a pull request using the template below.
+If you discover a vulnerability, report it upstream according to their security policy.
+Afterwards, you can create and advisory by opening a pull request using the template below.
 See [CONTRIBUTING.md] for more information.
 
 See [HOWTO_UNMAINTAINED.md] before filing an advisory for an unmaintained crate.