Information technology — Security techniques — Vulnerability disclosure

This document provides requirements and recommendations to vendors on the disclosure of vulnerabilities in products and services. Vulnerability disclosure enables users to perform technical vulnerability management as specified in ISO/IEC 27002:2013, 12.6.1[1]. Vulnerability disclosure helps users protect their systems and data, prioritize defensive investments, and better assess risk. The goal of vulnerability disclosure is to reduce the risk associated with exploiting vulnerabilities. Coordinated vulnerability disclosure is especially important when multiple vendors are affected. This document provides: — guidelines on receiving reports about potential vulnerabilities; — guidelines on disclosing vulnerability remediation information; — terms and definitions that are specific to vulnerability disclosure; — an overview of vulnerability disclosure concepts; — techniques and policy considerations for vulnerability disclosure; — examples of techniques, policies (Annex A), and communications (Annex B). Other related activities that take place between receiving and disclosing vulnerability reports are described in ISO/IEC 30111. This document is applicable to vendors who choose to practice vulnerability disclosure to reduce risk to users of vendors' products and services.

Technologies de l'information — Techniques de sécurité — Divulgation de vulnérabilité

Le présent document fournit des exigences et des recommandations à l'attention de fournisseurs concernant la divulgation de vulnérabilités dans des produits et services. La divulgation de vulnérabilité permet aux utilisateurs d'effectuer une gestion des vulnérabilités techniques telle que spécifiée dans l'ISO/IEC 27002:2013, 12.6.1[1]. La divulgation de vulnérabilité aide les utilisateurs à protéger leurs systèmes et données, à prioriser les investissements défensifs et à mieux apprécier le risque. L'objectif d'une divulgation de vulnérabilité est de réduire le risque associé à l'exploitation de vulnérabilités. Une divulgation de vulnérabilité coordonnée est particulièrement importante lorsque plusieurs fournisseurs sont affectés. Le présent document fournit: — des lignes directrices sur la réception de signalements concernant des vulnérabilités potentielles; — des lignes directrices sur la divulgation d'informations concernant la remédiation de vulnérabilités; — des termes et définitions spécifiques à la divulgation de vulnérabilités; — une vue d'ensemble des concepts associés à la divulgation de vulnérabilité; — des considérations relatives aux techniques et politiques de divulgation de vulnérabilité; — des exemples de techniques, de politiques (Annexe A) et de communications (Annexe B). D'autres activités associées intervenant entre la réception et la divulgation de signalements de vulnérabilités sont décrites dans l'ISO/IEC 30111. Le présent document s'applique aux fournisseurs qui choisissent de pratiquer la divulgation de vulnérabilité pour réduire le risque pour les utilisateurs de produits et services de fournisseurs.

General Information

Status
Published
Publication Date
22-Oct-2018
Current Stage
9092 - International Standard to be revised
Start Date
26-Sep-2025
Completion Date
30-Oct-2025
Ref Project

Relations

Standard
ISO/IEC 29147:2018 - Information technology — Security techniques — Vulnerability disclosure Released:10/23/2018
English language
32 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 29147:2018 - Technologies de l'information — Techniques de sécurité — Divulgation de vulnérabilité Released:6/3/2020
French language
34 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO/IEC
STANDARD 29147
Second edition
2018-10
Information technology — Security
techniques — Vulnerability disclosure
Technologies de l'information — Techniques de sécurité —
Divulgation de vulnérabilité
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Concepts . 3
5.1 General . 3
5.2 Structure of this document . 3
5.3 Relationships to other International Standards . 4
5.3.1 ISO/IEC 30111 . 4
5.3.2 ISO/IEC 27002 . 5
5.3.3 ISO/IEC 27034 series . . 6
5.3.4 ISO/IEC 27036-3 . 6
5.3.5 ISO/IEC 27017 . 6
5.3.6 ISO/IEC 27035 series . . 6
5.3.7 Security evaluation, testing and specification . 6
5.4 Systems, components, and services . 6
5.4.1 Systems . 6
5.4.2 Components . 6
5.4.3 Products . 6
5.4.4 Services . 7
5.4.5 Vulnerability . 7
5.4.6 Product interdependency. 7
5.5 Stakeholder roles . 8
5.5.1 General. 8
5.5.2 User . 8
5.5.3 Vendor . 8
5.5.4 Reporter . 8
5.5.5 Coordinator . 9
5.6 Vulnerability handling process summary . 9
5.6.1 General. 9
5.6.2 Preparation .10
5.6.3 Receipt .10
5.6.4 Verification .11
5.6.5 Remediation development .11
5.6.6 Release .11
5.6.7 Post-release .12
5.6.8 Embargo period .12
5.7 Information exchange during vulnerability disclosure.12
5.8 Confidentiality of exchanged information .13
5.8.1 General.13
5.8.2 Secure communications .13
5.9 Vulnerability advisories .13
5.10 Vulnerability exploitation .14
5.11 Vulnerabilities and risk .14
6 Receiving vulnerability reports .14
6.1 General .14
6.2 Vulnerability reports .14
6.2.1 General.14
6.2.2 Capability to receive reports .14
6.2.3 Monitoring .15
© ISO/IEC 2018 – All rights reserved iii

6.2.4 Report tracking .15
6.2.5 Report acknowledgement .15
6.3 Initial assessment .16
6.4 Further investigation .16
6.5 On-going communication .16
6.6 Coordinator involvement .16
6.7 Operational security .17
7 Publishing vulnerability advisories .17
7.1 General .17
7.2 Advisory .17
7.3 Advisory publication timing .17
7.4 Advisory elements .18
7.4.1 General.18
7.4.2 Identifiers .18
7.4.3 Date and time .18
7.4.4 Title .19
7.4.5 Overview .19
7.4.6 Affected products .19
7.4.7 Intended audience .19
7.4.8 Localization .19
7.4.9 Description . . .19
7.4.10 Impact .19
7.4.11 Severity .20
7.4.12 Remediation .20
7.4.13 References .20
7.4.14 Credit . .20
7.4.15 Contact information .20
7.4.16 Revision history .20
7.4.17 Terms of use .20
7.5 Advisory communication .20
7.6 Advisory format .21
7.7 Advisory authenticity .21
7.8 Remediations .21
7.8.1 General.21
7.8.2 Remediation authenticity .21
7.8.3 Remediation deployment .21
8 Coordination .21
8.1 General .21
8.2 Vendors playing multiple roles .22
8.2.1 General.22
8.2.2 Vulnerability reporting among vendors .22
8.2.3 Reporting vulnerability information to other vendors .22
9 Vulnerability disclosure policy .22
9.1 General .22
9.2 Required policy elements .23
9.2.1 General.23
9.2.2 Preferred contact mechanism .23
9.3 Recommended policy elements.23
9.3.1 General.23
9.3.2 Vulnerability report contents . .23
9.3.3 Secure communication options .24
9.3.4 Setting communication expectations .24
9.3.5 Scope .24
9.3.6 Publication .24
9.3.7 Recognition .24
9.4 Optional policy elements .24
9.4.1 General.24
iv © ISO/IEC 2018 – All rights reserved

9.4.2 Legal considerations .24
9.4.3 Disclosure timeline .24
Annex A (informative) Example vulnerability disclosure policies .25
Annex B (informative) Information to request in a report .26
Annex C (informative) Example advisories .27
Annex D (informative) Summary of normative elements .30
Bibliography .32
© ISO/IEC 2018 – All rights reserved v

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
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. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
This second edition cancels and replaces the first edition (ISO/IEC 29147:2014), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— a number of normative provisions have been added (summarized in Annex D);
— numerous organizational and editorial changes have been made for clarity.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
This document is intended to be used with ISO/IEC 30111.
vi © ISO/IEC 2018 – All rights reserved

Introduction
In the contexts of information technology and cybersecurity, a vulnerability is a behaviour or set of
conditions present in a system, product, component, or service that violates an implicit or explicit
security policy. A vulnerability can be thought of as a weakness or exposure that allows a security
impact or consequence. Attackers exploit vulnerabilities to compromise confidentiality, integrity,
availability, operation, or some other security property.
Vulnerabilities often result from failures of a program or system to securely handle untrusted or
unexpected input. Causes that lead to vulnerabilities include errors in coding or configuration,
oversights in design choices, and insecure protocol and format specifications.
Despite significant efforts to improve software security, modern software and systems are so complex
that it is impractical to produce them without vulnerabilities. Risk factors of vulnerabilities include:
— operating and relying on systems that have known vulnerabilities;
— not having sufficient information about vulnerabilities;
— not knowing that vulnerabilities exist.
This document describes vulnerability disclosure: techniques and policies for vendors to receive
vulnerability reports and publish remediation information. Vulnerability disclosure enables both the
remediation of vulnerabilities and better-informed risk decisions. Vulnerability disclosure is a critical
element of the support, maintenance, and operation of any product or service that is exposed to active
threats. This includes practically any product or service that uses open networks such as the Internet.
A vulnerability disclosure capability is an essential part of the development, acquisition, operation, and
support of all products and services. Operating without vulnerability disclosure capability puts users
at increased risk.
The term “vulnerability disclosure” is used to describe the overall activities associated with
receiving vulnerability reports and providing remediation information. Additional activities such as
investigating and prioritizing reports, developing, testing, and deploying remediations, and improving
secure development are called “vulnerability handling” and are described in ISO/IEC 30111. The term
“disclosure” is also used more narrowly to mean the act of informing a party about a vulnerability for
the first time (see 3.2).
Major goals of vulnerability disclosure include:
— reducing risk by remediating vulnerabilities and informing users;
— minimizing harm and cost associated with the disclosure;
— providing users with sufficient information to evaluate risk due to vulnerabilities;
— setting expectations to facilitate cooperative interaction and coordination among stakeholders.
The processes described in this document aim to minimize risk, cost, and harm to all stakeholders. Due
to the volume of reported vulnerabilities, lack of accurate and complete information, and other factors
involved, it is not possible to create a single, fixed process that applies to every disclosure event.
The normative elements in this document provide minimum requirements to create a functional
vulnerability disclosure capability. Vendors should adapt the additional informative guidance in this
document to fit their particular needs and those of users and other stakeholders.
© ISO/IEC 2018 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 29147:2018(E)
Information technology — Security techniques —
Vulnerability disclosure
1 Scope
This document provides requirements and recommendations to vendors on the disclosure of
vulnerabilities in products and services. Vulnerability disclosure enables users to perform technical
[1]
vulnerability management as specified in ISO/IEC 27002:2013, 12.6.1 . Vulnerability disclosure helps
users protect their systems and data, prioritize defensive investments, and better assess risk. The goal
of vulnerability disclosure is to reduce the risk associated with exploiting vulnerabilities. Coordinated
vulnerability disclosure is especially important when multiple vendors are affected. This document
provides:
— guidelines on receiving reports about potential vulnerabilities;
— guidelines on disclosing vulnerability remediation information;
— terms and definitions that are specific to vulnerability disclosure;
— an overview of vulnerability disclosure concepts;
— techniques and policy considerations for vulnerability disclosure;
— examples of techniques, policies (Annex A), and communications (Annex B).
Other related activities that take place between receiving and disclosing vulnerability reports are
described in ISO/IEC 30111.
This document is applicable to vendors who choose to practice vulnerability disclosure to reduce risk
to users of vendors’ products and services.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. 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, 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 given in ISO/IEC 27000 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
© ISO/IEC 2018 – All rights reserved 1

3.1
vulnerability
functional behaviour of a product or service that violates an implicit or explicit security policy
[1]
Note 1 to entry: ISO/IEC 27002:2013, 12.6.1 uses the term “technical vulnerability” to distinguish between the
more general risk-based concept of vulnerability and the term used in this document.
3.2
disclosure
act of initially providing vulnerability (3.1) information to a party that was not believed to be
previously aware
3.3
coordination
set of activities including identifying and engaging stakeholders, mediating, communicating, and other
planning in support of vulnerability (3.1) disclosure (3.2)
Note 1 to entry: The term “coordinated vulnerability disclosure” is used to denote a disclosure process that
includes coordination.
3.4
vendor
individual or organization that is responsible for remediating vulnerabilities
Note 1 to entry: A vendor can be the developer, maintainer, producer, manufacturer, supplier, installer, or provider
of a product or service.
3.5
reporter
individual or organization that notifies a vendor (3.4) or coordinator (3.6) of a potential vulnerability (3.1)
Note 1 to entry: There are no special requirements for acting as a reporter. Reporters can be individuals,
organizations, amateurs or hobbyists, professionals, end-users, security research organizations, vendors,
governments, or coordinators.
Note 2 to entry: The term “reporter” does not imply unique or original discovery or reporting.
Note 3 to entry: Reporters can be called researchers, whether or not the reporter explicitly performs security or
vulnerability research. Historically, this role is also referred to as “finder.”
3.6
coordinator
individual or organization that performs coordination (3.3)
3.7
remediation
change made to a product or service to remove or mitigate a vulnerability (3.1)
Note 1 to entry: A remediation typically takes the form of a binary file replacement, configuration change, or
source code patch and recompile. Different terms used for “remediation” include patch, fix, update, hotfix, and
upgrade. Mitigations are also called workarounds or countermeasures.
3.8
advisory
document or message that provides vulnerability (3.1) information intended to reduce risk
Note 1 to entry: An advisory is meant to inform users or other stakeholders about a vulnerability including, if
possible, how to identify and remediate vulnerable systems.
2 © ISO/IEC 2018 – All rights reserved

4 Abbreviated terms
COTS common off-the-shelf
CRM customer relationship management
CSIRT computer security incident response team
[9]
CVE common vulnerabilities and exposures
[12][13]
CVRF common vulnerability reporting format
[10]
CVSS common vulnerability scoring system
[11]
CWE common weakness enumeration
HTTP(S) hypertext transfer protocol (secure)
ICT information and communication technology
OpenPGP open pretty good privacy
OWASP open web application security project
PoC proof of concept
PSIRT product security incident response team
S/MIME secure multipurpose internet mail extensions
SQL structured query language
TLS transport layer security
5 Concepts
5.1 General
The purpose of this clause is to provide background information and context to help understand
vulnerability disclosure.
Vulnerability disclosure involves different stakeholders with different perspectives, incentives,
capabilities, and available information. Furthermore, communication and process synchronization
among multiple stakeholders can quickly become complicated. In practice, disclosure can deviate from
the activities described in this document due to a variety of unforeseen circumstances.
5.2 Structure of this document
This document is meant to be read in its entirety as input to the development or improvement of
vulnerability disclosure policies and processes. The remaining clauses of this document are organized
as follows:
— Clause 5: Concepts;
— Clause 6: Receiving vulnerability reports;
— Clause 7: Publishing vulnerability advisories;
— Clause 8: Coordination;
© ISO/IEC 2018 – All rights reserved 3

— Clause 9: Vulnerability disclosure policy.
The structure of this document is not meant to be followed in strict sequence as it appears above. For
example, a vendor should ideally develop policy (Clause 9) before starting to receive reports (Clause 6).
Annex D contains a summary of all of the normative elements in this document.
5.3 Relationships to other International Standards
5.3.1 ISO/IEC 30111
ISO/IEC 30111 shall be used in conjunction with this document. The relationship between the two
International Standards is illustrated in Figure 1.
This document provides guidelines for vendors to include in their normal business processes when
receiving reports about potential vulnerabilities from external individuals or organizations and when
distributing vulnerability remediation information to affected users.
ISO/IEC 30111 gives guidelines on how to investigate, process, and resolve potential vulnerability
reports.
While this document deals with the interface between vendors and reporters, ISO/IEC 30111 deals
with internal vendor processes including the triage, investigation, and remediation of vulnerabilities,
whether the source of the report is external to the vendor or from within the vendor’s own security,
development, or testing teams.
4 © ISO/IEC 2018 – All rights reserved

Figure 1 — Relationship between ISO/IEC 29147 and ISO/IEC 30111
5.3.2 ISO/IEC 27002
Vulnerability disclosure enables the management of technical vulnerabilities (ISO/IEC 27002:2013,
[1]
12.6.1 ).
© ISO/IEC 2018 – All rights reserved 5

5.3.3 ISO/IEC 27034 series
Application security seeks to reduce the creation of application vulnerabilities (see ISO/IEC 27034-
[4]
1:2011, 6.5.2 ). Vulnerability disclosure can demonstrate the need for changes to application security
practices. Vulnerability disclosure cannot demonstrate that application security is completely effective.
Vulnerability disclosure occurs in the utilization and maintenance phases of the application security
[5]
lifecycle reference model described in ISO/IEC TS 27034-5-1:2018, 6.3.13 and 6.3.14 .
5.3.4 ISO/IEC 27036-3
Vulnerability disclosure supports multiple aspects of ICT supply chain security described in ISO/
[7]
IEC 27036-3:2013, 5.4 a), 5.8 i), 6.1.1 a) 2) and 6.3.4 .
5.3.5 ISO/IEC 27017
Vulnerability disclosure is necessary to enable the management of technical vulnerabilities as specified
[3]
for cloud services in ISO/IEC 27017:2015, 12.6.1 .
5.3.6 ISO/IEC 27035 series
Some incident management plans, particularly those of vendors, include vulnerability disclosure
[6]
(see ISO/IEC 27035-1:2016, Introduction ). Such plans typically treat vulnerability disclosure as
a type of incident. Incident management can also include vulnerability management (see also ISO/
[1]
IEC 27002:2013, 12.6.1 ), which is only possible when vulnerabilities are disclosed.
5.3.7 Security evaluation, testing and specification
This document provides guidance for vulnerability reports received externally, and not through
organized internal assurance and evaluation efforts. Thus, the more formal testing, assurance, and
[15] [16]
evaluation standards ISO/IEC 15408 and ISO/IEC 18405 do not generally apply.
5.4 Systems, components, and services
5.4.1 Systems
A system is a set of connected components and services. In vulnerability disclosure, the causes of a
vulnerability can be unclear, or due to interactions between the parts of a system, or between systems.
Thus, it is sometimes necessary to talk about systems being affected by vulnerabilities.
5.4.2 Components
A component is a unit of software or hardware that can be both an entire system unto itself and used
as part of a larger system. A component can be an entire operating system, a chip, an application, a
package, a library, or even a single file or segment of source code.
For the purposes of this document, the distinction between hardware and software components is
seldom relevant. There are very few cases of vulnerabilities in pure hardware components. In most
cases, so-called “hardware” vulnerabilities actually occur in low-level software or firmware.
5.4.3 Products
A product is usually one or more components or a system. Products are provided by vendors to users
either for sale or for free, usually under licensing terms. There are many different types of products
including but not limited to, custom software built under contract for a specific user’s licenced 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.
6 © ISO/IEC 2018 – All rights reserved

5.4.4 Services
A service is a collection of features provided to users. Users can interact with services they do not own,
operate, or maintain.
For vulnerability disclosure, vulnerabilities in services maintained by the vendor can usually be
remediated by the vendor taking action. Users can have to take action as well in order to remediate the
vulnerability. For example, a vendor implements changes on their own infrastructure to remediate the
vulnerability, and users have to change their passwords after the vendor has implemented the changes.
5.4.5 Vulnerability
A vulnerability is generally a behaviour or set of conditions that allows the violation of an explicit or
implicit security policy. Typically, the violation of a 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 impacts confidentiality and integrity since the attacker can 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 contextual factors.
Vulnerabilities are often caused by implementation defects in software. A vulnerability can be associated
to 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 CWE and OWASP. Both of these
resources help developers and engineers to recognize and avoid creating security vulnerabilities.
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 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.4.6 Product interdependency
Many products are complex systems that include or are dependent upon other products or components
in some way. It is possible that a user or vendor is not initially be certain which products are affected
by the vulnerability. These interdependencies are important since products that use or interact with a
vulnerable product can also be vulnerable.
product dependencies can include:
— source code re-use from other products, software libraries, or other types of interfaces;
— hardware or software supply chain;
— rebranding by different vendors of the same core technology;
— use of the same protocols or formats.
Depending on sales, distribution, and support models, vendors can h
...


NORME ISO/IEC
INTERNATIONALE 29147
Deuxième édition
2018-10
Technologies de l'information —
Techniques de sécurité — Divulgation
de vulnérabilité
Information technology — Security techniques — Vulnerability
disclosure
Numéro de référence
©
ISO/IEC 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO/IEC 2018 – Tous droits réservés

Sommaire Page
Avant-propos .vi
Introduction .vii
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 3
5 Concepts . 3
5.1 Généralités . 3
5.2 Structure du présent document . 4
5.3 Relations aux autres Normes internationales . 4
5.3.1 ISO/IEC 30111 . 4
5.3.2 ISO/IEC 27002 . 5
5.3.3 Série ISO/IEC 27034 . 6
5.3.4 ISO/IEC 27036-3 . 6
5.3.5 ISO/IEC 27017 . 6
5.3.6 Série ISO/IEC 27035 . 6
5.3.7 Évaluation, test et spécification de sécurité . 6
5.4 Systèmes, composants et services . 6
5.4.1 Systèmes . . . 6
5.4.2 Composants . 6
5.4.3 Produits . 7
5.4.4 Services . 7
5.4.5 Vulnérabilité . 7
5.4.6 Interdépendance des produits . 8
5.5 Rôles des parties prenantes . 8
5.5.1 Généralités . 8
5.5.2 Utilisateur . 8
5.5.3 Fournisseur. 8
5.5.4 Déclarant . . 9
5.5.5 Coordinateur . 9
5.6 Résumé du processus de traitement des vulnérabilités .10
5.6.1 Généralités .10
5.6.2 Préparation .11
5.6.3 Réception .11
5.6.4 Vérification .11
5.6.5 Développement d'une remédiation .11
5.6.6 Publication .11
5.6.7 Post-publication .12
5.6.8 Période d'embargo .12
5.7 Échange d'informations au cours de la divulgation d'une vulnérabilité .12
5.8 Confidentialité des informations échangées .13
5.8.1 Généralités .13
5.8.2 Communications sécurisées .13
5.9 Bulletins de sécurité sur des vulnérabilités .14
5.10 Exploitation de vulnérabilités .14
5.11 Vulnérabilités et risque .14
6 Réception de signalements de vulnérabilités .14
6.1 Généralités .14
6.2 Signalements de vulnérabilités .14
6.2.1 Généralités .14
6.2.2 Capacité à recevoir des signalements .15
6.2.3 Surveillance .15
© ISO/IEC 2018 – Tous droits réservés iii

6.2.4 Suivi des signalements .15
6.2.5 Accusé de réception d'un signalement .16
6.3 Évaluation initiale . .16
6.4 Étude complémentaire .16
6.5 Communication continue .17
6.6 Implication des coordinateurs .17
6.7 Sécurité opérationnelle .17
7 Publication de bulletins de sécurité sur des vulnérabilités .18
7.1 Généralités .18
7.2 Bulletin de sécurité .18
7.3 Période de publication d'un bulletin de sécurité .18
7.4 Éléments d'un bulletin de sécurité .19
7.4.1 Généralités .19
7.4.2 Identifiants .19
7.4.3 Date et heure .19
7.4.4 Titre .19
7.4.5 Vue d'ensemble .20
7.4.6 Produits affectés .20
7.4.7 Public cible .20
7.4.8 Localisation .20
7.4.9 Description . . .20
7.4.10 Impact .20
7.4.11 Gravité .21
7.4.12 Remédiation .21
7.4.13 Références .21
7.4.14 Crédit . .21
7.4.15 Informations de contact .21
7.4.16 Historique des révisions .21
7.4.17 Conditions d'utilisation .21
7.5 Communication du bulletin de sécurité .21
7.6 Format du bulletin de sécurité .22
7.7 Authenticité du bulletin de sécurité .22
7.8 Remédiations .22
7.8.1 Généralités .22
7.8.2 Authenticité de la remédiation .22
7.8.3 Déploiement de remédiations .22
8 Coordination .23
8.1 Généralités .23
8.2 Fournisseurs exerçant plusieurs rôles.23
8.2.1 Généralités .23
8.2.2 Signalement de vulnérabilités entre fournisseurs .23
8.2.3 Signalement d'informations de vulnérabilités auprès d'autres fournisseurs .24
9 Politique de divulgation de vulnérabilité .24
9.1 Généralités .24
9.2 Éléments obligatoires d'une politique .24
9.2.1 Généralités .24
9.2.2 Mécanisme de contact préférentiel .24
9.3 Éléments recommandés d'une politique .25
9.3.1 Généralités .25
9.3.2 Contenu d'un signalement de vulnérabilité .25
9.3.3 Options de communications sécurisées .25
9.3.4 Définition des attentes en matière de communication .25
9.3.5 Domaine d'application .26
9.3.6 Publication .26
9.3.7 Reconnaissance .26
9.4 Éléments facultatifs d'une politique .26
9.4.1 Généralités .26
iv © ISO/IEC 2018 – Tous droits réservés

9.4.2 Aspects juridiques .26
9.4.3 Délai de divulgation . .26
Annexe A (informative) Exemples de politiques de divulgation de vulnérabilités .27
Annexe B (informative) Informations à demander dans un signalement .28
Annexe C (informative) Exemples de bulletins de sécurité.29
Annexe D (informative) Résumé des éléments normatifs .32
Bibliographie .34
© ISO/IEC 2018 – Tous droits réservés v

Avant-propos
L'ISO (Organisation internationale de normalisation) et l'IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes
nationaux membres de l'ISO ou de l'IEC participent au développement de Normes internationales
par l'intermédiaire des comités techniques créés par l'organisation concernée afin de s'occuper des
domaines particuliers de l'activité technique. Les comités techniques de l'ISO et de l'IEC collaborent
dans des domaines d'intérêt commun. D'autres organismes internationaux, gouvernementaux et non
gouvernementaux, en liaison avec l'ISO et l'IEC, participent également aux travaux.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de document. Le présent document a été rédigé
conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www .iso
.org/ directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet
de droits de propriété intellectuelle ou de droits analogues. L'ISO et l'IEC ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails
concernant les références aux droits de propriété intellectuelle ou autres droits analogues identifiés
lors de l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations
de brevets reçues par l'ISO (voir www .iso .org/ brevets) ou dans la liste des déclarations de brevets
reçues par l'IEC (voir https:// patents .iec .c).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant: www .iso .org/ iso/ fr/ avant -propos.
Le présent document a été élaboré par le comité technique mixte ISO/IEC JTC 1, Technologies de
l'information, sous-comité SC 27, Techniques de sécurité.
Cette deuxième édition annule et remplace la première édition (ISO/IEC 29147:2014), qui a fait l'objet
d'une révision technique.
Les principales modifications par rapport à l'édition précédente sont les suivantes:
— certaines dispositions normatives ont été ajoutées (synthétisées à l'Annexe D);
— de nombreuses modifications organisationnelles et rédactionnelles ont été apportées pour des
raisons de clarté.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l'adresse www .iso .org/ fr/ members .html.
Le présent document est destiné à être utilisé avec l'ISO/IEC 30111.
vi © ISO/IEC 2018 – Tous droits réservés

Introduction
Dans les contextes des technologies de l'information et de la cybersécurité, une vulnérabilité est un
comportement ou un ensemble de conditions présent dans un système, un produit, un composant ou un
service, qui viole une politique de sécurité implicite ou explicite. Une vulnérabilité peut être vue comme
une faille ou une exposition qui crée un impact ou une conséquence pour la sécurité. Des attaquants
exploitent des vulnérabilités pour compromette la confidentialité, l'intégrité, la disponibilité, le
fonctionnement ou une autre propriété de sécurité.
Les vulnérabilités sont souvent le résultat de défaillances d'un programme ou d'un système à traiter de
façon sécurisée une entrée non fiable ou imprévue. Les vulnérabilités ont diverses causes, notamment
des erreurs de codage ou de configuration, des négligences dans les choix de conception et des
spécifications de protocole et de format non sécurisées.
En dépit d'efforts significatifs pour améliorer la sécurité des logiciels, les logiciels et systèmes modernes
sont si complexes qu'il est impossible de les produire sans vulnérabilités. Les facteurs de risque des
vulnérabilités comprennent:
— l'exploitation et le recours à des systèmes qui présentent des vulnérabilités connues;
— le manque d'informations suffisantes concernant des vulnérabilités;
— l'ignorance de l'existence de vulnérabilités.
Le présent document décrit des techniques et des politiques de divulgation de vulnérabilité à l'attention
de fournisseurs qui reçoivent des signalements de vulnérabilités et publient des informations de
remédiation. Une divulgation de vulnérabilité permet à la fois la remédiation des vulnérabilités et la
prise de décisions plus avisées en matière de risque. La divulgation de vulnérabilité est un élément
essentiel du support, de la maintenance et de l'exploitation de tout produit ou service exposé à des
menaces actives. Cela comprend pratiquement tout produit ou service qui utilise des réseaux ouverts tels
qu'Internet. Une capacité de divulgation de vulnérabilité est une partie essentielle du développement, de
l'acquisition, de l'exploitation et du support de tous les produits et services. L'exploitation de produits ou
services exempts de capacités de divulgation de vulnérabilité expose les utilisateurs à un risque accru.
Le terme «divulgation de vulnérabilité» est utilisé pour décrire les activités globales associées à la
réception de signalements de vulnérabilités et à la fourniture d'informations sur leur remédiation. Les
activités supplémentaires telles que l'enquête et la priorisation des signalements, le développement,
le test et le déploiement de remédiations, ainsi que l'amélioration d'un développement sécurisé, sont
appelées «traitement de vulnérabilités» et sont décrites dans l'ISO/IEC 30111. Le terme «divulgation»
est aussi utilisé de façon plus restrictive pour désigner l'acte d'informer pour la première fois une partie
concernant une vulnérabilité (voir 3.2).
La divulgation de vulnérabilité a plusieurs objectifs majeurs:
— réduire le risque en corrigeant des vulnérabilités et en informant les utilisateurs;
— limiter autant que possible le préjudice et le coût associés à la divulgation;
— fournir aux utilisateurs des informations suffisantes pour évaluer le risque dû à des vulnérabilités;
— définir des attentes pour faciliter l'interaction et la coordination parmi les parties prenantes.
Les processus décrits dans le présent document ont pour but de réduire autant que possible le risque,
le coût et le préjudice pour l'ensemble des parties prenantes. En raison du volume de vulnérabilités
signalées, du manque d'informations précises et complètes et des autres facteurs impliqués, il n'est pas
possible de créer un seul processus figé qui s'applique à chaque événement de divulgation.
Les éléments normatifs du présent document fournissent des exigences minimales pour créer une
capacité fonctionnelle de divulgation de vulnérabilité. Il convient que les fournisseurs adaptent les
recommandations informatives du présent document à leurs besoins spécifiques ainsi qu'à ceux des
utilisateurs et autres parties prenantes.
© ISO/IEC 2018 – Tous droits réservés vii

NORME INTERNATIONALE ISO/IEC 29147:2018(F)
Technologies de l'information — Techniques de sécurité —
Divulgation de vulnérabilité
1 Domaine d'application
Le présent document fournit des exigences et des recommandations à l'attention de fournisseurs
concernant la divulgation de vulnérabilités dans des produits et services. La divulgation de
vulnérabilité permet aux utilisateurs d'effectuer une gestion des vulnérabilités techniques telle que
[1]
spécifiée dans l'ISO/IEC 27002:2013, 12.6.1 . La divulgation de vulnérabilité aide les utilisateurs à
protéger leurs systèmes et données, à prioriser les investissements défensifs et à mieux apprécier le
risque. L'objectif d'une divulgation de vulnérabilité est de réduire le risque associé à l'exploitation de
vulnérabilités. Une divulgation de vulnérabilité coordonnée est particulièrement importante lorsque
plusieurs fournisseurs sont affectés. Le présent document fournit:
— des lignes directrices sur la réception de signalements concernant des vulnérabilités potentielles;
— des lignes directrices sur la divulgation d'informations concernant la remédiation de vulnérabilités;
— des termes et définitions spécifiques à la divulgation de vulnérabilités;
— une vue d'ensemble des concepts associés à la divulgation de vulnérabilité;
— des considérations relatives aux techniques et politiques de divulgation de vulnérabilité;
— des exemples de techniques, de politiques (Annexe A) et de communications (Annexe B).
D'autres activités associées intervenant entre la réception et la divulgation de signalements de
vulnérabilités sont décrites dans l'ISO/IEC 30111.
Le présent document s'applique aux fournisseurs qui choisissent de pratiquer la divulgation de
vulnérabilité pour réduire le risque pour les utilisateurs de produits et services de fournisseurs.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO/IEC 27000, Technologies de l'information — Techniques de sécurité — Systèmes de management de la
sécurité de l'information — Vue d'ensemble et vocabulaire
ISO/IEC 30111, Technologies de l'information — Techniques de sécurité — Processus de traitement de la
vulnérabilité
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l'ISO/IEC 27000 ainsi que les suivants
s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp
© ISO/IEC 2018 – Tous droits réservés 1

— IEC Electropedia: disponible à l'adresse http:// www .electropedia .org/
3.1
vulnérabilité
comportement fonctionnel d'un produit ou service qui viole une politique de sécurité implicite ou
explicite
[1]
Note 1 à l'article: L'ISO/IEC 27002:2013, 12.6.1 utilise le terme «vulnérabilité technique» pour établir une
distinction entre le concept plus général de vulnérabilité basée sur le risque et le terme utilisé dans le présent
document.
3.2
communication
acte consistant à fournir initialement des informations relatives à une vulnérabilité (3.1) à une partie
qui n'en avait vraisemblablement pas connaissance auparavant
3.3
coordination
ensemble d'activités comprenant l'identification et l'engagement des parties prenantes, la médiation, la
communication et les autres formes de planification à l'appui d'une divulgation (3.2) de vulnérabilité (3.1)
Note 1 à l'article: Le terme «divulgation de vulnérabilité coordonnée» est utilisé pour indiquer un processus de
divulgation impliquant une coordination.
3.4
fournisseur
individu ou organisme qui a la responsabilité de résoudre des vulnérabilités
Note 1 à l'article: Un fournisseur peut être le développeur, l'agent de maintenance, le producteur, le fabricant,
l'approvisionneur, l'installateur ou le fournisseur d'un produit ou service.
3.5
déclarant
individu ou organisme qui informe un fournisseur (3.4) ou un coordinateur (3.6) d'une vulnérabilité (3.1)
potentielle
Note 1 à l'article: Aucune exigence particulière ne s'applique au fait d'agir en tant que déclarant. Les déclarants
peuvent être des individus, des organismes, des amateurs ou passionnés, des professionnels, des utilisateurs
finaux, des organismes de recherche en sécurité, des fournisseurs, des autorités gouvernementales ou des
coordinateurs.
Note 2 à l'article: Le terme «déclarant» n'implique pas une découverte ou un signalement unique ou initial(e).
Note 3 à l'article: Les déclarants peuvent être appelés «chercheurs», qu'ils mènent explicitement ou non une
recherche en sécurité ou en vulnérabilités. Historiquement, le terme «découvreur» est également utilisé pour
désigner ce rôle.
3.6
coordinateur
individu or organisme qui effectue une coordination (3.3)
3.7
remédiation
modification apportée à un produit ou service pour supprimer ou atténuer une vulnérabilité (3.1)
Note 1 à l'article: Une remédiation prend habituellement la forme d'un remplacement de fichier binaire, d'un
changement de configuration ou d'une correction et d'une recompilation du code source. Différents termes sont
utilisés pour désigner une «remédiation», par exemple patch, correctif, mise à jour, correctif d'urgence et mise à
niveau. Les mesures d'atténuation sont également appelées solutions de contournement ou contremesures.
2 © ISO/IEC 2018 – Tous droits réservés

3.8
bulletin de sécurité
document ou message qui fournit des informations relatives à une vulnérabilité (3.1) destinées à en
réduire le risque
Note 1 à l'article: Un bulletin de sécurité a pour but d'informer les utilisateurs ou autres parties prenantes
concernant une vulnérabilité, y compris, si possible, la manière d'identifier des systèmes vulnérables et d'y
remédier.
4 Abréviations
COTS Équipement sur étagère (Common Off-The-Shelf)
CRM Gestion de la relation client (Customer Relationship Management)
CSIRT Équipe d'intervention en cas d'incidents de sécurité informatique (Computer Security Inci-
dent Response Team)
[9]
CVE Vulnérabilités et expositions courantes (Common Vulnerabilities et Exposures)
CVRF Format commun de signalement de vulnérabilités (Common Vulnerability Reporting For-
[12][13]
mat)
CVSS Système commun de classement des vulnérabilités (Common Vulnerability Scoring Sys-
[10]
tem)
[11]
CWE Liste des failles courantes (Common Weakness Enumeration)
HTTP(S) Protocole de transfert hypertexte (sécurisé) (Hypertext Transfer Protocol (Secure))
OpenPGP Protocole ouvert de confidentialité PGP (Open Pretty Good Privacy)
OWASP Projet ouvert de sécurité des applications Web (Open Web Application Security Project)
PoC Preuve de concept (Proof of Concept)
PSIRT Équipe d'intervention en cas d'incidents de sécurité produit (Product Security Incident
Response Team)
S/MIME Extensions de courrier électronique à multiples fins sécurisées (Secure Multipurpose
Internet Mail Extensions)
SQL Langage de requêtes structuré (Structured Query Language)
TIC Technologies de l'Information et de la Communication
TLS Sécurité de couche de transport (Transport Layer Security)
5 Concepts
5.1 Généralités
Le présent article a pour but de fournir des informations générales et un contexte afin de mieux
comprendre le concept de divulgation de vulnérabilité.
La divulgation de vulnérabilité implique différentes parties prenantes avec des perspectives, des
incitations, des capacités et des informations disponibles différentes. De plus, la communication et
la synchronisation des processus parmi plusieurs parties prenantes peuvent devenir rapidement
© ISO/IEC 2018 – Tous droits réservés 3

compliquées. Dans la pratique, les activités décrites dans le présent document peuvent conduire à une
divulgation en raison de diverses circonstances imprévues.
5.2 Structure du présent document
Le présent document est destiné à être lu dans son intégralité pour servir de base au développement
ou à l'amélioration de politiques et processus de divulgation de vulnérabilité. Les articles suivants du
présent document sont organisés comme suit:
— Article 5: Concepts;
— Article 6: Réception de signalements de vulnérabilités;
— Article 7: Publication de bulletins de sécurité sur des vulnérabilités;
— Article 8: Coordination;
— Article 9: Politique de divulgation de vulnérabilité.
La structure du présent document n'est pas destinée à être scrupuleusement suivie dans l'ordre
indiqué. Par exemple, il convient idéalement qu'un fournisseur élabore une politique (Article 9) avant
de commencer à recevoir des signalements (Article 6).
L'Annexe D contient un résumé de tous les éléments normatifs du présent document.
5.3 Relations aux autres Normes internationales
5.3.1 ISO/IEC 30111
L'ISO/IEC 30111 doit être utilisée conjointement avec le présent document. La Figure 1 présente la
relation entre les deux Normes internationales.
Le présent document fournit des lignes directrices à l'attention des fournisseurs à inclure dans
leurs processus métier habituels lorsqu'ils reçoivent des signalements concernant des vulnérabilités
potentielles de la part d'individus ou organismes externes, et lorsqu'ils transmettent aux utilisateurs
concernés des informations relatives à la remédiation de vulnérabilités.
L'ISO/IEC 30111 fournit des lignes directrices sur la manière d'étudier, traiter et résoudre les
signalements de vulnérabilités potentielles.
Si le présent document traite de l'interface entre des fournisseurs et des déclarants, l'ISO/IEC 30111
décrit les processus internes des fournisseurs, notamment le triage, l'étude et la remédiation de
vulnérabilités, que la source du signalement soit extérieure au fournisseur ou qu'elle provienne de ses
propres équipes de sécurité, de développement ou de test.
4 © ISO/IEC 2018 – Tous droits réservés

Figure 1 — Relation entre l'ISO/IEC 29147et l'ISO/IEC 30111
5.3.2 ISO/IEC 27002
La divulgation de vulnérabilité permet la gestion des vulnérabilités techniques (ISO/IEC 27002:2013,
[1]
12.6.1 ).
© ISO/IEC 2018 – Tous droits réservés 5

5.3.3 Série ISO/IEC 27034
La sécurité des applications cherche à réduire la création de vulnérabilités d'application (voir
[4]
l'ISO/IEC 27034-1:2011, 6.5.2 ). La divulgation de vulnérabilité peut démontrer la nécessité d'introduire
des modifications à des pratiques de sécurité des applications. La divulgation de vulnérabilité ne peut
pas démontrer que la sécurité des applications est totalement efficace.
La divulgation de vulnérabilité intervient au cours des phases d'utilisation et de maintenance du modèle
de référence du cycle de vie de sécurité des applications décrit dans l'ISO/IEC TS 27034-5-1:2018, 6.3.13
[5]
et 6.3.14 .
5.3.4 ISO/IEC 27036-3
La divulgation de vulnérabilité soutient plusieurs aspects de la chaîne d'approvisionnement TIC décrite
[7]
dans l'ISO/IEC 27036-3:2013, 5.4 a), 5.8 i), 6.1.1 a) 2) et 6.3.4 .
5.3.5 ISO/IEC 27017
La divulgation de vulnérabilité est nécessaire pour permettre la gestion des vulnérabilités techniques
[3]
telle que spécifiée pour les services en nuage dans l'ISO/IEC 27017:2015, 12.6.1 .
5.3.6 Série ISO/IEC 27035
Certains plans de gestion d'incident, en particulier ceux de fournisseurs, incluent la divulgation
[6]
de vulnérabilité (voir l'ISO/IEC 27035-1:2016, Introduction ). Ces plans traitent généralement la
divulgation de vulnérabilité comme un type d'incident. La gestion d'incident peut également inclure la
[1]
gestion de vulnérabilité (voir également l'ISO/IEC 27002:2013, 12.6.1 ), qui est possible uniquement
lorsque des vulnérabilités sont divulguées.
5.3.7 Évaluation, test et spécification de sécurité
Le présent document contient des recommandations concernant les signalements de vulnérabilités
reçus de la part de sources externes, et non dans le cadre d'efforts d'assurance et d'évaluation organisés
[15] [16]
en interne. Les normes d'essai, d'assurance et d'évaluation ISO/IEC 15408 et ISO/IEC 18405 , plus
formelles, ne s'appliquent donc généralement pas.
5.4 Systèmes, composants et services
5.4.1 Systèmes
Un système est un ensemble de composants et services connectés. En matière de divulgation de
vulnérabilité, les causes d'une vulnérabilité peuvent être floues, ou être dues à des interactions entre
les parties d'un système ou entre des systèmes. Il est donc parfois nécessaire d'évoquer les systèmes
affectés par des vulnérabilités.
5.4.2 Composants
Un composant est une unité d'un logiciel ou d'un matériel qui peut à la fois constituer en soi un système
complet et être utilisée comme partie d'un système plus vaste. Un composant peut être un système
d'exploitation complet, une puce, une application, un paquet, une bibliothèque ou même un simple
fichier ou segment de code source.
Pour les besoins du présent document, la distinction entre composants matériels et logiciels est
rarement pertinente. Il n'existe que très peu de cas de vulnérabilités dans des composants purement
matériels. Dans la plupart des cas, les vulnérabilités dites «matérielles» sont généralement observées
dans des logiciels ou micrologiciels de bas niveau.
6 © ISO/IEC 2018 – Tous droits réservés

5.4.3 Produits
Un produit désigne généralement un ou plusieurs composants ou un système. Les produits sont fournis
à des utilisateurs par des fournisseurs, soit à la vente soit gratuitement et généralement sous des
conditions de licence. Il existe de nombreux types de produits différents, notamment, sans toutefois
s'y limiter, des logiciels personnalisés développés dans le cadre d'un contrat pour une utilisation sous
licence par un utilisateur spécifique, des bibliothèques destinées à être intégrées dans d'autres produits,
des produits sur étagère destinés aux marchés de masse, des projets développés par une communauté
et des offres récréatives ou de loisir.
5.4.4 Services
Un service est un ensemble de fonctions fournies à des utilisateurs. Les utilisateurs peuvent
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.