> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Report upstream
> Report a flaw in a third-party component to its maintainers under CRA Art. 13(6), from a draft Pharus writes, and track their answer and fix.
**Plans:** Every plan. **Who:** any member drafts, records and tracks upstream reports.
When the flaw is in a third-party component, the CRA asks you to report it to the people who maintain it, and to share your fix with them if you make one (CRA Art. 13(6)). Pharus suggests where to send the report, drafts it in English and keeps track of it until the maintainers fix it. You send it. Pharus sends nothing itself and fetches nothing from the project's websites.
## When Pharus offers it
The card **Report to the component's maintainers** is on:
* an incident's **Overview** tab, and
* a report in the [disclosure inbox](/disclosure/inbox).
It is for a vulnerability the world doesn't know about yet. When the incident or report already has a public vulnerability id, such as a CVE, GHSA or EUVD id, the card reads **Already public upstream** instead: the maintainers know about it, and **Read it** opens the public record on OSV.dev or EUVD. Drills don't report upstream.
The component comes from the SBOMs of the incident's or report's product family. Without a product family, the card asks you to pick one first; a family without an SBOM with components has nothing to pick from yet.
## Where Pharus suggests sending it
When you pick a component, Pharus lists the ways to reach its maintainers that it can work out from the component's purl and the external references in your SBOM, most private first:
| Channel | Where it comes from |
| - | - |
| **GitHub private vulnerability report** | A GitHub repository in the purl or the SBOM: its new security advisory page |
| **Security contact** | A security contact in the SBOM |
| **security.txt** | A security.txt link in the SBOM, or the `/.well-known/security.txt` address of the component's website |
| **GitHub security policy** | The GitHub repository's security policy page |
| **Security advisories** | An advisories link in the SBOM |
| **Website** | The component's website in the SBOM |
| **Issue tracker** | The issue tracker in the SBOM |
Pharus picks the first private one. These are links for you to open; Pharus doesn't visit them, so check that the page exists before you rely on it. Choose **Somewhere else** to enter an `https://` address or an email address yourself.
An issue tracker is public: anyone can read it. Don't post the details of an unfixed flaw there; ask for a private channel instead.
### Look it up on deps.dev
If Pharus finds no GitHub repository for the component, select **Look it up on deps.dev**. Pharus asks deps.dev (Google's Open Source Insights) where the component's source lives, and adds the source repository, homepage and issue tracker it knows. deps.dev receives only the component's package identifier (its purl), as the OSV.dev lookups already do, never anything about your company. The lookup runs only when you select it, and covers npm, PyPI, Maven, Go, Cargo, NuGet and RubyGems packages with a version. If deps.dev doesn't know either, add the address yourself.
## Write and save the report
Select **Report to the maintainers** on the card. On an incident, the matched component is picked first. Use **Find a component** to search the family's components by name or purl.
Under **Where to send it**, pick one of the suggested channels, or **Somewhere else**.
The **Subject** and **Report** are drafted in English, so maintainers anywhere can read them. The draft says who you are and why you report (CRA Art. 13(6)), what you found (the incident's summary, where there is one), the affected package and versions, how to reproduce it, and asks the maintainers to confirm and coordinate disclosure. It ends with your security contact and the company name. Fill in the bracketed parts. Leave out your customers, your users and the researcher who found it.
Select **Save draft**. The report is listed on the card as **Draft**. You can **Edit** it or **Remove draft** until you mark it as sent.
## Send it yourself
Open the channel from the report: an email address opens your email program with the subject and the report filled in, and a web address opens the maintainers' page, where you paste the report. **Show the report** on the card has a copy button.
When you have sent it, select **Mark as sent** and set **When**. A sent report can't be changed: it is part of the incident's record.
## Track the answer and the fix
Each report on the card shows its status, the channel, when it was sent and answered, the answer and the fix:
| Status | Set with | What you record |
| - | - | - |
| **Draft** | **Save draft** | The channel, subject and report |
| **Sent** | **Mark as sent** | When you sent it |
| **Answered** | **Record their answer** | When, and **What they answered** |
| **Fixed upstream** | **Mark as fixed** | When, what they answered, and the **Link to the fix or their advisory** (`https://`) |
| **No answer** | **No answer** | When |
From **Sent**, record their answer, mark it as fixed or as no answer. A report with no answer can still be answered or fixed later. Every change lands in the [audit trail](/reports/audit-trail).
## Related
Reports from researchers, with replies and a triage log.
Where components and their external references come from.
Publish your own CSAF/VEX advisory once there is a fix.
How an incident runs from match to closing.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.