Software suppliers should handle vulnerability reports through a clear, secure and accountable process. This includes providing a reporting channel, acknowledging submissions, investigating potential security weaknesses, developing appropriate fixes and communicating with affected users. Where necessary, suppliers should also coordinate disclosure with security researchers, other vendors and relevant authorities.
For organisations that depend on third-party software, vulnerability handling is an important part of supplier risk management. A vulnerability does not automatically mean a product is unsafe, but the way its supplier responds can reveal a great deal about its security practices. The EU Cyber Resilience Act (CRA) is also making vulnerability management a more explicit regulatory responsibility for manufacturers of covered digital products. Specific reporting obligations have applied since 11 September 2026, while most other requirements will apply from 11 December 2027.
Understanding how suppliers respond to vulnerabilities helps organisations make better decisions about the software they trust.
Why Vulnerability Handling Matters
Software vulnerabilities can exist in commercial applications, open-source components, cloud integrations and other digital products. They may be discovered during internal testing, reported by independent security researchers or identified through information about a third-party dependency. Discovering a vulnerability is not necessarily evidence of negligence, since complex software can contain weaknesses despite careful development and testing. What matters is whether the supplier has a reliable process to investigate and address those weaknesses.
Consider an organisation using a business application that processes customer information. A security researcher discovers a potential vulnerability in one of its components and contacts the supplier. Without a clear reporting channel, the researcher may struggle to reach the right people, while a delayed investigation can leave customers unaware of a potential risk. Even when a fix becomes available, affected organisations still need to understand whether their systems are vulnerable and what action to take.
Vulnerability handling therefore involves more than fixing code. It connects software development, security operations, supplier responsibility and communication, all of which influence how effectively a security issue can be resolved.
What Is Coordinated Vulnerability Disclosure?
Coordinated Vulnerability Disclosure (CVD) is a structured approach through which people who discover security vulnerabilities work with the responsible organisations to investigate, resolve and disclose them appropriately. Instead of immediately publishing potentially sensitive technical details, the parties coordinate how the vulnerability will be handled and when information should become public. The objective is to give affected organisations and users a reasonable opportunity to reduce their exposure without unnecessarily delaying important security information.
The European Union Agency for Cybersecurity (ENISA) recognises coordinated disclosure as an important mechanism for strengthening cybersecurity across the European Union. It often involves several parties, especially when a vulnerability affects software components used by multiple vendors. Cooperation helps align remediation efforts and reduces the likelihood that important information is overlooked.
CVD should not be confused with a bug bounty programme. A supplier can establish an effective vulnerability disclosure process without offering financial rewards. Recognition or compensation may encourage responsible reporting, but the essential requirement is that reports can be received, assessed and acted upon.
Six Steps in a Responsible Vulnerability Handling Process
A professional vulnerability handling process should connect technical investigation with clear ownership, appropriate remediation and reliable communication. Although the details will vary between organisations and products, six practical steps provide a useful foundation.
1. Provide a Clear and Secure Reporting Channel
Researchers, customers and technical partners need to know where potential vulnerabilities can be reported. A supplier should provide an accessible security contact or reporting page, ideally supported by a published disclosure policy. This policy should explain which products are covered, how reports can be submitted, what information is useful and how the supplier intends to communicate with reporters.
A secure submission method is particularly important because reports may contain sensitive technical information or evidence that could be misused. Public issue trackers and ordinary support forums are not always appropriate for confidential vulnerability details. The Netherlands’ National Cyber Security Centre (NCSC) provides an example of a structured reporting process, including guidance on confidential communication and responsible disclosure.
2. Acknowledge Reports and Assign Responsibility
Once a report arrives, it should reach someone with the authority and expertise to investigate it. An acknowledgement confirms that the report has been received and should provide a practical indication of what happens next. At this stage, the supplier does not necessarily need to confirm that a vulnerability exists, but the reporter should know that the submission is being handled.
Internally, the supplier should record the report, assign an accountable owner and establish an appropriate priority. A documented response process helps prevent reports from becoming lost between development, security and customer support teams. It should also establish reasonable communication expectations without promising unrealistic resolution dates before the issue has been investigated.
3. Assess the Vulnerability and Its Potential Impact
Not every reported weakness presents the same level of risk. A supplier should determine whether the issue can be reproduced, which product versions or components may be affected, what an attacker might achieve and whether there is evidence of exploitation. The investigation should distinguish between a confirmed vulnerability, a potential weakness requiring further research and a finding that does not create a meaningful security risk.
Technical severity is important, but it should not be considered in isolation from the environments where software is used. For example, a weakness in an administrative interface may have different consequences depending on whether that interface is publicly accessible or restricted to authorised personnel. Dependencies also matter, because a vulnerability in a third-party library may affect several products even when the underlying problem was not introduced by the supplier itself.
A useful investigation should produce a documented assessment, including the reasoning behind its conclusions and the actions that follow.
4. Develop, Test and Distribute Appropriate Fixes
When a vulnerability is confirmed, the supplier should determine how to eliminate or reduce the risk. Depending on the circumstances, remediation may involve a software update, a configuration change, temporary mitigation measures or coordinated work with another supplier. Security fixes should be tested sufficiently to reduce the likelihood of introducing additional problems, and their distribution should allow customers to obtain legitimate, trustworthy updates.
Supported product versions and dependencies require particular attention. If a vulnerable component is used by multiple versions of an application, updating the latest release alone may not protect every supported installation. Suppliers should consider which versions remain supported, how customers receive updates and whether affected organisations can realistically implement the proposed remedy.
Where a permanent fix is not immediately available, clear temporary mitigations may help customers reduce their exposure while further work continues.
5. Communicate With Researchers and Affected Customers
Effective vulnerability handling requires communication with different audiences. Researchers need appropriate progress updates and coordination about disclosure, while affected customers need information that helps them understand the consequences for their systems. A useful security advisory should identify the affected products and versions, explain the potential impact, describe available fixes or mitigations and make the recommended action clear.
The timing and technical detail of public disclosure require judgement. Publishing information that makes exploitation easier before users can reasonably protect themselves may introduce unnecessary risk. However, withholding important information indefinitely can also leave customers exposed or prevent them from making informed decisions.
A coordinated approach seeks an appropriate balance between transparency, timely communication and the protection of affected users.
6. Document the Outcome and Improve the Process
Closing a vulnerability report should involve more than marking a development task as complete. The supplier should retain an appropriate record of the report, investigation, decisions, remediation and relevant communication. These records support accountability, help establish what happened and make it easier to identify recurring weaknesses.
For example, multiple vulnerabilities involving the same dependency, permission model or development practice may indicate a broader problem that deserves attention. Reviewing these patterns can help suppliers improve security testing, architecture, dependency management and future response procedures. A mature vulnerability handling process should therefore contribute to continuous improvement rather than simply resolving individual reports.
What Does the EU Cyber Resilience Act Require?
The Cyber Resilience Act, Regulation (EU) 2024/2847, introduces cybersecurity requirements for covered hardware and software products made available on the European Union market. Its vulnerability handling provisions are particularly relevant to manufacturers of products with digital elements, including software manufacturers where the regulation applies. Under Annex I, Part II, the CRA establishes requirements concerning vulnerability identification and remediation, security testing, coordinated vulnerability disclosure, reporting channels and secure distribution of updates.
However, the implementation dates and the distinction between different obligations are important.
Since 11 September 2026, manufacturers within the relevant scope have been required to report actively exploited vulnerabilities and severe incidents affecting the security of their products. According to the European Commission’s guidance on CRA reporting obligations, the reporting sequence includes:
- Within 24 hours: an early warning after becoming aware of a relevant event.
- Within 72 hours: a further notification containing the required information.
- Actively exploited vulnerabilities: a final report no later than 14 days after a corrective or mitigating measure becomes available.
- Severe incidents: a final report within one month after the 72-hour notification.
Manufacturers submit these notifications through the CRA Single Reporting Platform established by ENISA.
Not every vulnerability report automatically triggers these deadlines. The reporting duties concern specific categories of events defined by the regulation, and a newly reported or unverified weakness is not automatically an actively exploited vulnerability. Organisations should therefore distinguish general vulnerability intake and investigation from incidents or vulnerabilities that meet the CRA’s legal reporting criteria.
The CRA’s main requirements, including its broader vulnerability handling provisions, become applicable from 11 December 2027. Reporting obligations for open-source software stewards also apply from that later date, where the relevant provisions cover them. The precise responsibilities depend on the product, the organisation’s legal role and the regulation’s scope, meaning that a software manufacturer, an IT service provider and an organisation using purchased software do not necessarily have the same obligations.
For the complete legal framework, consult the Cyber Resilience Act on EUR-Lex and the European Commission’s CRA overview.
How Can Organisations Evaluate Their Software Suppliers?
Organisations do not need to conduct a comprehensive technical security audit of every software supplier to begin asking meaningful questions. A practical supplier review can start by examining whether vulnerability handling is documented, understandable and supported by credible operational practices.
Five questions provide a useful starting point.
Is There a Published Vulnerability Disclosure Policy?
Check whether the supplier provides clear instructions for reporting security concerns, including an appropriate contact channel. A published policy makes it easier for researchers and customers to know where to report a potential weakness. It should also explain the scope of the reporting process and the general expectations for communication.
Who Is Responsible for Responding?
Determine whether security reports are handled through an established process with clear ownership. Vulnerability reports should not depend entirely on an ordinary customer support queue without a defined escalation route. Suppliers should be able to explain how potentially serious findings reach the people responsible for investigating them.
How Are Security Updates Managed?
Ask how the supplier identifies affected versions, develops fixes and distributes updates. Understanding which product versions remain supported is particularly important when an organisation relies on older software or customised deployments. A credible update process should address both the technical remedy and the practical steps customers need to take.
How Will Customers Be Informed?
Look for documented security advisories, release notes or other appropriate communication methods. A supplier should be able to explain how affected customers learn about important vulnerabilities, available mitigations and necessary updates. Communication should be sufficiently clear for customers to determine whether action is required in their own environment.
What Happens When a Third-Party Component Is Vulnerable?
Ask how software dependencies are monitored and how the supplier coordinates with upstream maintainers when an external component requires attention. A vulnerability in a widely used dependency can affect products from multiple vendors, creating responsibilities that extend beyond a single development team. Suppliers should understand which components they depend on and have a reasonable way to assess whether newly disclosed vulnerabilities affect their products.
These questions help organisations determine whether vulnerability handling is an operational capability rather than an informal promise.
Organisations can also consult the European Vulnerability Database (EUVD), maintained by ENISA, for information about published vulnerabilities, affected products and available mitigation details. The database provides useful evidence for supplier reviews, but it should not replace direct communication with the supplier or an assessment of the organisation’s actual software environment.
What if a Supplier Does Not Respond?
A missing or inadequate response to a vulnerability report deserves attention, particularly when the potential impact is significant. The first step is to confirm that the report reached the correct security contact and to document the original submission, subsequent communication attempts and any acknowledgement received. Where appropriate, the issue can be escalated through the supplier’s established security or contractual channels.
If the vulnerability may affect multiple organisations or products, involvement from a relevant national Computer Security Incident Response Team (CSIRT) may be appropriate. In the Netherlands, the NCSC explains that vulnerabilities in products or systems outside the Dutch central government should first be reported to the responsible owner or supplier. Where that organisation does not respond adequately, the NCSC may act as an intermediary after receiving evidence of previous contact attempts.
Public disclosure should not be used casually as a substitute for an effective escalation process. The potential consequences for affected users, applicable law and coordinated disclosure arrangements must be considered before releasing sensitive technical information. For organisations relying on the supplier, continued failure to respond may also justify reviewing contractual responsibilities, available mitigations, operational dependencies and alternative solutions.
The objective is not to penalise suppliers simply because vulnerabilities have been discovered. It is to ensure that credible security concerns receive appropriate attention and that affected organisations can make informed decisions.
Vulnerability Handling Is Part of Supplier Governance
Vulnerability handling should not be considered separately from the wider relationship between an organisation and its software suppliers. Supplier selection, contractual responsibilities, security updates, dependency management and incident response all influence the ability to respond effectively when a security issue arises. An organisation may work with technically capable suppliers but still encounter problems if nobody knows who should contact them, who can authorise an emergency update or who is responsible for assessing the business impact.
This makes clear ownership important on both sides of the supplier relationship. Software suppliers need dependable processes for receiving and resolving reports, while their customers need sufficient visibility to understand dependencies, act on advisories and maintain their systems responsibly.
The same principle applies when introducing new software. Our guide on assessing a WordPress plugin before installation explains how to consider maintenance and supplier trust before adding a new dependency. Similarly, a documented digital supplier handover helps ensure that operational responsibilities remain clear when service relationships change.
Neither a vulnerability disclosure policy nor an absence of reported vulnerabilities guarantees that a supplier is secure. These are individual signals that should be considered alongside actual practices, technical evidence and the organisation’s needs. Good governance comes from understanding these factors together rather than treating any single document or security claim as sufficient proof of trustworthiness.
Conclusion
Software vulnerabilities cannot always be prevented, but their handling should not depend entirely on improvisation. Responsible suppliers make it possible to report weaknesses securely, investigate them consistently, deliver appropriate remedies and communicate with the people who may be affected. Clear procedures and documented responsibilities also make it easier to learn from vulnerabilities and improve future security practices.
For organisations using third-party software, evaluating these capabilities is a practical part of digital governance. It helps clarify expectations, improve supplier accountability and reduce avoidable uncertainty when security issues arise.
The most useful question is not whether a supplier has ever received a vulnerability report. It is whether the supplier has a credible process for dealing with one when it happens.
This article provides general information about software security and European regulatory developments. It is not legal advice or a substitute for a product-specific security or regulatory assessment.
