For our customers, SonarQube Cloud checks the boxes on features and performance - and now it's built to clear your security review too.
Encryption with Customer-managed keys (CMK), also known as Bring Your Own Key (BYOK) in SonarQube Cloud Enterprise is designed to achieve this: you can reap the benefits of our managed cloud service while retaining full ownership and control over the encryption keys protecting your source code at rest.
Why encryption with CMK matters for on‑premise customers considering the cloud
When we talk with self-managed customers who are hesitant to move to the cloud, we consistently hear three themes:
- Regulatory and internal policies often require that encryption keys for proprietary source code remain under the company’s direct control.
- Risk management and incident response processes assume security teams can rotate or revoke keys instantly, without depending on a vendor.
- Audit and compliance teams want a clear, documented answer to “Who can do what with which keys, and where?”
Historically, this pushed many security-conscious organizations to stay on-premise, even when they would prefer the agility, reduced operational burden, and faster innovation cadence of SonarQube Cloud.
Encryption with CMK changes this trade-off: you can store your code in SonarQube Cloud, but the keys that protect it stay in your AWS account, governed by your own policies and controls.
What is CMK in SonarQube Cloud
At a high level, encryption with CMK delivers three core benefits for Enterprise customers:
1. Encrypt your code at rest with your own AWS KMS key
SonarQube Cloud already encrypts source code at rest using built-in AWS encryption, regardless of plan. With CMK, you add an extra layer of protection by configuring a Customer Managed Key in AWS Key Management Service (KMS) under your own AWS account.
- Your source code is encrypted with keys under your control.
- Encryption is scoped at the enterprise level, covering all projects in your SonarQube Cloud Enterprise.
2. Meet strict compliance and data-ownership requirements
Many frameworks and internal policies mandate that:
- Encryption keys for sensitive intellectual property are managed and owned by the organization.
- Third-party services get the minimum rights necessary to use those keys.
Encryption with CMK is specifically designed around those expectations:
- You create and manage a symmetric CMK in your AWS KMS account, in the region matching your SonarQube Cloud instance.
- SonarQube Cloud gets only least-privilege permissions (such as
kms:GenerateDataKey,kms:Decrypt, andkms:ReEncrypt*) to use the key for encryption and decryption; it does not get administrative permissions over your key.
You stay in full control of who can administer, rotate, or revoke the CMK inside AWS KMS.
3. Control the key lifecycle and access to your code
Because the CMK lives in your AWS account, your security team can:
- Rotate keys on your schedule, to align with security best practices.
- Disable or revoke a key in case of an incident, blocking new KMS-backed decrypt operations.
This gives you a clean and powerful lever: if you don’t trust the environment anymore, you can use AWS KMS to cut off access to your data — without waiting on us to act.
How encryption with CMK works under the hood
Underneath, encryption with CMK uses a well-understood envelope encryption model with per‑project data keys. This provides strong security guarantees while keeping day‑to‑day performance smooth for developers.
1. Envelope encryption with AWS KMS
When you configure a CMK ARN in your SonarQube Cloud Enterprise settings, SonarQube Cloud uses that key through AWS KMS to protect project-specific data keys.
The flow looks like this:
- You create the CMK in AWS KMS
- In your AWS account (and region matching your SonarQube Cloud instance), you create a symmetric CMK in AWS KMS.
- You update the key policy with a statement that grants the SonarQube Cloud AWS account the rights it needs (
GenerateDataKey,Decrypt,ReEncrypt*, etc.).
- You configure the CMK in SonarQube Cloud Enterprise
- As an Enterprise Administrator, you go to Your Enterprise → Administration → Code Encryption and enter the CMK ARN.
- SonarQube Cloud generates per‑project Data Encryption Keys (DEKs)
- For each project, SonarQube Cloud requests a unique Data Encryption Key (DEK) from AWS KMS via the CMK.
- Using AES‑256, SonarQube Cloud encrypts your project’s source code with this DEK, this is the “inner” layer of envelope encryption.
- The DEK itself is then encrypted (“wrapped”) with your CMK and stored in SonarQube Cloud’s project configuration metadata.
- Decrypting when needed
- When SonarQube Cloud needs to read code (for example, to display analysis results), it decrypts it using the project DEK, served from a short-lived cache or, if the cache has expired, decrypted from its encrypted form via AWS KMS using your CMK.
- If your CMK is disabled or revoked, those decrypt operations fail, and SonarQube Cloud can no longer access the encrypted code.
Throughout this process, you manage the CMK; SonarQube Cloud only performs encryption and decryption operations via AWS KMS and does not get broad administrative control over your keys.
2. Performance and key‑caching
To avoid hitting AWS KMS on every single read operation, SonarQube Cloud caches unencrypted project data keys for a short time. Project DEKs are cached in plaintext for up to 5 minutes to accelerate encryption and decryption and reduce the reliance on AWS KMS calls.
This keeps the system responsive for developers browsing issues or analysis results, without compromising the overall control you retain through your CMK and AWS KMS configuration.
3. Rotating your CMK without re‑encrypting all code
Key rotation is a critical part of any mature key management strategy, but naively re‑encrypting terabytes of source code is not practical.
Envelope encryption allows rotation to be efficient:
- When you rotate the CMK, you provide a new key ARN in the Enterprise Code Encryption settings.
- SonarQube Cloud uses the new CMK to re‑encrypt existing and future DEKs; the source code itself is not re‑encrypted.
- During the rotation, both old and new CMKs must be enabled to ensure a smooth transition. After completion, you can disable the old CMK.
This design keeps rotation a fast, controlled operation while preserving strong security properties.
4. Incident response: revoking access to encrypted code
If a security incident occurs and you decide that access to code in SonarQube Cloud must be cut off:
- Your security team can go to AWS KMS, locate the CMK, and Disable it.
- Once disabled, AWS KMS will refuse decryption requests that use that key, which means SonarQube Cloud can no longer decrypt the stored code.
This gives you a clear and auditable control point fully inside your AWS account.
Why we designed encryption with CMK this way
Several design choices behind CMK are deliberate responses to what security and platform teams told us they need to see before approving a cloud move.
Least-privilege key model
We heard repeatedly that security teams are willing to let a SaaS use their keys, but only if:
- The SaaS does not become a key administrator.
- The SaaS has only the permissions strictly required for its function.
By relying on AWS KMS key policies and a least-privilege model (GenerateDataKey, Decrypt, ReEncrypt*, and related describe/grant actions), CMK ensures SonarQube Cloud can perform encryption and decryption, but cannot manage your keys, users, or broader KMS configuration.
Per‑project data keys and envelope encryption
Using unique DEKs per project with AES‑256 envelope encryption strikes a balance between security and operational efficiency:
- It limits blast radius: even if a DEK were somehow exposed, it would only apply to a single project.
- It enables fast key rotation: you can re-encrypt DEKs with a new CMK without touching the encrypted code itself.
- It’s built on well-established cryptographic patterns, aligning with security best practices and making it easier for your teams to review and approve.
Enterprise‑level configuration and permissions
Code encryption is configured at the Enterprise level and can only be managed by users with Administer Enterprise permission. This matches how large organizations structure responsibilities:
- Enterprise admins (often from a central platform or security team) own encryption strategy.
- Individual project or organization admins don’t have to manage keys directly.
- Governance and auditing become simpler, because there is a single, enterprise-wide point of control.
Ultimately, Customer Managed Keys are the bridge between the operational benefits of SonarQube Cloud and the risk posture your organization requires.
If you want to go deeper into configuration details, and operational procedures, you can find them in the official Code encryption documentation for SonarQube Cloud.
