Page History
...
- Should you disclose at all? – Generally, the answer will be yes, but there may be factors that influence this decision. For example, some vulnerabilities, if exploited, could place lives in danger or cause severe socioeconomic harm. As a result, it may be prudent for reports of such vulnerabilities to be held indefinitely until the population of vulnerable systems has been reduced through patching or obsolescence. However, any decision to defer disclosure should be considered provisional or contingent on the continued absence of evidence of exploitation or adversarial knowledge of the vulnerability.
- What information will you disclose? – For example, will you publish all information about the vulnerability, including proof of concept code, or will you only release a brief description of the problem and a remediation? Generally speaking, there is a minimum amount of information required in order for a vulnerability report to be useful. Recall that the point of disclosure is to provoke some action, most often by deployers or any downstream vendors who were not already involved in the coordination process. If the details provided to the recipient are insufficient to cause that action to be taken, the disclosure process will not succeed.
- To whom will you disclose? – In most cases, the disclosure should be made publicly. However, in some scenarios the disclosure may be to a specific limited group. For example, if the pool of users is small and the vendor reaches out to every impacted user, a public disclosure may be unnecessary.
Wiki Markup Via
what
channel(s)
will
you
disclose?
_ -– Will
the
vulnerability
information
be
published
on
the
vendor's
website?
The
reporter's
blog?
BugTraq
\[1],
Full
Disclosure
\[2],
or
other
mailing
lists?
Will
you
draw
attention
to
it
on
social
media?
There
are
pros
and
cons
to
most
of
these
options
that
must
be
weighed.
When
available,
an
organization's
communications
or
public
relations
groups
should
be
involved
in
planning
for
the
disclosure
process.
While
it
is
usually
neither
possible
nor
practical
to
have
every
CVD
case
flow
through
them,
leveraging
their
expertise
in
planning
and
developing
the
CVD
capability
can
improve
the
process
considerably.
- What is your expectation of others in disclosing further (or not)? – Be sure to discuss your expectations with all stakeholders and be prepared to negotiate.
...
The Traffic Light Protocol (TLP) may be useful when sharing draft information. We discuss applications of TLP to CVD in Section 7.2.2.1 Appendix B.
An example of a template for a vulnerability disclosure document is provided in the appendices.
Publishing
...
Once
...
the
...
draft
...
circulation
...
phase
...
is
...
complete,
...
the
...
next
...
step
...
is
...
publishing
...
the
...
vulnerability
...
document
...
to
...
whatever
...
channels
...
have
...
been
...
identified
...
during
...
previous
...
phases.
...
Some
...
vendors
...
have
...
a
...
specific
...
website
...
that
...
lists
...
all
...
their
...
security
...
advisories
...
to
...
date.
...
Others
...
might
...
...
the
...
disclosure
...
to
...
a
...
user
...
mailing
...
list
...
or
...
a
...
security
...
mailing
...
list
...
such
...
as
...
Full
...
Disclosure
...
[2]
...
or
...
BugTraq
...
[1].
...
Reporters
...
themselves
...
may
...
also
...
chose
...
to
...
disclose
...
by
...
posting
...
the
...
advisory
...
to
...
a
...
mailing
...
list
...
or
...
including
...
it
...
in
...
a
...
personal
...
or
...
company
...
blog.
...
A
...
common
...
goal
...
for
...
reporters
...
in
...
the
...
CVD
...
process
...
is
...
to
...
synchronize
...
their
...
publication
...
with
...
the
...
vendor's
...
response.
...
As
...
a
...
result,
...
near-simultaneous
...
publication
...
occurs
...
quite
...
often.
...
It
...
is
...
generally
...
courteous
...
for
...
the
...
vendor
...
and
...
reporter
...
to
...
contact
...
each
...
other
...
after
...
disclosure
...
to
...
inform
...
one
...
another
...
that
...
the
...
disclosure
...
went
...
through
...
as
...
planned
...
and
...
provide
...
URLs
...
to
...
the
...
published
...
documents.
Vulnerability Identifiers Improve Response
...
Many
...
vulnerability
...
reports
...
can
...
be
...
similar,
...
and
...
sometimes
...
a
...
vendor
...
or
...
coordinator
...
might
...
receive
...
multiple
...
reports
...
of
...
similar
...
vulnerabilities
...
at
...
the
...
same
...
time.
...
Sometimes
...
this
...
is
...
due
...
to
...
independent
...
discovery,
...
which
...
we
...
discuss
...
in
...
...
6.5.
...
Other
...
times
...
it
...
reflects
...
a
...
report
...
traversing
...
multiple
...
paths
...
to
...
arrive
...
at
...
its
...
destination
...
within
...
the
...
CVD
...
process.
...
This
...
is
...
fairly
...
common
...
in
...
cases
...
where
...
a
...
vulnerability
...
affects
...
products
...
from
...
multiple
...
vendors.
...
Using
...
a
...
common
...
identifier
...
improves
...
coordination
...
as
...
it
...
ensures
...
that
...
all
...
coordinating
...
parties
...
can
...
keep
...
track
...
of
...
the
...
issue.
...
The
...
most
...
common
...
identifier
...
in
...
use
...
today
...
is
...
the
...
CVE
...
ID
...
[3],
...
which
...
is
...
meant
...
as
...
a
...
globally
...
unique
...
identifier
...
for
...
a
...
public
...
vulnerability
...
report.
...
CVE
...
IDs
...
can
...
be
...
obtained
...
from
...
the
...
CVE
...
Project
...
at
...
MITRE
...
or
...
one
...
of
...
several
...
CVE
...
Numbering
...
Authorities
...
(CNAs)
...
established
...
by
...
MITRE—typically
...
the
...
vendors
...
of
...
common
...
software
...
products
...
themselves
...
[4].
...
Both
...
reporters
...
and
...
vendors
...
can
...
request
...
a
...
CVE
...
ID,
...
but
...
reporters
...
should
...
first
...
check
...
if
...
the
...
vendor
...
they
...
are
...
coordinating
...
with
...
is
...
already
...
a
...
CNA.
...
This
...
identifier
...
should
...
be
...
included
...
in
...
any
...
pre-disclosure
...
shared
...
drafts,
...
so
...
that
...
all
...
parties
...
are
...
aware
...
of
...
the
...
common
...
identifier.
Where to Publish
Publicly disclosing the existence of a vulnerability and the availability of its fix is usually considered to be the primary goal of the CVD process. Vendors will often provide vulnerability information:
- on the vendor's public website. Many vendors offer a security-focused section within the support section of their online offerings.
- to a public mailing list or a vendor-specific list
Vendors of bespoke software or products with highly focused customer bases are sometimes reasonably confident that they can reach their affected users directly. These vendors often publish vulnerability and fix information:
- on a customer-only site
- via a customer support mailing list
- by individually notifying customers, for example through the technical sales channel
...
Overview
Content Tools