Page History
Version: 2.2 3 | Date: 19th Mar 202018th April 2022
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.
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 systems for future reference.
This document further explains, each individual phase of this overall process, carried out in order to produce secure software.
| Table of Contents |
|---|
Design Phase
New feature developments and modifications to the existing features must go through a thorough design review/s that evaluates the security aspects of the corresponding component.
The software architects and security leads of the respective product domains must attend these reviews. Following are some questions that are taken into consideration during these reviews.
- What are the interactions with other components in the system and how those interactions happen?
- What are the access and trust boundaries of the component?
- Who should be able to consume the functionalities exposed by the component?
- What level of authentication and authorization is required by the component, and what is the granularity of the permissions?
- What are the session management related requirements? E.g. is forgot password required?
- Are there configuration elements that includes confidential data? If so, how should they be protected?
- Are there confidential data stored in the database? If so, how should they be protected?
- Is the strength of cryptographic keys and algorithms to be used on par with the latest best practices?
- Is adequate amount of information being logged to understand a security related incident.
Development Phase
Developer Self-review
Before any code review, all the engineers must do a self code review. During development tasks and also during the self-code reviews, it is essential to follow the guidelines set forth by WSO2 Secure Engineering Guidelines.
Find Security Bugs Spotbugs plugin is recommended to be used in development environments.
Before sending any GItHub pull-requests (PR), developers must confirm the following workflow:
Relevant checks are further enforced by the GitHub pull-request template:
Code Reviews
Each new component must go through a set of code reviews. The participation of one or more security leads is a must for each code review. Once a code review is done, all the findings related to the security aspects must be resolved before merging the component into the code base.
WSO2 Secure Engineering Guidelines should be used as a guideline when reviewing the security aspect of the code.
There are two types of vulnerabilities that are taken into consideration during a code review.
Exploitable vulnerabilities
Security weaknesses / defence in depth issues
The exploitable vulnerabilities have a direct impact and provides an attacker more privileges than allowed. The second type is not directly exploitable and can be used in conjunction with exploitable vulnerabilities to aggravate the impact of an attack. Following lists out some of the most common vulnerabilities, introduced due to bad coding practices.
Cross-Site Scripting (XSS) attack
Cross-Site Request Forgery (CSRF)
HTTP Response Splitting (Header Injection)
SQL Injection
Following are some questions that are taken into consideration during these reviews.
Are all the entry points and trust boundaries identified by the design?
Is input validation being applied whenever input received from outside the current trust boundary?
Has all input validation applied in a allowlisting fashion which includes data types, formats, minimum/maximum lengths?
Does the application perform canonicalization of data prior to validating the inputs?
Does the application apply defense in depth to the input validation strategy?
All XML input validated against an agreed schema?
Is output that contains externally supplied input subjected to the correct type of encoding?
Do we log any confidential data?
Do we encrypt or allow encrypting any of the confidential data before being stored?
Can we encrypt any confidential data read from configuration files?
PreparedStatement is properly used whenever write to or read from a database?
Does the application store passwords and other confidential data in char[] and not as Strings?
Does the default values carry the most secure option?
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.
WSO2 uses the Trivy, Open-source image scanner for finding OS level vulnerabilities in WSO2 docker images.
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 are excluded from the static code analysis.
...
Overview
Content Tools
Activity