Security Controls
Introduction
This document provides an overview of the security controls available in Citrix Secure Developer Spaces (SDS). It supports security assessments, risk evaluations, and third-party due diligence reviews.
The controls described in this document reflect the SDS security architecture, operational practices, and shared responsibility model as a customer-hosted solution. They are designed to align with enterprise security requirements and industry best practices.
Additional documentation and supporting evidence can be provided on request to address specific security, compliance, or audit requirements.
Security controls
| Security requirement | Security controls |
|---|---|
| Apply logging policy | SDS provides structured platform logging and real-time audit events. Platform logs capture application and service behavior to support operational troubleshooting, platform monitoring, and security investigations. The audit capability records security-relevant events, including authentication and session activity, user and workspace authorization actions, and data security events such as clipboard, upload, download, and monitored outbound network activity. These events are available on the SDS Audit page, where security teams can filter them by event type, severity, workspace, user, and date and time. This provides an operational audit trail for investigation and review. Platform audit events can also be exported in standard formats for downstream monitoring and SIEM integration. |
| Send logs to a Security Information and Event Management system | SDS supports Security Information and Event Management (SIEM) integration by writing security logs in Common Event Format (CEF) to the underlying host nodes. These logs can be collected and streamed to the corporate SIEM by configuring a standard log forwarder, such as Filebeat or Fluent Bit, to monitor the configured directory. For more information, see SIEM integration. |
| Establish detection use cases with the CSIRT | The SIEM integration supports filtering logs by severity threshold and event type. This allows the Cyber Security Incident Response Team (CSIRT) to create alerts for critical events, such as privilege changes or unauthorized access attempts. For more information, see Event categories and attributes. |
| Third-party due diligence | Citrix can provide standard third-party assurance documentation on request. Customers should specify the artifacts required for their review. |
| Security annex | A data flow diagram can be provided as part of the security annex when required for assessment or audit purposes. |
| Non-disclosure agreement | Non-disclosure agreements are covered as part of the global contractual framework with Citrix. |
| Application inventory | Citrix can provide an application and component inventory for the SDS platform on request. Customers should specify the required level of detail for their assessment. |
| Vulnerability management | Citrix continuously scans SDS source code and software dependencies for vulnerabilities. Security patches and minor updates are released periodically. |
| Single sign-on and multi-factor authentication | SDS supports enterprise single sign-on (SSO) through standards-based identity federation using SAML 2.0 or OpenID Connect (OIDC). Multi-factor authentication (MFA) can be enforced by the identity provider as part of the authentication flow. SDS also includes native MFA capabilities. |
| Access management | SDS includes built-in role-based access control (RBAC). Administrators can map application permissions to local user accounts or to directory groups synchronized from the identity provider. For more information, see Role-based access control. |
| Manage IT-level privileges | SDS separates infrastructure-level management from application-level administration. Because SDS is containerized and hosted on Kubernetes, the customer’s infrastructure team retains control over the underlying cluster, nodes, and container orchestration layer. Application-specific IT privileges, such as user management and configuration changes, are restricted to the application layer through granular RBAC. These privileges do not require direct access to the hosting infrastructure. |
| Encrypt data at rest | SDS is a customer-hosted solution. The customer is responsible for provisioning and managing the underlying database and persistent storage volumes. SDS is compatible with industry-standard encryption-at-rest technologies, including cloud-managed storage encryption, such as AWS KMS or Azure Key Vault, and encrypted Kubernetes Persistent Volumes (PVs). SDS also applies application-layer protection. When the external Vault feature is not enabled, developer secrets are encrypted in the database using AES-128 encryption. |
| Encrypt data in transit | SDS encrypts data in transit using secure protocols. External web traffic is enforced over HTTPS with TLS 1.2 or TLS 1.3. Secure terminal sessions use SSH. Within the Kubernetes cluster, traffic between the ingress controller and backend microservices is secured using mutual TLS (mTLS). This provides encryption and cryptographic identity verification for internal communication. |
| Manage certificates and certificate lifecycle | SDS relies on standard X.509 certificates for TLS encryption. For external traffic, SDS supports automated certificate lifecycle management tools, such as cert-manager, Let’s Encrypt, or internal PKI, to support certificate renewal without application downtime. For internal cluster traffic, SDS automatically manages the server and client certificates required to maintain mTLS between the ingress controller and backend microservices. |
| Apply backup policy | SDS separates stateless application logic from stateful data stores. Customers can apply standard snapshotting, database backup scripts, and backup retention policies to the underlying storage volumes. |
| Restrict network port usage to essential services | SDS operates with a minimal network footprint and exposes only the essential ports required for primary services, typically HTTPS over port 443 and SSH over port 22. SDS also supports Kubernetes Network Policies, allowing network security teams to isolate pod-to-pod communication within the cluster and restrict traffic to essential paths. |
| Provide architecture documentation | SDS architecture documentation is available in the product documentation. A data flow diagram can also be provided as an annex when required. For more information, see Architecture. |
| Hardening baseline | SDS uses a hardened container baseline. Core SDS service container images are built using Debian Distroless base images, which remove unnecessary packages, shells, and system utilities to minimize the exploitable attack surface. A dedicated Ubuntu-based image is used only where specific SDS workspace features require standard OS utilities. |
| Patch management | SDS deployments use standard container tags and package management mechanisms. Updates can be rolled out with minimal disruption, using approaches such as rolling updates or blue-green deployments, depending on the customer’s infrastructure configuration. |
| Protect exposed applications | SDS is designed to run behind the customer’s preferred web application firewalls (WAFs), reverse proxies, and API gateways. These controls can help filter malicious web traffic and protect against common web application risks, including OWASP Top 10 threats. |
| Segregate production and non-production environments | The SDS deployment model supports isolated instances. Customers can deploy separate clusters or servers for development, staging, and production environments using separate environment configurations. |
| Infrastructure and access | SDS is customer-hosted. Physical, operating system, and infrastructure-level access are controlled and managed by the customer. SDS does not require external inbound vendor connectivity to function. |
| Zero-trust data protection | SDS applies zero-trust principles across the application and network layers. At the application layer, every API call and data request requires explicit authentication and authorization. SDS verifies cryptographic tokens before granting data access. At the network layer, inbound traffic from the ingress controller to backend services is encrypted and authenticated through mTLS. Within the cluster, SDS supports Kubernetes Network Policies to isolate and restrict pod-to-pod communication so that only explicitly authorized microservices can exchange network traffic. |
| Identity and authentication | SDS supports SAML 2.0 and OIDC for SSO and MFA enforcement. SDS also supports System for Cross-domain Identity Management (SCIM) for automated user provisioning, deprovisioning, and identity lifecycle synchronization from a central identity provider. |
| Secrets management | SDS separates application and infrastructure secret handling. Application and developer secrets are managed at the application layer. By default, these secrets are encrypted before being written to the database using AES-128 encryption. SDS also supports integration with an external HashiCorp Vault instance. Secrets are injected securely into workspace runtimes through environment variables or volume-mounted configuration files. Infrastructure secrets, such as platform bootstrap credentials and database connections, use standard Kubernetes Secrets. Because SDS is customer-hosted, customers can add infrastructure-level protections, such as cloud provider KMS envelope encryption for etcd or a Secrets Store CSI Driver to inject infrastructure keys from an enterprise vault. |
| Container security | Core backend services use minimal Debian Distroless images to reduce the attack surface. Where specific workspace features require standard OS utilities, SDS uses dedicated Ubuntu images. Because SDS is customer-hosted, customers are responsible for implementing and operating runtime container scanning to validate images against corporate baselines. SDS is compatible with these scanning controls. |
| Network policies | SDS is containerized and requires a Kubernetes environment. It can be deployed in an isolated virtual private cloud (VPC) or subnet. SDS includes preconfigured Kubernetes Network Policies to restrict internal pod-to-pod communication. Customers can add or customize these policies to match their cluster security requirements. |
| Data loss prevention | SDS provides native controls that support a data loss prevention (DLP) strategy. Clipboard security can be enforced to prevent users from pasting content from the IDE or secure browser into external applications. Workspace app security can require workspace applications to open only in a secure browser, helping reduce data exfiltration risk when developers share internal apps. Outbound network policies can restrict workspace traffic to approved repositories and domains. Audit events provide visibility into monitored or blocked activity. Where remote development over SSH is enabled, DLP effectiveness might be reduced and should be governed by customer policy. |
| Governance and change management | SDS supports standard DevOps and GitOps deployment pipelines. Application configuration changes can be tracked through version control and infrastructure as code (IaC). Upgrades and configuration changes are documented in the release notes. For more information, see What’s new in Citrix Secure Developer Spaces. |
| Security stack on the Secure Developer Spaces platform | SDS deployment configurations, such as Helm charts or Kubernetes manifests, and delivered container images are compatible with validation through the customer security stack. Although proprietary source code is not provided, SDS supports automated infrastructure-as-code linting, configuration compliance checks, and container image vulnerability scanning, including software composition analysis (SCA), before deployment. |
Security Controls
Copied!
Failed!