When a vulnerability lands in one of your products, the scanner findings and the SBOM tell you what’s wrong internally. The next job is the hard one: tell your customers, in a form they can act on, and prove you did it. That is the Product Security Incident Response Team (PSIRT) function — and most teams run it out of a spreadsheet and a mail-merge.
Talarity’s Product Advisories page is a real PSIRT surface. Author an advisory about your own product, score it with CVSS v3.1, export a machine-readable CSAF 2.0 document, see instantly whether any of its CVEs are in the CISA Known Exploited Vulnerabilities catalog, and notify affected customers — all on a coordinated-disclosure lifecycle (draft → published → withdrawn) with a per-org advisory number.
The advisory register
Open Application Security → Findings & Supply Chain, on the Advisories tab. Every advisory is one row: its ADV-YYYY-NNNN number, title, severity with its CVSS score when a vector is recorded, status (draft / published / withdrawn), a KEV column, and its publication date. The number is assigned at publish time, so a draft has none and its cell reads Unnumbered — the word “Draft” is not repeated there, because the status column three cells along already says it.
The KEV column lights up Exploited when one of the advisory’s CVEs is in the CISA catalog, reads Not listed when its CVEs were checked and none is, and No CVEs when there is nothing to check — three different answers, never one ambiguous dash.
Advisories are organisation-level by nature, so this page is never narrowed by linked account: an advisory is about a product you ship, not about one subsidiary’s code. You will not see the scope band the other AppSec pages paint, and its absence here is correct rather than an oversight.
Drafts don’t burn a number, so your public advisory IDs stay dense and sequential. The register sorts published first, then drafts, then withdrawn, each band ordered by severity — so the thing a customer is most likely to be asking about is the thing at the top.
One thing to know before your first advisory: on a brand-new organisation, with nothing in the register at all, the search box and the two filters are not drawn. There is nothing to filter yet, and the empty state explains what the page is for instead.
Draft it, and let CVSS do the scoring
Click + New advisory. Write the title and the summary — the summary is optional to save but required to publish, so it is worth writing now — then enter the CVSS v3.1 vector. Talarity computes the base score on the server, using the exact FIRST specification formula rounded up to one decimal, and the derived score and severity become authoritative: the Severity field greys out, because the vector governs it. Clear the vector and the field is yours again.
Scoring on the server matters more than it sounds. There is exactly one CVSS implementation in the product, and the browser is not a second copy of it — so the score in this preview is the same number that reaches the CSAF document, the customer email and your own reporting. Add the affected products and version ranges, the CVE identifiers and the CWE weakness classes below, and everything you record flows into the machine-readable export.
A draft is private and fully editable. Its own footer carries Edit, Download CSAF, Delete draft and Publish… — so a draft that turns out to be wrong is simply deleted, and only publishing is one-way.
The CISA-KEV check, on the draft as well as the published advisory
The KEV check does not wait for publication. As soon as an advisory carries a CVE, Talarity matches it against the CISA Known Exploited Vulnerabilities catalog and says so — in the register’s KEV column and, in full, at the top of the advisory itself.
That badge is the single most important signal a customer has when deciding how fast to patch, and the catalog behind it is kept current by a nightly sync of the live CISA feed — so the check reflects present-day exploited-in-the-wild status rather than a snapshot taken when the advisory was written. Further down the same drawer, the matched CVEs are listed with the catalog’s own fields, including the BOD 22-01 remediation due date that US federal agencies are bound by.
Note the status chip in that picture. This advisory is a draft — it has not been disclosed to anyone, and its detail drawer is the authoring view, not the public record. It stays that way: it is a worked example held permanently in draft, and nothing in this walkthrough publishes it. The advisory in the next two sections is a different one — ADV-2026-0001, the payments-webhook denial of service from the register above.
Publish — the irreversible step
Publishing is the irreversible part, so read this before you click it. Publishing an advisory is a public disclosure: it becomes readable by anyone on the internet through your organisation’s Trust Center once that Trust Center is active, there is no per-advisory opt-in because publishing is the opt-in, and a published advisory can never be edited again. The only exit is a terminal withdrawal, covered below. Talarity states all of that in a confirmation dialog before it happens, and everything up to that moment is a draft you can rewrite freely — which is why the advisory number is not assigned until you publish.
A published advisory carries the whole picture, and it is honest about its own reach: until the Trust Center is active, the drawer says so in as many words rather than implying the advisory is already out there.
Every advisory — draft, published or withdrawn — can be downloaded as a CSAF 2.0 JSON document, the OASIS standard your customers’ own tooling can ingest automatically.
Notify the customers who are affected
Click Notify customers. Build the recipient list a row at a time: an app user (chosen by name from your org, not a raw id), an email address, or a contact from your address book. App users get an in-app notification that deep-links straight to the advisory; email addresses and contacts get an email through the standard mail queue, carrying the remediation and — once your Trust Center is active — a link to it. Talarity resolves that link when it sends and omits it when there is nothing to point at, rather than mailing your customers a URL that 404s.
If your organisation has no app users or no contacts to pick from, the composer says which, and points you at the email option instead — and if those lists fail to load, it says that, with a Retry, rather than showing you an empty picker that looks the same. It is a small distinction that matters at 2am.
Talarity then records the outcome per recipient, not just the send: the four tallies on the advisory (Recipients, Delivered, Queued, Not delivered) are backed by a table naming each recipient, the channel used, and what happened — because queued is not delivered, and an advisory programme that cannot tell the difference cannot prove it notified anybody.
Withdraw and reissue — never quietly edit
A published advisory is a public record, so you don’t silently edit it. If it turns out to be inaccurate or is superseded, you withdraw it, with a reason that is optional to the system and worth writing every time — it is shown to your customers. Withdrawal is terminal for editing — but not for communication. A withdrawn advisory that was published keeps two actions: download the (now withdrawal-stamped) CSAF document, and Notify customers of withdrawal. Use the second one. The people who were told about the original advisory are exactly the people who need to hear that it was withdrawn, and a withdrawal nobody is told about leaves your customers acting on guidance you no longer stand behind. Then issue a fresh advisory in its place.
Find what you need
Filter the register by status or severity, or search across advisory titles and summaries — pull “every published advisory” or “every critical” in one click.
What you walk away with
A coordinated-disclosure PSIRT workflow that produces audit-ready, machine-readable advisories: CVSS-scored on the FIRST specification, exported as CSAF 2.0, checked live against the CISA KEV catalog from the first draft onwards, published under a per-org advisory number, and pushed to the customers who need them — with per-recipient delivery evidence and a withdraw-and-reissue discipline that keeps your public record honest.
The page maps to the standards your customers’ security teams already speak: CVSS v3.1 (FIRST.org, base-metric group), CSAF 2.0 (OASIS, the machine-readable successor to CVRF), the CISA Known Exploited Vulnerabilities catalog (BOD 22-01), and the coordinated-disclosure practice of ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), operationalized the way the FIRST PSIRT Services Framework describes.