Vulnerability Management

When a security issue lands in your product, two questions need answering fast: which customers are exposed, and how do you tell them. Vulnerability Management answers both from inside Distr. You record the issue as a security advisory, mark the versions it affects, and Distr tells you which customers deployed or downloaded those versions. When you are ready, you publish, and the affected customers see the advisory in their portal.

A security advisory is the record you write and disclose. It is not the same thing as the underlying vulnerability: one advisory describes one issue for your product, in your words, scoped to your versions.

How it works

You create a security advisory. It starts in Draft and is visible only to your team.
You mark the application and artifact versions it affects, and the versions that carry the patch.
Distr shows you the affected customers: every deployment that has run an affected application version, labelled by where it stands now, and registry pulls of an affected artifact version.
You write the description in Markdown, add tags and link to public CVE databases or your own release notes.
When the advisory is ready, you Publish it. Affected customers now see it.
Once a patch has shipped, you mark the advisory as Resolved.

Publishing opens the advisory’s timeline, which records every step from there on, together with any notes your team adds.

Status lifecycle

Status	Customer visible	Meaning
Triage	No	Reported through the API and waiting to be assessed. Nothing is committed to yet.
Draft	No	The advisory is being written. Content is settled but not yet disclosed.
Active	Yes	Disclosed to affected customers.
Resolved	Yes	A patch has shipped. Stays visible so customers can confirm they are covered.
Canceled	No	Closed without disclosure: a duplicate, a false report or not applicable.

These are the vendor’s own labels and only your team sees them. The status is called published in the API and the SDK, where the name has not changed; Active is how the same status reads in the interface, because that is what it means once the advisory is out.

Where an advisory starts

An advisory you create in Distr starts in Draft, because you are writing it yourself and there is nothing to assess first. The form lets you pick another status right away if the advisory is ready to go out.

Triage is the inbox for issues that arrive through the API or the SDK, typically from a researcher intake form, a security mailbox or a scanner pipeline. Those land somewhere your team can review them before deciding whether they are worth an advisory. Creating an advisory programmatically therefore defaults to triage; send "status": "draft" to skip the inbox.

Changing the status

The status badge on the advisory list and on the detail page is itself a dropdown: click it and pick any status. There is no prescribed order, so you can disclose an advisory straight out of triage, unpublish one you sent out too early, resolve it once the patch has shipped and reopen it later. The severity badge works the same way, which is what a re-assessment usually comes down to.

A status change that crosses the line between the statuses customers can see and the ones they cannot asks you to confirm it first, because it either discloses the advisory or withdraws it from the customer portal. Changes on one side of that line, such as resolving an advisory that is already Active or moving a triaged report to Draft, apply straight away.

Canceling is the right ending for a report that turns out to be a duplicate, a false positive or an issue that does not apply to your product. A canceled advisory keeps its timeline, so the reasoning behind the decision stays on record.

CVE ID

An advisory can carry the CVE ID of the issue it describes. It is optional: plenty of issues worth disclosing never get a CVE, and those advisories are identified by their title alone. On the detail page it is shown in the References panel, above the links.

A CVE ID can be used by at most one advisory per organization, so that customers never have to work out which of two entries about the same CVE is the current one. Matching ignores case, and saving an advisory with a CVE ID that another one already carries is rejected. If you find yourself wanting a second entry for the same CVE, edit the existing advisory instead.

Severity

Severity is a hand-picked label rather than a computed CVSS score: None, Low, Medium, High or Critical. You decide what the issue means in the context of your product, which is usually more useful to your customers than an upstream score computed without knowledge of how the affected component is used.

If you want to publish the underlying CVSS vector as well, add it to the description or link to the CVE entry as a reference.

Filtering the list

The list has a free-text search that matches the title, CVE ID, status, severity and tags, next to three dropdowns for severity, status and tags.

Each dropdown takes any number of values, and picking several widens the result rather than narrowing it: selecting High and Critical shows both. Leaving a dropdown empty means it does not filter at all. The dropdowns combine with each other and with the search, which is what you want for a query like “critical and high advisories tagged runtime that are still in triage”.

The status dropdown starts with every status except Canceled selected, so advisories you decided not to disclose stay out of the way. Tick Canceled to bring them back, or use Select all to see everything.

Customers and partners get the search and the severity dropdown only. There is no status filter, because they are shown Affected or Not affected rather than the status, and no tag dropdown for customers, because the list of tags in use across your organization is not exposed to them.

Marking affected versions

Affected versions drive both the impact analysis and customer visibility, so it is worth being precise.

In the Versions tab of the advisory form you can mark, per version:

Affected: the version contains the vulnerability.
Patched: the version carries the patch. Customers use this to work out where to upgrade to, and the advisory lists these versions under Patched In.

“Affected” is always the exposure and “patched” is always the remedy, which is why neither word is used for the advisory’s own status.

Both application versions and registry artifact versions can be marked. For artifacts, selecting a version also covers every tag pointing at the same image digest, so selecting a digest will not miss customers who pulled it by tag. Artifact versions are listed by their tags with the digest underneath, the same way they appear when you pick versions for an artifact entitlement, and the version panel on the advisory shows them the same way.

Marking an artifact version does not pin it. Registry tags stay deletable and overwritable while an advisory refers to them, and deleting or overwriting one drops the marking with it. If that was the only affected version left, the advisory stops being shown to customers until you mark a current one.

Seeing affected customers

The advisory detail page shows two impact tables. Every row of every customer is only ever visible to your own team: partners see only the customers assigned to their partner organization, and a customer sees only itself, as described under What customers see.

Deployments lists one row per deployment that has ever run an affected application version. Each row is classified by the version its current revision runs:

Affected: it still runs a version you marked as affected. These are the customers to contact.
Patched: it now runs a version you marked as patched. The upgrade has landed and no further action is needed.
Not affected: it has moved off the affected version, but onto one you marked neither affected nor patched. It is no longer running a release you have flagged as vulnerable, though Distr cannot confirm it carries the patch.

Alongside the state, each row shows the most recent affected version the deployment ran and when it last ran it. That stays visible even once a deployment is patched, because it is the exposure window you need when deciding who to notify.

A large number of Not affected rows usually means you marked the affected versions but never marked the release carrying the patch. Marking it turns those rows into Patched.

Artifact Downloads lists registry pulls of affected artifact versions, grouped by customer and version, with a pull count and the last pull time. Note that a download is not the same as a deployment. Distr records who pulled an artifact, but nothing links an artifact version to an application version, so this table tells you who obtained the affected artifact rather than who is currently running it. There is no state column for the same reason: the closest thing to evidence that a customer took the patch is that they later pulled a version you marked as patched, which is a fact about the artifact as a whole rather than about any one of these rows.

What customers see

A customer sees an advisory only when all of the following hold:

Vulnerability Management is enabled for your organization.
The advisory is Active or Resolved.
The customer has deployed an affected application version, or is entitled to at least one affected version.

An advisory without an affected version is not shown to customers. Mark at least one version as affected before publishing if customers should receive the advisory.

Deployments are the first thing checked, because they are the strongest evidence that a customer is exposed. If a customer’s deployment ever ran an affected application version, they see the advisory, whether or not they hold a matching entitlement. This is the same set of customers that the Deployments impact table reports to you, so the two views never disagree. Customers who have already upgraded stay included: the advisory is how they confirm they are covered. There is no equivalent for artifacts, because a gated artifact cannot be pulled without an entitlement in the first place.

Entitlements are checked next, and are evaluated per resource type. For applications, the customer must hold an unexpired application entitlement covering an affected application version; an entitlement that does not pin specific versions covers every version of its application. For artifacts, the customer must hold an unexpired artifact entitlement covering an affected artifact.

As elsewhere in Distr, entitlements are only a restriction once you use them. If you have configured no application entitlements at all, every customer is treated as entitled to every application version, and the same holds independently for artifacts. Vendors who do not use the licensing feature therefore still reach all of their customers.

Customers see the title, severity, CVE ID, tags, description, references and the affected and patched versions. They do not see the timeline or who on your team wrote the advisory, since the timeline is an internal record and often contains notes you would not want to disclose. Neither does a partner.

Which versions a customer is shown

Entitlements decide not only whether an advisory is visible but also which of its versions it discloses. A customer is shown a marked version when they are entitled to it, or when they already have it because they deployed or downloaded it. Everything else is withheld, on both the affected and the patched side, and the version count in their list reflects only what they can see. If none of the patched versions are theirs, the advisory shows no patch at all rather than naming a release they cannot obtain, and the summary above their exposure table says that no patched version has been released yet.

This matters most for backported patches. An advisory covering 1.3.0 and 1.5.0 with patches in 1.3.1 and 1.5.1 should not tell a customer on the 1.3 line to upgrade to 1.5.1, and it must not disclose a patch published in an application they have no access to at all.

Partners read advisories on behalf of the customers assigned to them rather than for themselves, so they are gated by disclosure alone: a partner sees every Active and Resolved advisory that marks an affected version, with all of its versions, and none of your drafts or triage. What is scoped to their own customers are the impact tables.

In place of the status they see whether the advisory is a live problem for them, Affected or Not affected. The status is never shown to them, and neither is the date you resolved it: the editorial workflow is your business, and telling a customer an advisory is “resolved” says nothing about whether they have taken the upgrade. Partners see the same two labels, computed across the customers assigned to them.

A customer is Affected when either of the following holds:

One of their deployments still runs a version you marked as affected.
They pulled an affected version of an artifact and have not since pulled a version of that same artifact that you marked as patched. Because a pull cannot be observed the way a running deployment can, taking the patch is the only signal available, and it is tracked per artifact: pulling the patch for one artifact does not settle an advisory that covers two.

Alongside it, Your Exposure shows the customer their own half of the impact tables: their deployments that have run an affected version and their own downloads of an affected artifact version, with the same Affected, Patched and Not affected states you see. Rows belonging to other customers are never included. A summary above the table states whether they are still exposed and what to do about it, so a customer who has already upgraded is told that they might no longer be affected instead of having to compare version numbers themselves. It is worded as a possibility on purpose: Distr knows which versions they deployed or downloaded, not what each of their own installations is running right now. This is also why an advisory stays visible after a customer upgrades.

Customers reach advisories under Security in their portal sidebar.

References

References are links displayed alongside the advisory. Typical uses are the NVD or GitHub Advisory Database entry for a CVE, an upstream project’s advisory or your own release notes. Each reference can carry an optional label; without one, the URL is shown.

Timeline

Every advisory keeps an append-only timeline recording who published it, who changed its status afterwards and who edited it. One save writes one entry listing everything it changed, so an edit reads as the single action it was. Your team can add notes to the timeline, which is a good place for investigation findings, decisions about severity and coordination with upstream maintainers.

The timeline is the record of a disclosure, so it begins at the disclosure: publishing is always its first entry, and the drafting that came before it is not recorded. An advisory is rewritten until it is right, and none of that is worth reading afterwards. Notes are the exception and are kept whenever you write them, including during triage.

The timeline is never shown to customers.

Relationship to vulnerability scanning

Security advisories and Vulnerability Scanning solve different problems and work well together.

Scanning is automated and runs in your CI pipeline, producing a report of everything known CVE databases flag in a given build. It is broad and noisy by design.

Security advisories are manual and curated. They cover the issues you have decided are worth communicating, whether they came from a scan, a security researcher, an upstream advisory or your own code review. Use scanning to find candidates, and advisories to triage, assess and disclose the ones that matter.

Next steps

Application Entitlements: Control which customers can access specific application versions, which in turn controls who sees an advisory.
Vulnerability Scanning: Automate CVE discovery in CI and attach reports to your versions.
Support Bundles: Collect diagnostic data from customer environments when investigating a report.