Use Case

Security vendor disclosure coordination
one engagement record from discovery to vendor advisory

When your AppSec, product security, or security engineering team finds a vulnerability in an external software vendor product, run the disclosure coordination as a structured engagement rather than as a one-off email thread. Track vendor contact, acknowledgement, triage, embargo, CVE assignment, advisory publication, and company-side remediation on one record. The closure history holds up under audit, customer assurance review, and your own published disclosure policy.

Get Started Free

No credit card required. Free plan available forever.

Security vendor disclosure coordination workflow for internal security teams

Internal AppSec, product security, and security engineering teams routinely find vulnerabilities in external vendor products: a SaaS application your company integrates with, a library you embed, a hardware vendor firmware your platform team operates, an open-source dependency at the bottom of the dependency tree, a third-party SDK shipped inside the product. When the bug belongs to the vendor, the company side is the discloser and the vendor PSIRT is the receiver. Done well, the coordination ends in a vendor advisory, a CVE, and a company-side remediation against the patch. Done badly, the disclosure dies in an engineer mailbox, the vendor goes silent past the policy window, and the next time the auditor asks for a vendor disclosure history there is no record to produce.

This page covers the operational workflow that turns vendor disclosure from a one-off email into a tracked engagement record. For the inverse workflow (running an inbound vulnerability disclosure programme where external researchers report into your product), read the VDP management workflow. For the vendor-side post-disclosure publication shape (how your own PSIRT handles intake to advisory publication), read the PSIRT product security incident response workflow. For the policy groundwork that names the disclosure window and the escalation route, read the practical VDP setup guide and the copy-ready vulnerability disclosure policy template. For the broader prioritisation model behind severity calls, see the vulnerability prioritisation framework.

Where vendor disclosure cases originate inside the workspace

A vendor disclosure case can land from any of the channels the security team already runs. Each intake source converts to the same structured engagement so the downstream coordination workflow does not depend on where the finding came from.

Internal AppSec or product security engineer

An AppSec engineer reviewing a third-party library, a SaaS integration, or a vendor SDK finds a vulnerability in the vendor product. The engagement opens with the vendor product name, the affected version range, the asset on the company side that exposed the bug, the reproduction steps, and the engineer who made the finding.

Penetration test against a vendor-hosted environment

A scoped pentest against a vendor SaaS surface or a third-party API uncovers a vulnerability that is not specific to the company tenant. The case opens against the vendor product record, the original pentest engagement is linked, and the chain from the tester evidence to the vendor advisory is reconstructible at audit time.

Authenticated or external scanner finding against a vendor asset

An authenticated or external scan against a vendor-hosted edge produces a finding that, on triage, is a vulnerability in the vendor product rather than a misconfiguration on the company side. The promotion captures the scanner source, the original finding identifier, and the rationale for treating the issue as a vendor disclosure rather than a company-side remediation task.

Code scanning against a forked or vendored open-source component

Code scanning against a connected repository surfaces a vulnerability in a vendored library, a forked open-source dependency, or a Git submodule. The case captures the upstream project, the affected commit range, the company fork status, and whether the report goes to the open-source maintainer, a CNA, or the downstream commercial distributor.

Customer or partner escalation about a third-party component

A customer or partner reports a vulnerability they hit in a third-party component embedded in the company stack. The case captures the reporter contact, the affected environment, and the urgency that drives the disclosure clock with the upstream vendor while the company side decides whether a workaround can ship before the vendor fix lands.

Bug bounty finding affecting an integrated vendor product

A bounty researcher submits a finding through the company programme that, on triage, is a vulnerability in an upstream vendor product the company integrates with. The case captures the researcher reference, the platform identifier, the embargo and credit terms agreed with the researcher, and the parallel coordination track with the upstream vendor that ships the actual fix.

The coordinated disclosure states the case moves through

Coordinated disclosure with an upstream vendor follows a defined sequence. The engagement carries the state, the timestamps, and the rationale per transition so the closure record reads cleanly against an audit lookback or a customer assurance review.

State	What the engagement captures
Discovered	Vulnerability confirmed against the vendor product. Reproduction evidence captured. Engagement opened with vendor name, product line, affected version range, and the original source attached.
Vendor contacted	Disclosure message sent through the vendor published channel (security.txt, PSIRT mailbox, web form, ISO 29147 contact, CNA route). The send timestamp, the channel, the message body, and the named vendor contact land on the activity log.
Acknowledgement received	Vendor acknowledged the report and the working reference (PSIRT ticket, vendor case ID, CNA tracking number). The acknowledgement timestamp closes the first SLA leg and starts the triage clock the workflow holds against the vendor.
Triage agreed	Vendor agreed on severity, scope, and remediation path. Disagreements (the vendor wants to mark a finding informational while the company side has working exploitation evidence) are captured with a documented rationale so the closure decision is defensible.
Fix in progress	Vendor confirmed a fix is in the engineering backlog with a target release. The case tracks the vendor target date, the company-side workaround in place, and the next status request the company will send if the vendor goes silent.
Embargo and disclosure window	Vendor agreed on a coordinated disclosure date. The case captures the embargo terms, the CVE assignment status (vendor-as-CNA, MITRE root CNA, or third-party CNA), the advisory draft for review, and the credit attribution the company side will accept.
Vendor advisory published	Vendor published the advisory with the agreed identifier (CVE, GHSA, vendor security bulletin, CNA-assigned record). The advisory link, the publication timestamp, the assigned identifier, and the public credit line land on the case for the audit trail.
Company-side remediation closed	The company side completes its own upgrade, configuration change, or workaround verification once the vendor patch ships. The retest evidence is paired to the original finding so the closure record covers both the upstream advisory and the company-side fix.
Escalation or non-response handling	Vendor missed the agreed milestone or went silent past the policy window. The case captures the escalation route (CERT/CC, JPCERT, CISA coordination, sector ISAC, national CSIRT), the deadline the company side committed to in its disclosure policy, and the public-disclosure decision if the vendor still does not respond.

Triage dispositions every vendor disclosure case closes with

Each case closes with a structured disposition. Consistent disposition recording keeps the disclosure programme defensible and gives the security team a clear answer when the vendor, the auditor, or the company leadership asks how a specific case was handled.

Confirmed in-scope vendor vulnerability

Reproducible, present in the current vendor release, attributable to the vendor product. Moves to the disclosure workflow with severity, vendor contact, SLA tier, and named internal coordinator.

Configuration on the company side

On triage, the issue is a misconfiguration in how the company deploys the vendor product rather than a vendor bug. Closed with the configuration fix referenced on the company side and the rationale visible to the original reporter.

Duplicate of vendor advisory

Vendor already published an advisory or the issue is a duplicate of an existing PSIRT case. Linked to the original vendor advisory record so credit and timeline are preserved.

Vendor end-of-life with no fix

Affected product version is out of support. Decision captured: drop the vendor, hold the company-side compensating control, or pay for extended support. The decision rationale lives on the engagement, not in a thread.

Embargoed multi-party disclosure

Issue affects multiple vendors at once and is being coordinated through a third party (CERT/CC, JPCERT, CISA). The case captures the coordinator, the embargo, and the company role in the multi-party advisory.

No fix planned by vendor

Vendor declined to fix the issue or marked it informational against the company assessment. Decision captured: accept the residual risk, escalate publicly under the disclosure policy, or move off the product. Each option carries a deadline rather than drifting indefinitely.

SLA ladder for vendor disclosure coordination

Disclosure coordination runs on tracked clocks rather than calendar reminders. The ladder below is a defensible starting point you can adapt to your own published disclosure policy. The engagement record holds the actual targets and the slippage history for each case. For the wider operating model behind SLA discipline, see the vulnerability SLA management workflow.

Clock	Default target	Notes
Vendor acknowledgement	5 business days	Time from the disclosure send to a human acknowledgement from the vendor. Public PSIRT teams routinely hit this. Silent vendors trigger the escalation route on the policy.
Vendor triage decision	15 business days	Time from acknowledgement to a triage decision (accepted, duplicate, configuration, no-fix, embargoed). The case carries the decision rationale, not a yes-or-no flag.
Vendor fix availability (critical)	90 days	Reasonable upper bound for a critical fix in a coordinated disclosure model. A 90-day public disclosure window is the default many disclosure policies cite, and the company side commits to disclose if the vendor passes the deadline without an agreed extension.
Vendor fix availability (high)	120 days	Operating bound for a high-severity vendor fix. Extension requests are recorded as state events on the case rather than as silent calendar slips.
Embargo expiry without fix	Per policy	When the agreed embargo passes without a vendor patch, the company side publishes its disclosure under the policy. The decision to publish carries a named approver and the rationale, not an automatic action.
Company-side workaround in place	30 days	Time for the company side to deploy a workaround (configuration change, WAF rule, control disablement, alternate vendor swap) for any case where exploitation is feasible before the vendor fix lands.

Where vendor disclosure breaks in production

Vendor disclosures rarely break because the engineer who found the bug did the wrong thing. They break because the workflow around the engineer is informal, single-threaded, and unrecorded. Each failure mode below is one the workflow is built to prevent rather than survive.

Vendor disclosure handled through one engineer email inbox

When the disclosure conversation lives in one engineer mailbox, the chain breaks at staff turnover, at vacation cover, and at the moment the auditor asks for the response history. Converting every disclosure into an engagement on intake removes the single-point-of-failure entirely.

No tracked clock from disclosure send to vendor acknowledgement

Without a tracked clock, the company side discovers the vendor never responded only when the issue resurfaces months later. SLA timers tied to disclosure send convert silent drift into a visible escalation trigger before the embargo runs out.

Embargo and credit terms agreed in a single email thread

Embargo terms (the disclosure date, the CVE assignment route, the credit line, the press treatment) need to live on a structured field, not paraphrased from a thread. The advisory text the vendor publishes is the artefact your customers will read; the company side needs a defensible record of what was agreed.

No paper trail when the vendor goes silent and the policy clock expires

A disclosure policy that allows public disclosure after a vendor non-response window is only enforceable if the silent intervals, the escalation attempts, and the public-disclosure approval all sit on one record. Reconstructing the history from email exports after the fact undermines the policy in public.

No link between the vendor advisory and the company-side remediation

The vendor advisory lands, the company side upgrades, and the two records sit in different tools. Pairing the upstream advisory identifier with the company-side retest evidence on one engagement keeps the closure record honest under SOC 2, ISO 27001, NIS2, and DORA reviews.

Standards and frameworks the workflow reads against

Vendor disclosure coordination sits inside several frameworks that increasingly expect the company side to demonstrate, not assert, how it handles vulnerabilities discovered in suppliers and third-party components. Running the workflow as a structured engagement per case makes the same dataset useful for each framework without re-keying evidence every audit cycle.

ISO/IEC 29147

Vulnerability disclosure handling. The standard expects a published policy, a defined intake channel, acknowledgement, triage, remediation tracking, and coordinated public disclosure. This workflow is the same standard read from the reporter side: how a company that finds a vulnerability in a vendor product coordinates a disclosure that the vendor PSIRT will receive under its own 29147 process.

ISO/IEC 30111

Internal vulnerability handling processes. Whether you are receiving disclosures or sending them, the standard expects defined roles, triage criteria, internal communication, and remediation governance. The internal coordinator, the named approvers for embargo and escalation, and the audit log map straight to the same clauses.

FIRST PSIRT Services Framework

The FIRST framework defines the PSIRT operating shape. Reading it from the discloser side, the same operating disciplines (triage, coordination, advisory handling, embargo management, multi-party disclosure) apply. A structured engagement per disclosure makes the company side a competent counterparty to the vendor PSIRT it talks to.

CERT/CC and ISO/IEC 30111 coordination

Multi-vendor coordinated disclosure routes through CERT/CC, JPCERT, or a sector ISAC. The case carries the coordinator, the coordination reference, the embargo terms, and the company contribution to the multi-vendor advisory so the participation is auditable rather than reconstructed from a coordinator email thread.

EU CRA, NIS2, and DORA

The EU Cyber Resilience Act, NIS2 Directive, and DORA all increasingly require defensible vulnerability handling evidence across the third-party software estate. The disclosure history per vendor case is the artefact a regulator or auditor reads when they ask how the company manages vulnerabilities introduced by its vendors.

SOC 2 and ISO 27001

Trust Services Criteria and Annex A controls increasingly expect evidence of how the security team handles vulnerabilities the team itself discovers in suppliers and third-party components. The per-case closure record is the audit artefact that demonstrates the process is operating, not only published.

How vendor disclosure coordination uses the platform

The workflow runs on the same record substrate the rest of the security programme uses. There is no separate disclosure tool to integrate with, and there is no hidden record the auditor has to chase. Each capability below is verified product surface rather than promised behaviour.

Engagement per vendor case

Each vendor disclosure opens a structured engagement on the workspace. The engagement carries the vendor name, the product line, the affected version range, the assigned internal coordinator, the disclosure timeline, and the linked source (the AppSec finding, the pentest engagement, the scanner finding, or the bounty handoff that originated the case).

Findings with CVSS 3.1

The vulnerability lands as a structured finding with a CVSS 3.1 vector, environmental modifiers reasoned for the deployed environment, reproduction evidence, request and response captures, and the company-side severity. When the vendor disagrees with the severity, both vectors live on the record so the disagreement is auditable rather than implicit.

Document management for the chain

The disclosure message text, the vendor acknowledgement, the embargo agreement, the advisory drafts, the CNA correspondence, and the published vendor advisory all attach to the engagement through document management. The audit lookback reads one folder per case rather than an email export job.

Activity log with timestamps

Every state transition (vendor contacted, acknowledgement received, triage agreed, embargo set, advisory published, case closed) lands on the activity log with the actor and the timestamp. The CSV export gives the audit team the chain in their preferred format.

Internal coordination notes

Internal triage debate, the workaround decision, the legal review of the public disclosure text, and the leadership escalation thread land on the finding through finding comments and collaboration so the operating context survives a coordinator change.

RBAC and MFA for sensitive cases

Embargoed cases are scoped to the named coordinator and the approval chain through team management with MFA enforcement on the workspace. The embargo discipline is technical, not a hope.

Exception register for accepted risk

When a vendor declines to fix or ships an end-of-life decision, the residual-risk decision lives in the finding overrides register with rationale, named approver, expiry, and the compensating control reference, rather than dissolving into a verbal acceptance.

AI-assisted disclosure narrative

AI report generation derives the leadership summary, the customer notice draft, and the audit pack narrative from the live engagement. The leadership view, the operational queue, and the audit lookback all read against one source rather than three reconstructions.

What SecPortal does not do for vendor disclosure coordination

The workflow is honest about the surface it covers. SecPortal is the engagement, findings, evidence, activity-log, exception-register, and reporting substrate the coordination runs on. It does not pretend to be the disclosure brokerage or the CVE assignment automation. The list below states what is out of scope so the operating decision is informed.

SecPortal does not send the vendor email or web-form submission on your behalf; the workflow captures the message body and the send timestamp as a document artefact, but the disclosure transmission happens through the vendor own channel.
SecPortal does not submit CVE requests to MITRE, CNAs, GitHub Security Advisory, or third-party CNAs on your behalf; the workflow captures the assignment route, the reference, and the assigned identifier on the engagement for the audit chain.
SecPortal does not integrate with PSIRT ticketing systems on the vendor side, does not integrate with bug bounty platforms (HackerOne, Bugcrowd, Intigriti) through API, does not integrate with CERT/CC, JPCERT, or sector ISAC coordination platforms.
SecPortal does not integrate with Jira, ServiceNow, Slack, SIEM, or SOAR through packaged connectors. State changes that need to land in those systems are exported from the activity log CSV or summarised through AI reports.
SecPortal does not host a CNA-grade CVE assignment workflow, does not parse vendor advisory feeds into a queryable advisory graph, and does not maintain a continuously refreshed CISA KEV or FIRST EPSS feed inside the workspace.

How vendor disclosure connects to the rest of the workflow

Vendor disclosure cases share the workspace with the rest of the security programme. A vendor advisory that becomes a significant incident moves into incident response without re-keying evidence. A vendor disclosure that pairs to a CISA KEV listing or a high EPSS score reads against zero-day and emergency vulnerability response for the company-side rapid-fix track. The vendor patch closure is paired against the same record the original finding opened on, so retest evidence and fix verification attach to the original disclosure rather than to a parallel ticket. Findings sourced from a connected repository against a vendored dependency feed dependency vulnerability triage with the upstream advisory linked, and the closure record carries straight through to the audit fieldwork evidence request fulfillment workflow when the auditor asks how the company manages vendor vulnerability handling. For framework-specific evidence packs, the same finding records map straight into ISO 27001, SOC 2, NIS2, DORA, and EU CRA evidence packs.

For internal security and AppSec teams

Internal security teams and AppSec teams run vendor disclosure coordination on the same workspace they use for the rest of the security programme. The engineer who finds the bug, the coordinator who runs the disclosure clock, the security lead who approves the public disclosure, and the GRC owner who pulls the evidence at audit time all read against one record.

For product security and security leadership

Product security teams and CISO functions use the per-vendor case register as the evidence base for supplier security reviews, for board-level conversations about vendor risk, and for the customer assurance pack a buyer asks for during procurement.

Vendor disclosure coordination is a discipline most security programmes do partially and almost none do consistently. The difference between a programme that closes vendor advisories on time and one that loses them in a mailbox is rarely the engineer who finds the bug. It is the workflow record around the engineer: the engagement, the SLA clock, the embargo decision, the escalation route, and the closure evidence. Get the record right and the next vendor advisory is auditable on the day it ships rather than reconstructible a year later when someone asks how it was handled.

Frequently asked questions about vendor disclosure coordination

What is security vendor disclosure coordination?

Security vendor disclosure coordination is the operational workflow an internal security, AppSec, or product security team runs when its own engineers, scanners, or testers discover a vulnerability in an external software vendor product (a SaaS application, a vendor library, a hardware vendor firmware, an open-source dependency, a third-party SDK). The team becomes the discloser and the upstream vendor PSIRT becomes the receiver. The workflow covers reproduction, vendor contact, SLA tracking, embargo and credit negotiation, CVE assignment, advisory publication, and company-side remediation against the vendor patch.

How is vendor disclosure coordination different from running a VDP?

Running a vulnerability disclosure programme is the inbound shape: external researchers report vulnerabilities to your product. Vendor disclosure coordination is the inverse: your team discovers a vulnerability in someone else product and coordinates a responsible disclosure with the vendor PSIRT. Both workflows touch CVSS scoring, severity decisions, retest evidence, and audit artefacts, but the counterparty, the SLA pressure direction, and the closure record contents are different. SecPortal supports the workflow in both directions on the same engagement and findings record.

How is this different from PSIRT product security incident response?

PSIRT product security incident response is what a vendor runs when a vulnerability is reported in its own product. Vendor disclosure coordination is what a customer or downstream consumer runs when they find a vulnerability in a vendor product. The two workflows are mirror images. SecPortal supports both, with the PSIRT workflow on `/use-cases/psirt-product-security-incident-response` covering the vendor side and this page covering the disclosing customer side.

When should we publish a vendor disclosure if the vendor is silent?

The decision sits on the disclosure policy you publish, not on a single case. A common operating model is a 90-day window from disclosure send to public publication, with an extension path documented when the vendor is engaged and progressing. A non-responsive vendor passes the deadline and the company side publishes under its policy with a named approver and the rationale recorded. The case carries every escalation attempt, every silent interval, and the approval timestamp so the public disclosure is defensible rather than reactive.

How should we handle CVE assignment when disclosing to a vendor?

Vendors that are CNAs assign their own CVE for findings inside their product. For vendors that are not CNAs, the company side can request a CVE through the MITRE root CNA, through a CNA of last resort, or through a third-party CNA covering the product class. The case captures the assignment route, the assigned identifier, and the embargo until publication. SecPortal does not submit CVE requests on behalf of the company; the workflow captures the decision, the rationale, the request reference, and the published CVE on the engagement record for the audit chain.

How do we coordinate an embargo without losing the audit trail?

Embargo terms (the agreed disclosure date, the CVE assignment route, the credit line, the joint advisory text, the press treatment) live as structured fields on the engagement, not paraphrased in an email thread. The activity log captures every state change. The closure record holds the agreed advisory text, the publication timestamp, the credit attribution, and any extensions or escalations agreed during the embargo. The audit lookback reads one record rather than a reconstruction across mailboxes.

What if the vendor disputes the severity or marks the finding informational?

Disagreements are common: the vendor wants to mark a finding informational while the company side has working exploitation evidence. The case captures the company CVSS 3.1 vector with environmental modifiers reasoned for the deployed environment, the working reproduction evidence, the vendor severity decision, and the company decision (accept, escalate to a coordinator like CERT/CC or a CNA of last resort, publish under the disclosure policy after the policy window). The decision rationale is the artefact that defends the public disclosure to customers, auditors, and regulators.

How it works in SecPortal

A streamlined workflow from start to finish.

Open one engagement per vendor disclosure case

Convert the discovered vulnerability into a structured engagement record with the vendor name, the product line, the affected version range, the company-side asset that surfaced the issue, the original source (AppSec finding, pentest, scanner, bounty handoff), and the named internal coordinator who will own the disclosure clock end to end.

Capture the finding with calibrated severity and reproducibility evidence

Record the finding on the engagement with a CVSS 3.1 vector, environmental modifiers reasoned for the deployed environment, the reproduction steps, the request and response or trace evidence, and the working proof of concept. The severity record is the artefact the company side will defend if the vendor disagrees with the call later in the coordination.

Send the disclosure through the vendor published channel and start the clock

Send the disclosure message through the vendor security.txt contact, PSIRT mailbox, web form, or CNA-routed channel. Capture the send timestamp, the channel, the message body as a document attached to the engagement, and the named vendor contact if one is known. The acknowledgement SLA clock starts the moment the message leaves the company side.

Track vendor acknowledgement, triage, and embargo terms

Record the vendor acknowledgement timestamp, the assigned PSIRT case identifier, the agreed triage decision, the planned fix release, and the embargo terms (the disclosure date, the CVE assignment route, the credit line, the joint advisory text). Each state transition lands on the activity log so the audit trail does not depend on a memory of an email thread.

Hold workarounds and escalation routes through the vendor delay

Where vendor fix availability runs against the company exposure, capture the workaround in place (configuration change, WAF rule, alternate vendor swap, control disablement) as a documented compensating control with an expiry. If the vendor goes silent past the policy window, the case carries the escalation route (CERT/CC, JPCERT, CISA coordination, sector ISAC, public disclosure) and the named approver who can trigger the next step.

Pair vendor advisory publication with company-side remediation evidence

When the vendor publishes the advisory, capture the assigned identifier (CVE, GHSA, vendor security bulletin), the publication timestamp, the agreed credit, and the public advisory link on the case. The company-side remediation closes the original finding with retest evidence paired to the disclosure record. The audit lookback reads one record covering both the upstream advisory and the company-side fix rather than two stitched datasets.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Every action recorded across the workspace

Finding comments and collaboration on the same record as the work

Finding overrides that survive every scan cycle

AI-powered reports in seconds, not days

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

Your brand. Your portal. Your clients love it.

Run vendor disclosure on one defensible engagement record

Vendor contact, embargo, CVE assignment, advisory publication, and company-side remediation on one record. Activity log, exception register, AI report, and audit pack from the same source. Start free.