Notifications
Clear all
Topic starter
20/08/2026 5:20 pm
TL;DR: Organizations can keep control of encryption keys for source code at rest while using a managed cloud service, as Sonar says SonarQube Cloud Enterprise now supports customer-managed keys with envelope encryption, per-project data keys, and the ability to rotate or disable keys from AWS KMS. Key ownership, revocation, and auditability become the real decision points, not just storage location.
NHIMG editorial — based on content published by Sonar: code encryption with customer-managed keys for SonarQube Cloud Enterprise
Questions worth separating out
Q: How should security teams govern customer-managed keys for SaaS code repositories?
A: Treat the key as a privileged control, not a checkbox.
Q: What breaks when a cloud service depends on provider-owned encryption keys?
A: The organisation loses direct revocation authority, which weakens incident response and complicates audit evidence.
Q: Why do customer-managed keys matter for source code security reviews?
A: Source code often contains business logic, security-sensitive implementation details, and sometimes embedded credentials.
Practitioner guidance
- Validate KMS key policy boundaries Confirm that the SaaS only has the minimum KMS actions required for GenerateDataKey, Decrypt, and ReEncrypt operations, and that no administrative permissions leak into the service trust path.
- Test key revocation as an incident control Exercise the full disablement path in AWS KMS so the team understands how quickly decrypt operations stop, how cached data keys behave, and what downstream workflows fail.
- Align rotation with access review ownership Assign named owners for CMK rotation, approval, and emergency revocation, then document the exact conditions under which the old key stays enabled during transition.
What's in the full article
Sonar's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step AWS KMS configuration guidance for enterprise administrators setting up the CMK.
- The exact permission model used for GenerateDataKey, Decrypt, and ReEncrypt operations.
- How the per-project DEK cache behaves during normal use and after key rotation.
- The documented disable-and-revoke workflow for incident response inside AWS KMS.
👉 Read Sonar's code encryption guidance for SonarQube Cloud Enterprise →
Customer-managed keys for source code: what changes for security teams?
Explore further
20/08/2026 6:12 pm
Customer-managed keys turn encryption into a governance control, not just a storage feature. The key point is that the organisation retains the authority to rotate and revoke the cryptographic root of trust. That changes the cloud approval conversation because the provider no longer sits inside the customer’s full trust boundary. For IAM and security teams, this is a model for how sensitive development platforms can be adopted without surrendering control over access decisions.
A question worth separating out:
Q: How do organisations decide whether CMK is worth the operational overhead?
A: Use it when the security requirement is not just encryption, but customer-controlled rotation, revocation, and evidence. If the cloud service must remain usable during normal operations but be cut off during an incident, CMK provides that lever. If no such governance requirement exists, the added complexity may not be justified.
👉 Read our full editorial: Customer-managed keys in SonarQube Cloud change code governance
