Vulnerability Management Process¶

Version: 2.1

WSO2 treats security vulnerability disclosures with the highest priority and follows a Coordinated Vulnerability Disclosure (CVD) program to ensure they are handled responsibly and consistently. This page outlines the process for receiving, assessing, remediating, and coordinating the disclosure of reported vulnerabilities, including communication with affected customers, security researchers, and the broader public.

Sources¶

WSO2 receives vulnerability information through the following channels:

• Internal security testing. Continuous scanning of WSO2 infrastructure, services, and product versions (both released and under development) using industry-standard tooling.
• Security mailing lists. Public reporting channels for vulnerabilities in WSO2 products and services. Submission requirements are documented in Vulnerability Reporting Guidelines.
• Customer Support Portal. Confidential reporting channel for WSO2 customers with an active subscription.
• External sources. Third-party security mailing lists, vendor security notifications, and public vulnerability databases.

Raw automated scan reports submitted through the public security mailing lists are not processed; the false-positive rate of automated scanning is too high to make blanket triage useful. Only verified findings with reproduction steps enter the handling process. Submissions from WSO2 customers go through the Customer Scan Report Submissions workflow.

Severity Classification¶

Severity is assigned per the Common Vulnerability Scoring System v3.1 for products listed in the WSO2 Support Matrix. The WSO2 classification mapping:

Resolution Timeframes¶

Target resolution windows run from the date a report is confirmed as a true positive.

For confirmed security breaches or zero-day vulnerabilities, WSO2 takes immediate action.

Vulnerability Handling Process¶

The lifecycle of a reported vulnerability:

1. Acknowledgement. WSO2 acknowledges receipt and creates an internal ticket to track progress.
2. Routing. The report is treated as high priority and directed to the responsible product or services team.
3. Evaluation. The product or services team, the product's security champion, and the Platform Security team jointly evaluate the report.
4. Non-threat. If the report does not constitute a threat to the product or service, WSO2 responds with the reasoning.
5. Confirmed threat. If the report is a real vulnerability, WSO2 accepts the issue and proceeds.
6. Mitigation. The product team identifies a configuration mitigation if one exists, then begins work on a code fix.
7. ETA for customer reporters. If the reporter is a WSO2 customer, an ETA is communicated for the patch on the affected product version.
8. Coordinated disclosure for non-customer reporters. If the reporter is not a WSO2 customer:
   • Identify every product version that needs a fix (see Backport Policy).
   • Estimate the effort to patch each.
   • Set a target date for issuing the fixes to customers.
   • Add a one-month buffer beyond that date for the public announcement.
   • Per WSO2's responsible-disclosure ethics, confirm the public announcement date with the reporter before disclosure.
9. Patch development. The fix is created.
10. Internal identifier. Assigned in the format WSO2-<year>-<ticket> (e.g., WSO2-2016-0010).
11. Security advisory. A security advisory is drafted covering impact and mitigation.
12. Delivery to customer reporter. If the reporter is a WSO2 customer, the patch is delivered directly to that customer.
13. Delivery to non-customer reporter. If the reporter is not a WSO2 customer, the source-code diff is provided on request. The public advisory is published after all customer patches are delivered and the buffer period elapses.

Backport Policy¶

Security fixes are proactively backported to product versions marked as Available or Deprecated in the WSO2 Support Matrix and distributed to customers through WSO2 Updates.

Customer Announcements¶

Once a fix and its security advisory are ready for every affected product version within the backport policy, they are shared with all WSO2 customers in the monthly Customer Announcement issued on the last working day of each month.

Adjustments to the monthly cycle:

• Customer-reported vulnerabilities. The reporting customer receives the fix as soon as it is ready, without waiting for the monthly announcement.
• Catastrophic vulnerabilities. Fixes are announced to all customers immediately; the monthly cycle is bypassed.

Public Disclosure¶

After the monthly customer announcement, a four-week buffer allows customers to apply the patches. The vulnerability is then published on the Security Advisories page. The content of the public advisory depends on the CVSS score and whether the latest product version is affected:

• CVSS ≥ 9.0, latest version affected. A patch release of the product follows the buffer period; the public advisory describes the issue and announces the patch release.
• CVSS < 9.0, latest version affected. The public advisory describes the issue, available risk mitigations, and the pull-request reference for the fix.
• Latest version not affected. The public advisory advises community users to update to the latest product version.

Acknowledgements¶

Security researchers who report vulnerabilities to WSO2 are credited on the relevant security advisory and listed on the Security Hall of Fame. Inclusion on either page is subject to the researcher's consent. The full program is documented in the WSO2 Security Reward and Acknowledgement Program.

Customer Scan Report Submissions¶

WSO2 customers may submit security scanning reports for analysis. Submission requirements:

• Reports must be submitted through the WSO2 Support Portal.
• Reports must contain only vulnerabilities in WSO2 products or product dependencies, not operating-system, application-runtime, or infrastructure-configuration findings.
• Each report must cover a single product version.

Supported scanner output formats:

Reports from scanners not in the supported list are accepted when converted to the WSO2 Common Vulnerability Format and submitted alongside the original output.