

Vulnerability Management Process

WSO2 conducts security reviews and tests throughout the entire software development lifecycle (SDLC) to make sure our products and services are secure against all known vulnerabilities. However, even with the most stringent tests, some vulnerabilities can go unnoticed. That is why WSO2 treats security vulnerability disclosures with the highest priority. We have an efficient process to evaluate such disclosures urgently and take steps to mitigate risks.

This document explains the processes that handle security vulnerabilities from their discovery to mitigation.

Security Vulnerability Sources

We receive security vulnerability information mainly via the following sources:

• Internal security tests and scans:

  • We conduct security scanning using multiple industry-standard products and tools on WSO2 infrastructure, services, and released WSO2 product versions as well as versions under development.

• The security mailing lists:

  • Any user who comes across security issues in WSO2 products and services is highly encouraged to report those issues via these channels. For further information please check WSO2 Security Vulnerability Reporting Guidelines.

• Customer Support Portal:

  • Users with a paid WSO2 subscription can report security issues via this channel.

• External security-related mailing lists, vendor security notifications and vulnerability databases.

Note

Follow the recommendations in WSO2 Security Vulnerability Reporting Guidelines before reporting a vulnerability to WSO2.

Note

We highly discourage sending automated scan reports via security mailing lists. The WSO2 Platform Security team does not put effort to evaluate such scan reports due to the high percentage of false positives that are inherent in automated security scanning. Therefore, report positive vulnerabilities with steps to reproduce as explained in the WSO2 Security Vulnerability Reporting Guidelines.

Severity Classification

We follow the Common Vulnerability Scoring System v3.1 to rate the vulnerabilities that are reported to us.

Given below is the WSO2 severity classification, and how it maps to the CVSS 3.1 scoring system:

Classification	CVSS Score
Critical	9.0 - 10.0
High	7.0 - 8.9
Medium	4.0 - 6.9
Low	3.9 or below

Resolution Timeframes

Given below are two examples of how timeframes are calculated:

1. A customer reports vulnerabilities found by an automated scan or a manual pen-test.

   In this case, the resolution timeframes change based on the severity of the vulnerability. WSO2 calculates these timeframes from the date that the vulnerability has been confirmed as a True Positive. For example:

   Classification	CVSS Score	Resolution Time (up to)
   Critical	9.0 - 10.0	7 days
   High	7.0 - 8.9	14 days
   Medium	4.0 - 6.9	30 days
   Low	3.9 or below	Next product release, or at the product team's discretion

   Note that once a fix is given to this customer, if other customers using the same product version, they can also get the same fix by using WSO2 Update Manager(WUM). WSO2 informs about security fixes to customers via a monthly announcement mailer. However, if it's a vulnerability with catastrophic implications, the fix is immediately announced to all customers.

2. A customer reports a security breach.

   WSO2 takes immediate action irrespective of the severity of the vulnerability.

Vulnerability Handling Process

Given below is the process of handling a security vulnerability notification:

1. The WSO2 team receives a notification about a security vulnerability, acknowledges it, and creates an internal ticket to track its progress.
2. The vulnerability is treated as the highest priority and directed to the respective product or services team.
3. The product or services team evaluates the vulnerability with help from the security champion of the product and the Platform Security team.
4. If the vulnerability does not pose a threat to the product or service, WSO2 responds with proper reasoning.
5. If the reported vulnerability is an actual threat, WSO2 responds by accepting the issue.
6. The product team provides a quick solution, if available. (E.g., a configuration change to disable some functionality). If not, the product team works to identify a fix.
7. If the reporter is a WSO2 customer, give a time estimation (ETA) to create the patch for a particular product version.
8. If the reporter is not a WSO2 customer, WSO2 does the following:
   1. Identify all the product versions that need to be fixed (See Back Port Policy for more information).
   2. Estimate the effort to patch all of them.
   3. Come up with a date to issue the fixes to the customers.
   4. Add a 1-month buffer to come up with the public announcement date.
   5. According to the responsible disclosure ethics of WSO2, inform the public announcement date for the issue reporter first. If the reporter agrees to make the vulnerability information public, then the information will be announced after the previously set public announcement date.
9. Initiate the patch creation process.
10. Create an internal identifier for the issue in the format WSO2-<year>-<ticket number>. For example, WSO2-2016-0010.
11. Create a Security Advisory for the vulnerability, informing its impact and the mitigation steps.
12. If the reporter is a customer of WSO2, the patch/update is provided to the reporter.
13. If the reporter is not a customer of WSO2, upon request by the reporter, WSO2 provides the source code diff so that the reporter can understand the fix and apply it. A public security advisory will be issued after all the patches are issued to the customers and the buffer period is exceeded.

Backport Policy

Security fixes are proactively backported to the product versions marked as Available and Deprecated in the WSO2 Support Matrix. These fixes are available to the customers through the WSO2 Update Manager.

Announcing to the Customers

Once the fix for a particular true positive vulnerability is identified and the security advisories are created for all the affected product versions that are within the backporting policy, they need to be shared with all WSO2 customers. This is done via a Customer Announcement that happens on the last working day of the month. However, if the vulnerability was reported by a customer, then the fix is given to that particular customer without waiting until the monthly announcement.

Announcing to the Public

Once the customer announcement is done, we give a buffer period of 4 weeks for customers to apply the patches. After the buffer period, the vulnerability is publicly announced on the Security Advisories page. The contents of the public security advisory depend on several factors:

• If the CVSS score of the issue is greater than or equal to 9.0 (CVSS >= 9), and the latest version of a WSO2 product is affected, a patch release of the particular product is done after all the patches are issued to the customers and the buffer period is exceeded. A public security advisory will be issued to inform about the issue and the availability of the patch release.
• If the CVSS score of the issue is less than 9.0 (CVSS < 9), and the latest version of a WSO2 product is affected, a public security advisory will be issued after all the patches are issued to the customers and the buffer period is exceeded. The public security advisory will contain information about any available risk mitigations and the pull-request information of the fix (relevant changes to public source code).
• If the latest version of any WSO2 product is not affected by the issue, public security advisory will be issued advising community users to update to the latest product version.

Tip

security-announce@wso2.org mailing list is used to announce security vulnerabilities in WSO2 products and services. If you wish to subscribe to this mailing list, please send an email to security-announce-request@wso2.org with the header subscribe.

Providing Acknowledgements

WSO2 appreciates the efforts of security researchers to identify security vulnerabilities in our products. We give credit to such researchers in the relevant security advisories listed on the Security Advisories page and also include them in a dedicated Security Hall of Fame page. The inclusion to either page is done upon the researcher's consent.

Tip

For more information on the acknowledgement process, see WSO2 Security Reward and Acknowledgement Program.

Analysis of Security Scan Reports

WSO2 accepts security scanning reports from our customers. Note that,

• Report(s) must be submitted through the WSO2 Support Portal.
• Should only contain WSO2 product or product dependency-related vulnerabilities (It should NOT contain vulnerabilities related to the operating system or other applications or configuration of infrastructure).
• Each report(s) submitted should only contain findings related to a single product version.

WSO2 currently supports reports exported from the following scanner formats:

Scanner Name	Supported Format
Aqua	json
JFrog (jfrogxray)	json
Trivy	json
Snyk	json
Dependency Check	xml
Veracode	xml
Blackduck	zip

If you are using a scanner other than what is listed above, you may convert the findings to the WSO2 Common Vulnerability Format and share them with us along with the original report.

Tip

Please note that we have included a sample sheet for your reference.