WSO2 Secure Software Development Process

Security is not an afterthought at WSO2. It's an integral part of each phase in the development life cycle. This makes sure security vulnerabilities are identified and mitigated as early as possible.

Open

WSO2 Secure Engineering Guidelines provide the overall security guidance during design, development and code review phases. A group of security leads review designs of new features and also review the code to make sure that engineers are adhering to the guidelines set forth. Some security checks are further enforced when engineers commit the code to the WOS2 maintained code repositories. 

Furthermore, before a product release, there are mandatory security scans that look at the security of the release candidate in different perspectives. All the security findings are securely stored into a centralized system for future reference. 

This document further explains, each individual phase of this overall process, carried out in order to produce secure software.

Release Process

A release candidate goes through three types of security checks, to make sure that the product is in a secure state.

Static Code Analysis

Static Code Analysis is used to identify possible vulnerabilities within source code, by using techniques such as Taint Analysis and Data Flow Analysis.

Apart from the Find Security Bugs Spotbugs plugin which is used at the development phase, WSO2 uses Veracode commercial static analyzer for this purpose.

Please note that the security issues relevant to the third-party dependencies are covered separately with the Third Party Dependency Analysis effort. Therefore, the source code of the third-party dependencies is excluded from the static code analysis.

Dynamic Analysis 

Dynamic Analysis is used to searching for software vulnerabilities when the code is in operation mode. The analysis is performed when the application is running.

WSO2 uses Qualys Web Application Scanner (Qualys WAS) for dynamic security scanning.

Third Party Dependency Analysis

Security vulnerabilities identified in the third-party dependencies may affect the security of the product. WSO2 prevent such security impacts that could occur due to third party dependencies at few stages.  

It is essential to make sure third party dependencies with known security vulnerabilities are not introduced newly. Therefore, with any "third party dependency approval request," it is essential to attach OWASP Dependency Check report, adhering to the "Introducing New External Dependencies" section of the "WSO2 Secure Coding Guidelines". 

New security vulnerabilities related third party dependencies may get identified and fixed in any given time. Therefore, it is essential to continuously monitor different sources to identify if a new vulnerability has been identified or fixed. 

WSO2 uses OWASP Dependency Track for this purpose with product versions released after Q1 2020. The National Vulnerability Database (NVD) is queries for third-party dependency issues and alerts will be generated if a new issue has been identified. It is required to update the dependency or add a mitigation comment explaining why the relevant vulnerability is not application to the product.

Mandatory checks during releases

Open

To request a security scan (Veracode, Qualys or Dependency Track), product teams create a JIRA in the internal security JIRA project, attach the related product pack, and send an email notification to security-leads-group@wso2.com, with a reference to the corresponding JIRA. 

Even though security scans can be scheduled at any time, based on the requests from the product teams, it is mandatory to perform all three scan types (static scan, dynamic scan, third-party dependency scan) before a product release. This involves:

• Get the version to be released scanned using the scanner. 

• Prepare feedback report for any "false positive", "not a threat", "not applicable" or "already mitigated" findings. The feedback should include:

  • Comment on why the issue is categorized as such.

  • Details about the use case of the relevant logic.

  • Details about the impact of the reported issue. 

• Fix all "true positive" issues identified.

• Rescan the product before the release vote, if complex changes have occurred between the initial security scan and the actual release vote, preventing manual verification of security fixes.

If any of the aforementioned items are not complete, Platform Security Team will down vote the release, preventing the product from getting released.