Message from the Chair

Vulnerabilities ... What's in a name? (again)

VulnCon 2026 came at a perfect time. Over the years, vulnerabilities have become a subject of choice.

Vulnerabilities are all over the press, social media, blogs, reports and ... our mailing lists, our messaging apps, discussions in our FIRST community. And vulnerabilities translate for most into CVEs. But some are not CVEs.

Based on the number of vulnerabilities to tackle and technical debt, a direction would be to look at vulnerabilities, get some help from prioritization (manual, automated, or from tools) and act, or ask for action to be taken by the right stakeholders. By the way, another good question here: who are these "stakeholders"? Centralized / decentralized / local / remote team(s), internal / external / contractor(s) team(s)? Let us simply call them the 'ops team'. Please translate in your own context.

Or ask the IT team or teams to take your prioritized list and act or ask for action to be taken.

Or gather inventory data, application data, data matrix flows, business-related diagrams, security assessments, and business impact analyses, then adapt your plan to the business context and constraints, publish it, and act, or ask for action to be taken.

Or follow any other process you have crafted over the years, and then act, or ask for action to be taken.

Action comes down to patching the ailing component in most cases. However, there are more options from the direst to the worst: remove, isolate, suspend, restrict, replace, mitigate, forget, hide, lie!

The job will be done, someone is caring for it, good ... until something goes wrong. Or nothing happens, or things are partially managed.

If a CSIRT (but it could be a CERT, a VOC or whoever oversees operations related to vulnerabilities) does not get status reports, the situation can only worsen. The less visibility, the worse.

Let us consider the role a CSIRT could have at best, or at worst, as this will translate into additional workload.

The list of requested actions as mentioned above is not static and will obviously evolve. A good reason for that is that if EPSS is one of the metrics used, a vulnerability score may evolve daily.

New threat intel and new IOCs may come, and priorities may shift. CSIRTs must be able to update their requests to the ops teams, know whether they are implemented and how fast, and update their knowledge and CMDBs, of course.

CSIRTs need to know progress or failure, and how the security level improves, remains stable or worsens.

Proper reporting is a necessity to prevent lowering the security level. CSIRTs must be able to escalate in case of regression.

CSIRTs need both to be aware and to have the ability to escalate. This is just a partial list of topics addressed during a fruitful VulnCon 2026.

If interested, join one of the Special Interest Groups (SIGs) dealing with vulnerabilities, such as CVSS, EPSS, PSIRT, SOC and Vulnerability Coordination, to name a few.

Also, think about joining the FIRST VulnOptiCon event (previously known as Vuln4Cast TC) in September 2026 in Luxembourg, or preparing for VulnCon 2027 in an even more interesting context.

Published on FIRST POST: Jan-Mar 2026