Photo by Keagan Henman on Unsplash

Don’t Be Ignorant of ISO/IEC 29147

Guidelines for the vulnerability disclosure processes

By Felipe Ruiz | February 05, 2021

If you go and look at my last post, you’ll discover or recall what happened recently to the Colombian Foreign Ministry and its digital visa platform. On that occasion, I referred to a "thoughtless vulnerability reporting" by the user who identified the weakness in that platform and by a group of journalists who published it on social networks. However, before finding out the details of that event, reflecting on it, and gathering words to offer to you through this medium, I was asked to review something else. I mean something I mentioned briefly in that writing, but judiciously posed to the reader as a possible forthcoming topic I would address here: ISO/IEC 29147:2018.

As shared on their website, ISO (the International Organization for Standardization) "is an independent, non-governmental international organization." "[It] brings together experts to share knowledge and develop voluntary, consensus-based, market relevant International Standards that support innovation and provide solutions to global challenges." In their standards catalog, the number 35 stands for the 'Information technology' group, where, among 15 different subgroups, 35.030 corresponds to the 'IT Security (including encryption).' There, we find the ISO/IEC 29147:2018, 'Information technology -Security techniques- Vulnerability disclosure.' In this post, I will introduce you to what the experts in this standard have to offer to all interested parties.


This standard takes as its primary subject Vulnerability Disclosure, i.e., in a nutshell, the act of informing stakeholders about an IT system’s vulnerability. You likely know that a vulnerability could be described as a security weakness in a system that could compromise multiple assets and operations when exploited by attackers. Factors such as the origin, severity, and impact generated by a vulnerability are variable characteristics. Nevertheless, when someone finds a vulnerability, at least in the first instance, what matters is not what its specific features are but the mere fact of reporting it. From an ethical conduct stance, everyone, whether we’re paid for it or not, should report or disclose any vulnerabilities identified for our well-being and that of others.

ISO chiefly directs this standard to vendors who may receive vulnerability reports and publish information (advisories) on their verification and remediation, for which they are responsible. Following ISO concepts, the reporter (usually the finder) is the person or organization that provides information on a potential vulnerability to the vendor or coordinator. On the other hand, the latter acts as an intermediary if communication and negotiation between stakeholders require it. It’s relevant to note that, apart from users, coordinators, and even vendors, can act as reporters.

The procedures of receiving reports and distributing remediation advisories are only two elements of a broader process. Some of the other steps involve different International Standards, such as the ISO/IEC 30111 for vulnerability handling methods, which we may discuss on another occasion. In general terms, we could describe that process as follows: a reporter contacts a vendor about a potential vulnerability, the vendor verifies the material and, if dealing with a genuine exposure, develops and implements remediation, subsequently publishing a related advisory to stakeholders.

However, as the main focus of this post, let’s mention some ISO recommendations that can serve as a valuable support for those companies that want to establish or enhance their vulnerability disclosure policies and methods.

Javier Allegue Barros
Figure 1. Photo by Javier Allegue Barros on Unsplash


For the appropriate receipt of reports, as a priority, vendors should develop policies and a comprehensive program that must be visible and available to all potential reporters. While it is ideal for a company to keep its IT systems under assessment through third-party vendors such as Fluid Attacks, it is always prudent to have everything ready to receive reports from any source. The lack of a vulnerability disclosure program can lead to reporters ending up publishing information without the vendor knowing about it beforehand. Similar in a certain way to what occurred to the Colombian Foreign Ministry. However, when the issue is not already public, reporters should try to transmit the sensitive vulnerability information confidentially to prevent attacks. It would also be great to give vendors enough time to fix the vulnerabilities found before talking about them publicly.


Although vendors could adhere to existing vulnerability disclosure policies, they could also create policies that apply to their employees and affiliates, and individuals outside the companies. Among their particular requirements, vendors should make public their intentions, expectations, and responsibilities concerning all stakeholders in an accurate and straightforward manner that facilitates communication. Policies should also contain information on preferred contact mechanisms and their security technology for confidentiality, as well as details on the required content for every report, among other things.

Receiving reports

The capability to receive vulnerability reports and establish efficient working relationships and ensure all involved people’s safety adheres to the vendor’s preparation phase. The reporting mechanisms to be enabled to reporters could be, as usual, emails, issue tracking systems, and web forms, but all of them should be as protected and confidential as possible. In addition, to facilitate the next step of verifying the potential vulnerability, the vendor should ask reporters for data such as the affected product/service, type of weakness, cause, severity, impact, evidence, among others. Of course, the vendor needs to be aware that a report made by a person who found the vulnerability, for example, by accident, is not going to include all that required data. Consequently, that operation always depends on the reporter’s technical knowledge, and the vendor should be prepared for it.

On the other hand, prepared and capable vendors should regularly monitor their reporting mechanisms, communications on reports already received, and internal channels and public sources for possible vulnerability reports. Vendors should be ready to give quick but simultaneously meaningful responses to reporters. (Caution: frustrated reporters may choose to release information wherever they feel inclined to do so.) Next, a reporter has the right to be informed whether the vulnerability has begun to be under investigation, whether more information is required in their report, or whether it is currently irrelevant. In those cases where reports lead to research, the previously mentioned vulnerability handling processes kick off, and the vendors build and test remediations about which they should later distribute advisories. Certainly, they should not forget to keep reporters up to date.

Distributing remediation advisories

Vendors may disseminate advisories related to vulnerability remediation either only to their users or to the general public. Users should receive information on the affected products/services and the remediation achieved along with corresponding instructions. For example, sometimes, users have to install updates or patches that constitute vulnerability fixing. Nevertheless, it is preferable to have automatic update deployment systems. In contrast, when a vulnerability is under exploitation, and no remediation is available, vendors should inform users about the threat and temporary solutions and guidelines to reduce risks. Always bearing in mind that if the information is public, it must avoid the exhibition of any specification advantageous to malicious hackers.

A quote to remember

"Vulnerability disclosure helps users protect their systems and data, prioritize defensive investments, and […​] make better risk decisions." ISO/IEC 29147:2018

PS: Many important details are missing in this post. If you’re really curious about vulnerability disclosure, we recommend that you read the entire ISO/IEC 29147:2018 document.