Don't Be Ignorant of ISO/IEC 29147

Guidelines for the vulnerability disclosure processes

Blog Don't Be Ignorant of ISO/IEC 29147

| 5 min read

Contact us

If you go and look at my last post, you’ll see what happened not long ago to the Colombian Foreign Ministry and its digital visa platform. At that time, I referred to a "thoughtless vulnerability reporting." This was attributed both to the user who identified the weakness in that platform and to the group of journalists who published it on social networks. However, before finding out the details of that event and reflecting on it, I was asked to review something else. I mean something I mentioned in brief in that post but judiciously posed to the reader as a possible forthcoming topic I would cover here: ISO/IEC 29147:2018.

As shared on their site, 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 list, the number 35 stands for the 'Information technology' group. 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.


This standard takes as its main 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 some assets and operations when exploited by attackers. Factors such as the origin, severity, and impact generated by a vulnerability are variable characteristics. Nevertheless, when a person finds a vulnerability, at least at first, what matters most is not its specific features. What is vital is the mere fact of reporting it. From an ethical conduct stance, everyone should report any identified vulnerability either we are paid for it or not. This would be to our benefit and that of others.

ISO chiefly directs this standard to vendors. Those who may get vulnerability reports and publish advisories on their verification and remediation, for which they are responsible. Following ISO terms, the reporter (most often the finder) is the person or team that gives information on a potential issue to the vendor or coordinator. On the other hand, the latter acts as an intermediary if communication and negotiation between stakeholders require it. It is apt 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 parts of a broader process. Some of the other steps involve different International Standards, e.g., the ISO/IEC 30111 for vulnerability handling methods, which I talk about in another blog post. In broad terms, we could describe that process as follows: First, a reporter contacts a vendor about a potential vulnerability. Then, the vendor verifies the issue and, if dealing with a genuine exposure, develops and implements remediation. In the end, the vendor publishes a related advisory to all stakeholders.

However, as the main focus of this post, let us mention some tips from ISO. These can serve as valuable support for those firms that want to set up or enhance their vulnerability disclosure policies and methods.

Javier Allegue Barros

Photo by J. A. Barros on Unsplash.


For the proper receipt of reports, as a priority, vendors should develop policies and a full program that must be visible and open to all potential reporters. It is ideal for a company to keep its IT systems under assessment through third-party vendors such as Fluid Attacks. But it is always prudent to have everything ready to receive reports from any other source. The lack of a vulnerability disclosure program can lead to reporters ending up publishing data without the vendor knowing about it ahead of time. 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 send sensitive vulnerability information confidentially to prevent attacks. It would also be great to give vendors enough time to fix the vulnerabilities before talking about them publicly.

Get started with Fluid Attacks' Vulnerability Management solution right now


It is clear that vendors can adhere to existing vulnerability disclosure policies. But they can also create requirements that apply to their staff, affiliates and outsiders. Among their particular policies, vendors should make public their intentions, expectations and responsibilities in relation to stakeholders. All this in an accurate and simple way that facilitates communication. Policies should contain information on preferred contact mechanisms and their security technology for confidentiality. They should also include details on the required content for every report, among other things.

Receiving reports

The capabilities to take vulnerability reports, establish efficient working relationships and ensure all involved people’s safety adhere 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 ease the next step of verifying the potential vulnerability, the vendor should ask reporters for some data: 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, e.g., by accident, is not going to include all that required data. Thus, 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 at the same time meaningful responses to reporters. (Caution: frustrated reporters may choose to release data wherever they feel inclined to do so.) Next, a reporter has the right to be informed of the following: 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 wider public. Users should receive information on the affected products/services and the remediation achieved along with corresponding instructions. For example, users have to install from time to time 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 this: if the data 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 major details are missing in this blog post. If you are really curious about vulnerability disclosure, we recommend that you read the full text of ISO/IEC 29147:2018.

Subscribe to our blog

Sign up for Fluid Attacks' weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by FlyD on Unsplash

Software supply chain management in financial services

Photo by Robs on Unsplash

Consequential data breaches in the finance sector

Photo by Towfiqu barbhuiya on Unsplash

Data protection in the financial sector, tips and more

Photo by Jasmin Egger on Unsplash

If the essential security layer is flawed, you're toast

Photo by Christian Wiediger on Unsplash

The need to enhance security within the fintech sector

Photo by Claudio Schwarz on Unsplash

Is your financial service as secure as you think?

Photo by mitchell kavan on Unsplash

Bringing the zero trust model to life

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.