Skip to main content
Deployment options: WSO2 Cloud, Self-hosted

Cloud Security Process

Version: 2.1

WSO2 cloud services operate under a DevSecOps process aligned with The Six Pillars of DevSecOps: Pragmatic Implementation from the Cloud Security Alliance: secure design, hardened build pipelines, continuous testing, governed delivery, runtime defense, and structured incident response. This page documents the tooling, controls, and engineering practices applied at each lifecycle stage; the CSA reference covers the conceptual framing.

Design and Architecture​

Continuous threat modeling drives the secure design phase.

  • Threat models are maintained alongside the system. Engineers update the model when introducing changes that may affect security posture; the Security Team uses the model to validate each change before it lands.
  • Customer-relevant findings are disclosed. Risks identified in cloud deployments, components, or features that are material to affected customers are communicated to those customers.

Coding​

Security controls and automated analysis are embedded in the coding stage.

  • Secure coding standards. Engineers follow the WSO2 Secure Coding Guidelines, which codify defensive coding practices, secure use of platform APIs, and consistent input handling across the codebase.
  • Container hardening. Build pipelines enforce hardened container images, and only hardened images are promoted to production. Enforced principles: least privilege, defense in depth, minimized attack surface, restricted blast radius, and separation of duties.
  • Software Composition Analysis (SCA). FOSSA scans cloud components and products for known vulnerabilities in third-party dependencies and surfaces license obligations alongside.
  • Static Application Security Testing (SAST). Veracode is the primary commercial scanner, complemented by open-source static analyzers tailored to each language and framework in the cloud portfolio.

Integration and Test​

Pre-production validation combines automated scanning, configuration testing, and human-led penetration testing.

  • Dynamic Application Security Testing (DAST). Invicti (formerly Netsparker) and Burp Suite probe deployed applications, services, and APIs for vulnerabilities observable from the outside.
  • Container and orchestrator testing. A dedicated test suite exercises container host and orchestrator configurations against the hardening baseline; this complements the build-pipeline controls and the runtime controls described below.
  • Internal penetration testing. WSO2's Security Team performs penetration tests and vulnerability assessments on a recurring cadence. Findings are routed to the responsible product teams for remediation, with severity-based service-level expectations.
  • Customer penetration testing. WSO2 Private Cloud customers may conduct penetration tests against their own environments under a formal authorization process. A request must be submitted covering testing scope, tools, source IP addresses, and other relevant details for approval. Approved tests proceed under WSO2's published terms; findings must be reported to WSO2 within 24 hours; testers operate under the terms of their agreement with WSO2 and must not introduce risk or impact to the service during the test window.

Delivery and Deployment​

Infrastructure and application deployments are governed as code, with continuous compliance enforcement.

  • GitOps. Infrastructure and application deployments are managed through Git; the repository is the source of truth for the deployment state and the audit trail for every change.
  • Policy guardrails. Azure Policies are integrated into the SDLC for compliance reporting and enforced auto-remediation.
  • Environment separation. Development, staging, and production environments are isolated and further segmented by function and trust boundary.
  • Secrets and key management. A centralized secret manager holds credentials, encryption keys, API keys, tokens, and cryptographic material; programmatic access is mediated by the platform.
  • Pipeline security. SAST, SCA, and container-image vulnerability scanning (operating system, application, and third-party dependency layers) gate every release. Kubernetes clusters are kept current with security patches per the shared-responsibility model.
  • System hardening. Hardening is applied across data, ports, components, functions, and permissions to reduce the attack surface of each deployment.

Runtime Defense and Monitoring​

Continuous posture management and security telemetry support detection and response.

  • Cloud Security Posture Management (CSPM). Microsoft Defender for Cloud (formerly Azure Defender for Cloud) continuously evaluates cloud resources against secure-configuration baselines, tracks WSO2's security and identity posture scores, and surfaces actionable risks.
  • Security operations. The WSO2 Security Operations Centre monitors applications, microservices, containers, security-event log analysis, hardware resources, and network transport, with detection and response playbooks for each signal class.

Incident Management​

WSO2 operates a documented cloud incident-management process: defined protocols, designated incident-response teams, severity-driven escalation, and stakeholder communication procedures. SaaS-specific customer notification commitments are documented separately. See Security Incident Notification Process for SaaS.

Risk Management​

Risks identified during threat modeling and at each SDLC stage are tracked and re-evaluated as development progresses. Risk management is integrated into engineering decision-making rather than executed as a separate review, ensuring that residual risk is visible to the teams making the decisions that produce it.

Vulnerability Management​

Periodic technical vulnerability assessments of cloud infrastructure run on a documented schedule with supporting automation, and platform-specific baseline security standards are maintained over time. The cross-product process (disclosure intake, triage, advisory publication, and customer communication) is documented in the Vulnerability Management Process.