Key points
- Build a vulnerability disclosure program (VDP) with a clear triage process to validate, prioritize, remediate, and document every reported security vulnerability.
- Follow a consistent vulnerability triage workflow to confirm reports, determine severity, and assign each issue to the right owner.
- Make your vulnerability disclosure process easy to use by asking for the essential details without creating unnecessary barriers for reporters.
- Track every vulnerability through remediation so you can verify the fix, maintain an audit trail, and prove the issue was resolved.
- Keep stakeholders informed throughout the disclosure process and measure performance with metrics like response time and remediation time.
Building an effective, transparent, and accessible vulnerability disclosure program (VDP) helps you build trust with your clients, users, and their customers. It’s not just software developers and vendors that must accept reports and disclose vulnerabilities – IT teams and managed service providers (MSPs) recommend, implement, and manage infrastructure, software, and configurations that present vulnerabilities – making you responsible for making sure that stakeholders are aware of risks to their data, and remediating them.
Once an external party has reported a vulnerability, you need a fast, reliable, and repeatable triage process. The report needs to be validated, communicated to stakeholders, prioritized, and finally turned into traceable remediation actions. This must all be followed by confirmation and reportable evidence that the vulnerability is closed.
This guide provides a template for this vulnerability disclosure triage process.
What is a vulnerability disclosure program (VDP)?
A vulnerability disclosure program allows external parties to alert your IT team of a suspected cybersecurity vulnerability that affects your organization.
This consists of vulnerability disclosure processes that span initial report submission, triage, communication to affected parties and stakeholders, remediation, and finally evidence collection and a final vulnerability report that confirms the closure of the issue.
These processes should be set in a policy that defines how and where reports are submitted, what information should be provided, who is in charge of initial review, and how the report is routed to the technician responsible. From there, reported vulnerabilities need to be confirmed, assigned a severity, prioritized, and assigned for remediation.
Your VDP processes should also cover communicating the vulnerability, its risks, and whether it has been successfully exploited, to internal stakeholders and any parties that may have their protected data threatened.
Why is a vulnerability disclosure program useful for MSPs
MSPs are responsible for IT security for their clients. Existing flaws in operating systems, cloud platforms, and third-party software impact both you and your clients, and you may introduce your own vulnerabilities through configuration errors.
To provide effective security and meet compliance goals, you must provide external parties with a way to report potential vulnerabilities so that you can investigate them.
What a security vulnerability report should include
When an external party submits a report, you should prompt them for the following pertinent information:
- The affected system, product, application, or endpoint
- Vulnerability description and steps to reproduce
- Evidence, screenshots, logs, or proof of concept
- Potential impact
- Reporter contact information
- Date submitted
- Suggested severity
- Whether the issue has been shared elsewhere
This should provide sufficient evidence to confirm the issue without requiring follow-up that delays investigation. However, any and all additional details and context should also be gathered through free text fields, or follow-up by a support agent (without waiting for a response before initiating investigation).
Key to the submission process is making it as frictionless as possible. Do not require all fields to be filled, or add frustrating form validation – the process must be as easy as possible to encourage submissions. Your disclosure form or contact details should also be readily findable for those who are looking for it.
VDP workflow: How to triage vulnerability reports
Once a vulnerability disclosure report is submitted, your VDP workflow should quickly determine whether the report is valid, and prioritize it.
Your triage workflow should be practicable with clearly defined steps that can be checked off to ensure that the report was fully investigated, and if confirmed, properly handed off for remediation.
The workflow below can act as a template for your own vulnerability disclosure process for intake and triage:
- Acknowledge receipt of the report
- Confirm the report is in scope
- Check whether the issue is a duplicate
- Validate the vulnerability safely
- Assess exploitability and business impact
- Assign severity
- Route the issue to the correct owner
- Create a remediation ticket or tracking record
- Define next communication and review steps
How to route and track vulnerability remediation
Your triage workflow should be followed by a self-contained remediation workflow. This allows it to be assigned to the technician responsible for the area that the vulnerability affects, and once the issue is fixed, it can be returned to the technician or team in charge of your VDP for validation.
Your remediation workflow should be assigned to a specific person until its completion, and linked to the inbound report. Usually, this is done using a support ticket. Target dates should be set based on severity and priority, and progress should be tracked. When a fix or control is implemented, it should be documented alongside test results confirming its effectiveness – with this information stored in your documentation platform for later audit or review.
Temporary workarounds should be handled the same way, but with scheduled reminders that a permanent fix needs to be deployed when possible, with responsibility retained across the process, even if it spans a period of time.
Communication and closure
The success of a VDP workflow is predicated on clear communication.
The submitter should receive acknowledgement for their disclosure, and again when it is confirmed. Internal stakeholders should be kept up to date on vulnerabilities that affect their areas of concern, including notifying legal stakeholders where compliance may have been breached or there was a notifiable event. Customers, clients, and users must be informed if their data was potentially breached — both for transparency, trust, and compliance.
The successful closure of vulnerabilities should be communicated to all parties involved (with a hearty thanks to the submitter when the vulnerability is closed!).
Metrics to track
Throughout your VDP workflow, you should collect metrics that demonstrate its effectiveness, and provide measures for future improvement.
These can include data such as:
- Time to acknowledge, validate, triage, and remediate
- Duplicate report rate
- Reports by severity and affected system
- Reopened reports
- Reports closed without action
- Reports awaiting owner response
Common mistakes in VDP workflows
Vulnerability disclosure reports must be triaged and acted on immediately: if a well-meaning external party has noticed a vulnerability, it’s very possible a less altruistic actor is actively working to exploit it. However, treating every report as an actual incident before confirming it will waste resources and induce burnout in your team. Similarly, reports should be de-duplicated to prevent resource waste.
Responsibility and decisions should all be documented, and ownership should be tracked across all VDP workflows. Though some reports may be out of scope (i.e., a vendor’s responsibility), they should not be ignored. You should ensure they are documented for visibility, and so that if the same issue is reported, time is not wasted re-investigating. You will also need to track the vendor’s progress in resolving the issue and may need to implement temporary mitigations in the meantime.
Always consult legal, compliance, and/or security leadership and experts when there is any potential customer or legal impact, or public communication is involved.
Finally, a vulnerability disclosure program is not a bug bounty. This needs to be made clear through your submission process so that those making vulnerability reports don’t feel misled (through their own assumptions or misunderstanding).
Confirming, reporting, and documenting the results of vulnerability disclosure programs and vulnerability management
The NinjaOne IT management platform includes many of the tools you need to create and maintain a robust vulnerability disclosure management program.
Accept reports, assign responsibility, communicate with stakeholders, and track progress through NinjaOne’s ticketing system. Monitor results using built-in secure documentation, deploy automated remediation scripts and patches, and confirm resolution using endpoint monitoring.
NinjaOne also includes vulnerability and patch management tools that automate remediation, and asset and inventory tools for a comprehensive view of your IT infrastructure.
