ISO/IEC 29147:2014

INTERNATIONAL ISO/IEC
STANDARD 29147
First edition
2014-02-15
Information technology — Security
techniques — Vulnerability disclosure
Technologies de l’information — Techniques de sécurité —
Divulgation de vulnérabilité
Reference number
©
ISO/IEC 2014
© ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Concepts . 3
5.1 General . 3
5.2 Interface between ISO/IEC 29147: Vulnerability disclosure and ISO/IEC 30111:
Vulnerability handling processes . 3
5.3 Products and online services . 5
5.4 Stakeholders . 6
5.5 Vulnerability disclosure process summary . 7
5.6 Information exchange during vulnerability disclosure. 8
5.7 Confidentiality of exchanged information . 9
5.8 Vulnerability advisories . 9
5.9 Vulnerability exploitation . 9
6 Vulnerability disclosure policy considerations .10
6.1 General .10
6.2 Minimum policy aspects .10
6.3 Optional policy aspects .11
7 Receipt of vulnerability information .12
7.1 General .12
7.2 Potential vulnerability report and its secure receiving model .12
7.3 Acknowledgement of receipt from finder or a coordinator .12
7.4 Tracking incoming reports .12
7.5 On-going communication with finder .12
7.6 Detailed information .12
7.7 Support from coordinators . .13
8 Possible vulnerability reporting among vendors .13
8.1 General .13
8.2 Typical cases calling for vulnerability reporting among vendors .13
8.3 Reporting of vulnerability information to other vendors .13
9 Dissemination of advisory .14
9.1 General .14
9.2 Purpose of advisory .14
9.3 Consideration in advisory disclosure .14
9.4 Timing of advisory release .14
9.5 Contents of advisory.15
9.6 Advisory communication .16
9.7 Advisory formats .17
9.8 Advisory authenticity .17
Annex A (informative) Details for handling vulnerability/advisory information .18
Annex B (informative) Sample policies, advisories, and global coordinators .26
Bibliography .34
© ISO/IEC 2014 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 29147 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
iv © ISO/IEC 2014 – All rights reserved

Introduction
A vulnerability is a weakness of software, hardware, or online service that can be exploited. An
exploitation of vulnerabilities results in a disruption of the confidentiality, integrity, or availability of
the ICT system or related information assets, which may cause a breach of data privacy, interruption of
operation of mission critical systems, and so on.
Vulnerabilities can be caused by both software or hardware design and programming flaws.
Poor administrative processes and a lack of user awareness and education can also be a source of
vulnerabilities, as can unforeseen changes in operating environments. Regardless of the cause, an
exploitation of such vulnerabilities may result in real threats to mission-critical information systems.
Individuals and organizations, including businesses and governments, rely heavily on hardware
and software components used in operating systems, applications, networks, and critical national
infrastructure. Vulnerabilities in these components increase risk to the information residing on them,
thus increasing risks to users and owners of the information. In addition, the lack of awareness about
these vulnerabilities also increases risk.
Inappropriate disclosure of a vulnerability could not only delay the deployment of the vulnerability
resolution but also give attackers hints to exploit it. That is why vulnerability disclosure should be
carried out appropriately.
Vulnerability disclosure is a process through which vendors and vulnerability finders may work
cooperatively in finding solutions that reduce the risks associated with a vulnerability. It encompasses
actions such as reporting, coordinating, and publishing information about a vulnerability and its
resolution.
The goals of vulnerability disclosure include the following:
a) ensuring that identified vulnerabilities are addressed;
b) minimizing the risk from vulnerabilities;
c) providing users with sufficient information to evaluate risks from vulnerabilities to their systems;
d) setting expectations to promote positive communication and coordination among involved parties.
This International Standard provides guidelines for vendors to be included in their business processes
when receiving information about potential vulnerabilities and distributing vulnerability resolution
information.
© ISO/IEC 2014 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 29147:2014(E)
Information technology — Security techniques —
Vulnerability disclosure
1 Scope
This International Standard gives guidelines for the disclosure of potential vulnerabilities in products
and online services. This International Standard details the methods a vendor should use to address
issues related to vulnerability disclosure. This International Standard
a) provides guidelines for vendors on how to receive information about potential vulnerabilities in
their products or online services,
b) provides guidelines for vendors on how to disseminate resolution information about vulnerabilities
in their products or online services,
c) provides the information items that should be produced through the implementation of a vendor’s
vulnerability disclosure process, and
d) provides examples of content that should be included in the information items.
This International Standard is applicable to vendors who respond to external reports of vulnerabilities
in their products or online services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27000:2012, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
ISO/IEC 30111, Information technology — Security techniques — Vulnerability handling processes
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO/IEC 27000 and the following apply.
3.1
advisory
announcement or bulletin that serves to inform, advise, and warn about a vulnerability of a product
Note 1 to entry: An advisory may include advice on how to deal with the vulnerability. An advisory typically
contains a description of the vulnerability at a specific point in time. An advisory can include a list of vulnerable
products or services, potential impact, resolution and mitigation information, and references. Such items included
in the advisory are relevant at the time the advisory is published and may evolve over time. An advisory may be
published by a vendor, finder, or coordinator and may be revised if more information becomes available.
3.2
coordinator
optional participant that can assist vendors and finders in handling and disclosing vulnerability
information
Note 1 to entry: A coordinator can act as a trusted liaison between involved parties (vendors and finders), enabling
positive communication between them.
© ISO/IEC 2014 – All rights reserved 1

3.3
finder
individual or organization that identifies a potential vulnerability in a product or online service
Note 1 to entry: Finders can be researchers, security companies, users, governments, or coordinators.
3.4
online services
service which is implemented by hardware, software, or a combination of them and provided over a
communication line or network
Note 1 to entry: The vendor of an online service may also be referred to as a service provider. Online services are
similar to products in that both are primarily software systems. Two main distinctions are that a service often
appears to users as a single instance of software and that users do not install, manage, or deploy the software, but
they only use the service.
3.5
product
system implemented or developed for sale or to be offered for free
3.6
remediation
patch, fix, upgrade, configuration, or documentation change to either remove or mitigate a vulnerability
Note 1 to entry: A remediation typically takes the form of a configuration change, binary file replacement,
hardware change, source code patch, etc. Remediations are usually provided by vendors. Vendors use different
terms including patch, fix, hotfix, and upgrade.
Note 2 to entry: Actions that reduce the impact of a possible attack or mask the vulnerability (which are, in most
cases, a temporary action) are often called countermeasures or workarounds.
3.7
service
means of delivering value to users by facilitating results users want to achieve without the ownership of
specific physical or logical resources and the risks related to ownership
3.8
vendor
individual or organization that developed the product or service or is responsible for maintaining it
3.9
vulnerability
weakness of software, hardware, or online service that can be exploited
[SOURCE: ISO/IEC 27000:2009, 2.46 — modified.]
Note 1 to entry: Weaknesses in a system can be caused by software and hardware design flaws, poor administrative
processes, lack of awareness and education, and advancements in the state of the art or improvements to current
practices.
4 Abbreviated terms
CCE Common Configuration Enumeration
CPE Common Platform Enumeration
CSIRT Computer Security Incident Response Team
CVE Common Vulnerabilities and Exposures
CVSS Common Vulnerability Scoring System
2 © ISO/IEC 2014 – All rights reserved

ID identifier
IT information technology
PC personal computer
PDF portable document format
PGP Pretty Good Privacy
PoC proof of concept
PSIRT product security incident response team
SRM secure receiving model
SW software
URL uniform resource locator
5 Concepts
5.1 General
The purpose of this clause is to provide background information and context to help readers better
understand vulnerability handling and vulnerability disclosure.
5.2 Interface between ISO/IEC 29147: Vulnerability disclosure and ISO/IEC 30111: Vul-
nerability handling processes
ISO/IEC 29147: Vulnerability disclosure and ISO/IEC 30111: Vulnerability handling processes are related
standards, as Figure 1 shows.
ISO/IEC 29147 provides guidelines for vendors to include in their normal business processes when
receiving information about potential vulnerabilities from external individuals or organizations and
when distributing vulnerability resolution information to affected users. This targets individuals,
persons, users, and organizations who require methods to receive vulnerability reports and, when
required, to disseminate advisories.
ISO/IEC 30111 gives guidelines on how to process and resolve potential vulnerability information
reported by individuals or organizations that find a potential vulnerability in a product or online service.
This is targeted at organizations who want to strengthen their internal processing to deal with received
vulnerability reports.
While ISO/IEC 29147 deals with the interface between vendors and those who find and report potential
vulnerabilities, ISO/IEC 30111 deals with the investigation, triage, and resolution of vulnerabilities,
regardless if the source of the potential vulnerability was external to the vendor or from within the
vendor’s own security, development, or testing teams.
© ISO/IEC 2014 – All rights reserved 3

Figure 1 — Mapping of ISO/IEC 29147 and ISO/IEC 30111
4 © ISO/IEC 2014 – All rights reserved

5.3 Products and online services
5.3.1 Products
Products are systems provided by vendors to users either for sale or for free. There are many different
types of products including but not limited to custom software built under contract for specific user’s
license use, libraries intended to be included in other products, commercial off-the-shelf (COTS) products
for mass markets, community-developed projects, and recreational or hobbyist offerings.
For the purposes of this International Standard, the distinction between hardware and software
products is seldom relevant. There are very few cases of vulnerabilities in pure hardware systems. In
most cases, so-called hardware vulnerabilities actually occur in low-level software or firmware.
Depending on sales, distribution, and support models, vendors may or may not have accurate lists of
users. This can be relevant when considering notifying affected users of a vulnerability.
5.3.2 Vulnerability
A vulnerability is generally a set of conditions that allows the violation of an explicit or implicit security
policy of the user. Typically, the violation of the user’s security policy results in a negative impact or loss
to the user. One common way to categorize loss is to consider the impact to the confidentiality, integrity,
and availability of an asset. For example, a vulnerability that allowed an attacker to install malicious
software on a user’s system might severely impact confidentiality and integrity since the attacker could
use the malicious software to read or change sensitive information. A vulnerability in a network product
that caused the product to experience a system error would impact availability. The actual impact of a
vulnerability depends on how the vulnerable product is used and other subjective factors.
Vulnerabilities are often caused by implementation defects in software. A vulnerability can be associated
with the security policy if one exists. One common type of vulnerability includes buffer overflows and
related low-level memory management errors that allow specially crafted input to control execution
of the vulnerable software program. SQL injection and cross-site scripting vulnerabilities are common
types of vulnerabilities found in web applications. Many other sets of conditions can cause or contribute
to vulnerabilities, including design decisions, default configuration settings, weak authentication or
access control, lack of awareness or education, or even unexpected interactions between systems or
changes in operating environments.
More information about types of vulnerabilities can be found in the Common Weakness Enumeration
(CWE) and the Open Web Application Security Project (OWASP). Both of these organizations focus on
training developers and engineers on current security threats including how to discover and rate them
and how to programmatically make code and applications better. Links to both of these sites are located
in B.4.
Many stakeholders (predominantly vendors and users) seek to identify and resolve vulnerabilities,
either removing them entirely (usually by patching or updating software to remove defects) or by
mitigating or working around vulnerabilities to reduce the likelihood and/or impact of successful
attack. Vulnerability disclosure provides vendors and users with information to resolve and mitigate
vulnerabilities and to make better risk decisions.
Attackers also seek to identify vulnerabilities, but typically do not attempt to disclose or resolve
vulnerabilities. Attackers seek to exploit vulnerabilities for some gain, almost always causing loss to
users.
5.3.3 Product interdependency
Many products are complex systems that include other products in some way. Products can use source
code from other products, software libraries, or other types of interfaces. Some products are substantially
similar but sold under different brands by different vendors. Different products that support the same
network protocol or file format may be affected by a vulnerability in the protocol or format. A user or
© ISO/IEC 2014 – All rights reserved 5

vendor may not be certain which products are affected by the vulnerability. These interdependencies
are important since products that use or interact with a vulnerable product may also be vulnerable.
5.4 Stakeholders
This subclause enumerates major stakeholders in the vulnerability disclosure process.
5.4.1 User
Users may directly operate software or hardware products or make use of an online service. Users may
be referred to as consumers, customers, or end users. Due to the interdependencies of modern software
products, users may not know precisely which components or products they are actually using.
Users need information about vulnerabilities, particularly remediation, in order to make effective risk
decisions and to use software products and online services more securely. Providing vulnerability
information to users is discussed in Clause 9.
5.4.2 Vendor
A vendor develops a product or online service or is responsible for maintaining it. A vendor may be an
individual or organization such as a commercial business or an open source project. There are a number
of different terms used to describe individuals or organizations who deliver software products for free,
including developer, maintainer, or distributor. Similarly, an individual or organization that delivers
software products within a supply chain may be called a supplier. For the purposes of this International
Standard, the term “vendor” shall be used to mean all of them.
Vendors are responsible for the quality of their products and online services. Vendors use vulnerability
disclosure to learn about vulnerabilities, to develop resolutions and mitigations, and to distribute
information to users.
There are many types of vendors with various models for developing, selling, supporting, and
distributing products. Some vendors integrate products into a system or service, and these vendors may
act as customers or users of the component products. These intermediate vendors may be dependent on
component vendors for vulnerability resolution and mitigation information.
5.4.3 Intermediate Vendor
An intermediate vendor gets a subsystem from a vendor and uses it to supply a system or service (or
a combination of both) to a user (or another intermediate vendor). Typical examples are the following:
a) system houses that use a PC and an operating system to add their own healthcare administration
software and sell the combined system to a medical doctor (maybe together with a maintenance
contract);
b) telecommunication providers that supply a mobile phone together with a service contract.
These intermediate vendors may learn about vulnerabilities through error reports from their customers
and additional early investigations (e.g. as part of quality controls for incoming goods). They shall report
vulnerabilities to their vendors. The difficult issue for intermediate vendors is that they may not be in a
position to simply wait for their vendor to solve the problem and remove the vulnerability.
They have a legal responsibility to inform their customers, as the customers may need to stop using the
device or some of its functionality or to work around the vulnerabilities in order to mitigate risk. This
holds especially when the vendor takes a long time to remove the vulnerability or is not able to do so at
all. If an intermediate vendor informs its customer, this may well mean that vulnerability is disclosed
before the vendor is able to deal with this.
Intermediate vendors may also be technically capable of producing and distributing workarounds to
at least protect the use of their product or service or even a specific configuration of the underlying
system (e.g. a more restrictive configuration of the operating system). Their intermediary role puts
6 © ISO/IEC 2014 – All rights reserved

these vendors in the position of having to deal with trade-offs (e.g. informing their customers about
vulnerabilities quickly vs. communicating solutions in addition to problems).
5.4.4 Finder
A finder is an individual or organization who identifies a potential vulnerability in a product or an online
service. A finder is often a security or vulnerability researcher. A finder may also be a user or vendor. For
the purposes of this International Standard, it is expected that a finder will attempt to inform a vendor
or coordinator about a vulnerability. In practice, a finder may choose not to attempt to inform a vendor
or coordinator or the attempt may fail. Receiving vulnerability information from finders is discussed in
Clause 7.
5.4.5 Coordinator
Coordinators may work with other coordinators to obtain help with domain expertise, language, time
zone, and cultural barriers and to share effort. Some Computer Security Incident Response Teams
(CSIRTs) provide vulnerability coordination services on an operational basis, and other CSIRTs will help
coordinate individual cases. Some vendors also provide coordination services.
Common services provided by a coordinator include
— helping finders identify and contact vendors,
— coordinating vulnerabilities that affect multiple vendors,
— performing technical analysis and validation of vulnerability reports, and
— publishing advisories.
While coordinators often have interests in protecting their constituencies, coordinators should attempt
to be technically objective and minimize risk to all stakeholders.
5.5 Vulnerability disclosure process summary
This subclause summarizes the vulnerability disclosure process contained in ISO/IEC 30111. Figure 2
outlines the vendor’s vulnerability disclosure process which consists of the five high-level steps.
Figure 2 — Summary vulnerability disclosure process
© ISO/IEC 2014 – All rights reserved 7

5.5.1 Receipt of vulnerability report phase
A finder identifies potential vulnerabilities in products or online services and reports to the vendor. The
vendor acknowledges receipt of the report.
5.5.2 Verification phase
The vendor investigates the report. Investigation often involves attempting to reproduce the environment
and behaviour reported by the finder. This may be a preliminary investigation, focused primarily on
the need for further effort by the vendor. Investigation may also include correlating similar or related
reports, assessing severity, and determining other affected products. The investigation determines
whether the report constitutes a vulnerability or not. The vendor may communicate with the finder
during the investigation and notifies the finder of the results at the end of the investigation.
5.5.3 Resolution development phase
The vendor develops a resolution for vulnerabilities reported by a finder. Resolution development may
involve more detailed investigation of the root cause of the vulnerabilities and determination of other
products affected by the same or similar vulnerabilities. The vendor typically develops remediation and
mitigation techniques and performs positive tests to determine that the remediation works correctly
and negative (regression) tests to provide assurance that the remediation does not disrupt existing
functionality.
5.5.4 Release phase
The vendor deploys the remediation. In an online service, the vendor deploys the remediation and
documents the event. For a product, the vendor provides the remediation and mitigation information
to users, typically in the form of a vulnerability advisory and software patches or updates, and users
deploy the remediation. A vendor may release an advisory before a remediation is available, particularly
in cases of active exploitation or public discussion. The vendor should attempt to ensure the remediation
does not introduce new vulnerabilities, overall product quality issues, or have compatibility problems
with other products or services if possible.
5.5.5 Post-release phase
A vendor collects feedback from users and updates remediation and mitigation information as necessary.
For example, a remediation may be found to be incomplete or to cause regression issues or side effects.
5.6 Information exchange during vulnerability disclosure
Figure 3 illustrates information exchange during the vulnerability disclosure process. There are two
main exchanges: potential vulnerability reports from finders to vendors and advisories from vendors
to users. A potential vulnerability report is sent from a finder to a vendor either directly or through
coordinators. A vendor may act as a finder and report a vulnerability to another vendor. An advisory
is released by a vendor either privately to its users or to the public. This International Standard
focuses on these two exchanges from the perspective of the vendor receiving vulnerability reports and
disseminating remediation information.
8 © ISO/IEC 2014 – All rights reserved

Figure 3 — Vulnerability information exchange
5.7 Confidentiality of exchanged information
Since vulnerability information may be used to attack vulnerable products and online services, sensitive
vulnerability information should be communicated confidentially. Vendors may wish to provide
secure confidential methods for finders to report vulnerability information. Message integrity is also
important, particularly in verifying that remediation information is authentic. Common cryptographic
protocols such as Secure Sockets Layer (SSL), Secure Multipurpose Internet Mail Extensions (S/MIME),
and Pretty Good Privacy (PGP) can provide confidentiality and integrity. If there are other security
requirements, ISO/IEC 27010 may be of relevance. An example would be if a coordinator wishes to offer
a finder anonymity service.
5.8 Vulnerability advisories
Vulnerability information is generally published in an advisory. The advisory describes the vulnerability,
usually focusing on remediation and mitigation, but also includes information about affected systems,
threats, impact, and related references. Users reading an advisory need sufficient information to make
informed risk decisions about how to remediate or mitigate the vulnerability.
Users should be able to cryptographically verify the authenticity and integrity of an advisory and
remediation (particularly patches and updates).
5.9 Vulnerability exploitation
In general, attackers seek to exploit vulnerabilities for some gain, almost always causing loss to users.
Various factors such as target population, exposure of targets, value of targets to the attacker, and cost
of exploit development can influence whether or not a vulnerability will be exploited by attackers. Any
attempt, however, to predict whether or not a vulnerability will or has already been used in attacks is
fraught with uncertainty. The most conservative assumption is that a vulnerability can and will (and
may have already been) used in attacks.
© ISO/IEC 2014 – All rights reserved 9

6 Vulnerability disclosure policy considerations
6.1 General
This clause discusses considerations to be taken into account when creating a vulnerability disclosure
policy. Each vendor has different requirements and resources available for dealing with security
vulnerability information.
Vendors should define their responsibilities in the vulnerability disclosure policy. Vendors should
publicize their vulnerability disclosure policy or point to an existing public vulnerability disclosure
policy. Several examples are listed in B.1.
The disclosure policy should state the intentions of the vendor, its responsibilities, as well what the
vendor expects from other stakeholders. The vulnerability disclosure policy should be simple and clear
to enable easy reporting of product vulnerabilities to the vendor. Vendors should consider intuitive
placement of information related to product security. One such location may be a security web page (e.g.
www.example.com/security).
6.2 Minimum policy aspects
A vendor should create an overall vulnerability disclosure policy, but they may choose to publicize only
select sections if the internal policy contains sensitive information. A vulnerability disclosure policy
should, at least, include information about the following.
a) How the vendor would like to be contacted
Vendors who adopt a policy of vulnerability disclosure will typically offer a security website or
page. This website/page provides information on the vendor’s accepted method(s) for receiving
vulnerability information from a finder.
Contact information might include one or more of the following:
1) E-mail address;
Examples of e-mail aliases that could be used include the following:
— security-alert@example.com;
— security@example.com;
— secure@example.com;
— psirt@example.com;
— csirt@example.com
2) Phone number;
3) Web form.
Vendors can offer a web form that the finder has to complete. This has the advantage that the
vendor can distinguish between optional and mandatory information and automate the process
of entering data in a vulnerability database.
b) Secure communication options
Due to the risk aspect of clear text messages, vendors should provide a secure communications
channel. This can leverage technologies such as S/MIME or PGP to ensure information exchanges are
protected. Likewise, vendors can offer HTTPS for web portals for vulnerability report submissions.
Vendors should configure these capabilities prior to communication with finders.
c) Setting communication expectations
10 © ISO/IEC 2014 – All rights reserved

Vendors should explain/set expectations for communication, including initial acknowledgement of
receipt of report and status updates. Vendors should provide updates to the finder using the agreed
method of communication.
d) Information that would be useful when submitting a possible vulnerability report
It is important that vendors maintain open and cooperative dialogue with finders so that information
about vulnerabilities can be shared and risk for users can be reduced as efficiently as possible. Once
a finder has initiated contact regarding a potential vulnerability, vendors will have to determine
if the finder has provided enough information to confirm or refute the issue. This will be different
in each situation. A.2 lists examples of information that would be helpful to vendors. If the vendor
determines that the finder has not provided enough information, the vendor may contact the finder
to request for additional details. Intermediate vendors may wish to invite information on which
terminal vendor or other intermediate vendor may be the source of the vulnerability and whether
the finder also reported the vulnerability there.
e) Out-of-scope services
In most cases, the team dealing with vulnerability reports will not be able to deal with security
incidents and other security related questions. Vendors should specify contact points for these
types of requests.
A vendor may wish to provide suggestions for submitting additional information that might be
helpful to understanding the vulnerability and possible remedies. The vendor might consider
providing a form for this purpose.
In cases when a vulnerability affects multiple vendors, it is useful for vendors to know if the finder
has also reported the vulnerability to the other affected vendors.
f) How submitted reports are tracked
The vendor should define a means to track received information about possible vulnerability
information and communicate that method with finders.
6.3 Optional policy aspects
A vulnerability disclosure policy may contain multiple optional elements.
a) Credit to finder
A vendor may acknowledge the contributions of the finder(s) who helped in the discovery or worked
towards resolution of the discovered vulnerability. Before doing so, the vendor should verify that
this acknowledgement is welcomed by the finder.
b) Synchronized public disclosure
As soon as remediations are available, the vendor and finder may come to a common and synchronized
public disclosure.
c) Distribution
The vendor will offer a means for publishing security advisories which may include a website,
mailing list, etc., including information on how to subscribe and unsubscribe.
© ISO/IEC 2014 – All rights reserved 11

7 Receipt of vulnerability information
7.1 General
This clause presents a guideline for vendors when receiving information on potential vulnerabilities
from either a finder or a coordinator, which helps vendors
a) ensure that their team responsible for vulnerability handling can receive vulnerability reports as
quickly and securely as possible, and
b) establish and maintain a working relationship with a finder or a coordinator.
7.2 Potential vulnerability report and its secure receiving model
Potential vulnerability reports are sent to vendors or coordinators by finders in order to prompt initiation
of the vulnerability handling process. They include a description of what product or online service has
a potential vulnerability and how the potential vulnerability is triggered. Reports may include proof-of-
concept (PoC) code that demonstrates the exploitation of the vulnerability. Since a vulnerability report
may include sensitive information such as PoC code, a vendor should provide a means to receive that
information securely.
7.3 Acknowledgement of receipt from finder or a coordinator
The vendor should respond to a vulnerability report within the time period specified in the vendor’s
vulnerability disclosure policy. It is recommended that an acknowledgement of receipt of a vulnerability
report be provided to a finder within seven calendar days.
7.4 Tracking incoming reports
A vendor should have a tracking system that is used to record and track all reports on potential
vulnerabilities. It shall be possible to unambiguously track each report. This assignment can be done
by the vendor, an intermediate vendor, a finder, a coordinator, or any other party involved in the
vulnerability disclosure process.
For tracking purposes, the vendor should assign a unique internal identifier to the potential vulnerability
report. It is preferred to use this unique identifier in all communication with the stakeholders involved
in the vulnerability assessment. Finders can also assign an internal identifier which can be included in
the vendor’s tracking process.
7.5 On-going communication with finder
Vendors should evaluate the reported issue and make a determination whether it represents a
vulnerability or not. The vendor should inform the finder and coordinator, if involved, on the results.
An intermediate vendor should check whether it can decide on the potential vulnerability on its own or
needs to involve the vendor it got the related subsystem from. If another vendor needs to be involved in
the decision and if this delays the response, the intermediate vendor should inform the finder and/or the
coordinator about this fact and about the further processing.
7.6 Detailed information
During the investigations, the vendor can lack sufficient information to come to a complete assessment
of the vulnerability. In this case, the vendor should request that the finder provide additional input using
the agreed upon communication channels.
Follow-up communication between the vendor and the finder will be conducted using agreed methods.
One possibility
...