> ## 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. # Security advisories > Draft, review and publish CSAF 2.0 VEX advisories that tell customers which product versions a vulnerability affects and what to do. **Plans:** Every plan. On Free, published advisories stay public, but you can't draft or publish. **Who:** any member drafts, edits and requests review; owners and admins publish. An advisory tells your customers, for each version of your products, whether a vulnerability affects it and what to do. Pharus writes it as a CSAF 2.0 document with the VEX profile, the format customers' security tools read automatically, and publishes it on your public advisories page and in a machine-readable feed. Once a security update is available, the CRA asks you to share and publicly disclose information about fixed vulnerabilities (CRA Annex I, Part II, point (4)). ## Draft an advisory Go to **Advisories** and select **Draft advisory**. Enter a **Title**. Customers see it, so write it in English, like the rest of the CSAF document. For example "CVE-2021-44228 in Gateway G3". Under **Vulnerabilities**, search your matched vulnerabilities, or type any CVE or GHSA ID, and select **Add vulnerability**. You can add a vulnerability you aren't affected by, to tell customers so. Choose the **Product families** the advisory covers. Every version Pharus has seen for these families is listed in the advisory. Select **Create draft**. The advisory opens on its **Summary** tab with a tracking ID such as `NORDLYS-2026-0001`: your slug in capitals, the year and a running number. ### Draft from an incident On an incident's **Overview** tab, the **Customer advisory** card lists the advisories drafted from it and has a **Draft advisory** button. A draft started there is linked to the incident and prefilled with the incident's vulnerability, product family, a title and a summary. If the incident's latest CRA determination is that the product isn't affected, the draft carries that over as **Not affected**, with the rationale as the reason. Drills never feed an advisory. An advisory is linked to an incident only when you draft it from the incident. The advisory's header then links to the incident. To cover a report from the [disclosure inbox](/disclosure/inbox), declare an incident from it first, or draft the advisory under **Advisories** and add the vulnerability. ## Write the summary The **Summary** tab holds what customers read. Write it in English: their tools read the advisory in English. | Field | What it is | | - | - | | **Title** | The advisory's title. | | **TLP** | Who may see it. See [TLP](#tlp). | | **Vulnerabilities** | The vulnerability IDs the advisory covers. | | **Product families** | The families it covers. | | **Summary** | One or two sentences: what is affected and what customers should do. Left empty, Pharus writes a neutral default. | | **Details** | Optional. Background, timeline, how you assessed it. | | **References** | Links customers may need, each with a **URL** and a **Description**: release notes, firmware downloads, your own write-up. Select **Add reference** for each. | | **Acknowledgments** | People or organisations to credit, one per line. Credit a reporter here if they asked for it. | Select **Save draft** to keep your changes. ## Set the product status The **Products and status** tab has one row for each product family and vulnerability. Pharus fills in the status of every version from your SBOM matches and VEX decisions, and shows where each one comes from: | Source | Meaning | Status in the advisory | | - | - | - | | **From SBOM match** | A component in that version matches the vulnerability. | The match's VEX status. One affected component makes the version affected. | | **Not in the SBOM** | Pharus has read the family's SBOMs and no component matches. | **Not affected**, justification **Component not present**. | | **No SBOM yet** | Pharus has no SBOM for the family. | **Under investigation**. | | **Set in this advisory** | You set the status yourself. | Your choice. | A fix recorded on an incident for the same family and vulnerability becomes "Install a fixed version" for the affected versions. See [vulnerabilities](/monitoring/vulnerabilities) for VEX decisions on matches. To change a row, select **Set status**. Your choice applies to every listed version of the family in this advisory only; it doesn't change the VEX status of the match. **Use SBOM status** undoes it. | Status | What you add | | - | - | | **Affected** | **What customers should do**: Install a fixed version, Apply a mitigation, Use a workaround, No fix available yet or No fix planned. A mitigation or workaround needs **Instructions**; a fixed version needs instructions or a **Fixed in version**. | | **Not affected** | A **Justification**, a reason under **Why it isn't affected**, or both. | | **Fixed** | Optionally the **Fixed in version**. | | **Under investigation** | Nothing more. | The justifications are the CSAF ones: Component not present, Vulnerable code not present, Vulnerable code not in execute path, Vulnerable code cannot be controlled by adversary, and Inline mitigations already exist. **Fixed in version** adds that version to the advisory as fixed. Write it as a single version, such as `4.4`, not a range. With **Install a fixed version**, a **Fixed in version** and no instructions, the advisory tells customers "Update Gateway G3 to version 4.4 or later." When CISA KEV or ENISA EUVD lists a vulnerability as exploited, the document says so, and the public page marks it "Known to be exploited". ## Check the CSAF JSON The **CSAF JSON** tab shows the document as it will be published, as a draft preview of the next version, with **Copy JSON**. It checks the document against the CSAF 2.0 schema and the VEX profile tests. When everything passes, it says "The document passes the CSAF 2.0 schema and the VEX profile tests." Otherwise it lists each problem in plain language with its test number, for example a not-affected product with no reason, or an affected product with nothing for customers to do. You can't publish until the list is empty. ## Request review Select **Request review** to mark the draft **In review**. The header shows "Review requested by" and your name. Pharus records the request in the audit trail but sends no notification, so tell the reviewer yourself. ## Publish an advisory Owners and admins publish. Members see "Only admins and owners can publish." Select **Publish advisory** in the advisory's header. While the CSAF JSON tab lists problems, the button is disabled and a link says how many to fix. The first version is `1.0.0`. For later versions, choose **Update** (new information, products or statuses; for example `1.1.0`) or **Correction** (fixes a mistake without changing the substance; for example `1.0.1`), and write **What changed** for the revision history customers see. Select **Publish version** and the version number. For a TLP:WHITE advisory the dialog shows the public address. Publishing sets the document's status to final and its date to now, stores the exact document with its SHA-256 and SHA-512 hashes, and records it in the [audit trail](/reports/audit-trail). A TLP:WHITE version replaces the previous one in the feed and on the public page, at the same address. Published versions can't be changed or deleted. To fix one, publish a correction. ### Update a published advisory Edit any tab of a published advisory and it becomes a draft of its next version, marked "Unpublished changes". The public page and the feed keep the last published version until you publish the next one. ## Releases The **Releases** tab lists every published version, exactly as it was served: the version, when and by whom it was published, its TLP label, its SHA-256 and links to the JSON and its `.sha256` and `.sha512` files. The latest version is marked **Current**, earlier ones **Superseded**. Only the current TLP:WHITE version is public; members download the others here. ## TLP CSAF 2.0 uses the Traffic Light Protocol version 1 labels, so the app offers **TLP:WHITE — public**, **TLP:GREEN — community**, **TLP:AMBER — limited** and **TLP:RED — named recipients**. A new advisory starts as TLP:WHITE. Only TLP:WHITE advisories go to the public feed and the public pages. A TLP:GREEN, AMBER or RED version is recorded as a release and marked "Not in the public feed"; download it from **Releases** and share it with the recipients directly. If the latest version of an advisory has a label other than WHITE, the advisory is no longer in the feed or on the public pages. ## The public advisories page Published TLP:WHITE advisories appear at `https://app.pharussecurity.com/disclose//advisories`, newest first, with the title, tracking ID, publication date, last update and version. Each advisory has its own page at `https://app.pharussecurity.com/disclose//advisories/`, with the tracking ID in lower case, showing: * the summary and details * each vulnerability, marked "Known to be exploited" where that applies * a **Products** table with each product version, its status and **What to do** * references, the people credited under "Thanks to", and the revision history * a link to "This advisory as CSAF JSON" The page itself is in Norwegian or English, like the other public pages; the advisory's text is in English. In the app, a published advisory's header links to its **Public JSON** and **Public page**. ## The machine-readable feed Customers' tools read the same documents from your CSAF feed, starting at `https://app.pharussecurity.com/csaf//provider-metadata.json`. The **Advisories** page shows the address. Once you publish a TLP:WHITE advisory, your security.txt gets a `CSAF` line pointing to it. See [CSAF feed](/api-reference/csaf-feed). ## On Free Published advisories stay on the public page and in the feed. The **Advisories** pages are read-only: you can't draft, edit or publish until an owner starts a plan. They also stay up after an owner closes the workspace, until it is deleted. ## Related The public endpoints customers' tools read. Matches and the VEX decisions advisories start from. Draft an advisory from an incident. The public site your advisories are published on. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.