Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Given below is the WSO2 severity classification, and how it maps to the CVSS 3.0 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 product team's discretion


    Note that once a fix is given to this customer, if there are 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 immediate 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. 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 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 back with proper reasoning.

  5. If the reported vulnerability is an actual threat, WSO2 responds back, 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 Porting 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 WSO2's responsible disclosure ethics, inform the public announcement date to the issue reporter first. If the reporter agrees to making 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.

...