Customer-managed keys in SonarQube Cloud change code governance

At a glance

What this is: SonarQube Cloud Enterprise adds customer-managed keys so source code at rest stays encrypted under an organisation-controlled AWS KMS key.

Why it matters: For IAM and security teams, the control shift is less about cloud adoption and more about whether key ownership, rotation, and revocation remain inside the organisation's governance boundary.

👉 Read Sonar's code encryption guidance for SonarQube Cloud Enterprise

Context

Customer-managed keys change the governance model for encrypted code because the organisation, not the SaaS provider, retains administrative control over the cryptographic root of trust. That matters wherever source code is treated as sensitive intellectual property, especially when audit teams need clear answers about who can administer, rotate, or revoke access.

In practice, the architectural question is not whether a cloud service can encrypt data, but whether the customer can enforce its own key lifecycle and incident response decisions without vendor dependency. That is a familiar pattern in NHI governance too, where control over secrets and keys is often the difference between bounded access and persistent exposure.

Key questions

Q: How should security teams govern customer-managed keys for SaaS code repositories?

A: Treat the key as a privileged control, not a checkbox. Define who can create, rotate, disable, and audit the CMK, then verify the SaaS only holds least-privilege KMS permissions. The operating model should also include incident playbooks, change approval, and evidence collection so revocation is both technically effective and auditable.

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. If the provider controls the keys, customer policy may not be enough to stop decrypt operations quickly. That creates a governance gap where the data may be protected, but the customer cannot fully enforce its own control decisions.

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. Customer-managed keys let reviewers see that the organisation retains ownership of the cryptographic control plane, which is easier to defend in audits than relying entirely on a vendor-managed encryption boundary.

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.

Technical breakdown

Envelope encryption and per-project data keys

SonarQube Cloud Enterprise uses a standard envelope encryption pattern. The customer supplies a symmetric AWS KMS customer-managed key, and the service requests per-project data encryption keys to encrypt source code with AES-256. The data itself is encrypted with the DEK, while the DEK is wrapped by the CMK and stored as metadata. This limits exposure because the service does not need direct access to raw key material for every operation, and each project has its own encryption boundary.

Practical implication: map encryption scope to project boundaries so a single key decision does not create platform-wide exposure.

Key policy, least privilege, and administrative separation

The important control here is not just encryption, but key governance. SonarQube Cloud only receives the KMS permissions it needs for GenerateDataKey, Decrypt, and ReEncrypt actions, while the customer keeps authority over administration, rotation, and revocation. That separation matters because it prevents the SaaS from becoming a key administrator. It also gives security teams a clear audit trail for who approved the key, who can rotate it, and who can disable it during an incident.

Practical implication: review KMS policies as a privileged access boundary, not as a routine configuration item.

Key rotation and revocation without re-encrypting the world

Envelope encryption makes rotation operationally feasible because the CMK re-wraps the DEKs rather than forcing a full re-encryption of source code. SonarQube Cloud notes that rotation requires both old and new keys to remain enabled during transition, and that disabling the CMK later cuts off future decrypt operations. The short-lived DEK cache improves performance but also means revocation is not instantaneous in every cached session. The real control question is whether your incident runbook treats key disablement as a decisive containment step.

Practical implication: test key rotation and revocation in the same way you test access revocation for privileged identities.

NHI Mgmt Group analysis

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.

Key ownership is the real control plane for source code protection. Many programmes treat encryption as binary, but the decisive question is who can administer the key lifecycle. If the provider can only use least-privilege KMS permissions, then audit, incident response, and policy enforcement remain customer-led. That is especially relevant where source code may embed secrets, build logic, or security-critical implementation details.

Blast-radius control is the named concept this pattern reinforces. Per-project DEKs mean the encryption boundary is narrower than the platform boundary, so one exposure does not automatically become a full-environment compromise. That design aligns well with identity governance principles because access can be scoped, rotated, and revoked at the smallest useful unit. Practitioners should treat the key hierarchy as part of the access model, not as a separate cryptography topic.

Cloud adoption decisions increasingly depend on whether security teams can keep their own revocation authority. When organisations hesitate to move sensitive workloads to SaaS, the blocker is often not encryption itself but dependence on vendor-mediated remediation. A customer-controlled CMK gives teams a cleaner answer for audits and incident playbooks. The broader signal is that governance-ready cloud services will need customer-enforced control points, not just shared responsibility language.

What this signals

Key management is becoming part of identity governance because the control boundary now matters as much as the cryptographic algorithm. When a SaaS can use customer-held keys under least privilege, security teams gain a stronger argument for moving sensitive workloads without surrendering revocation authority. That is the same governance logic that underpins NHI lifecycle discipline and the need to keep control of credentials, keys, and service access inside an auditable boundary.

Code encryption and secrets governance are converging operationally. Source repositories, build systems, and runtime services now sit in the same risk conversation because the data path and the access path are linked. For practitioners, the practical signal is to align KMS ownership, access review, and secret lifecycle controls rather than managing them as isolated programmes.

For practitioners

• 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.
• Map code encryption to privileged access governance Treat CMK administration as a privileged function and fold it into access review, separation of duties, and audit evidence collection alongside other high-risk identity controls.

Key takeaways

• Customer-managed keys shift the question from whether code is encrypted to who controls the ability to decrypt it.
• The operational value is strongest when teams need rotation, revocation, and auditability without abandoning a managed cloud service.
• Security programmes should treat key administration as privileged governance, with clear ownership, testing, and incident controls.

Key terms

• Customer Managed Key: A key that an organisation creates and controls rather than using the cloud provider's default managed key. It gives the organisation more policy, audit, and custody control, but it also shifts responsibility for grants, rotation, and lifecycle governance onto the team that owns it.
• Envelope Encryption: A two-layer encryption pattern that uses a short-lived data encryption key to protect the data and a longer-lived key encryption key to wrap that data key. It scales rotation, supports tenant separation, and keeps the primary key material out of direct data handling.
• Content Encryption Key: A Content Encryption Key is the symmetric key used to encrypt the actual payload inside a JWE object. It is typically generated for a single token and then protected with the recipient’s key management method, which keeps the data encrypted while still enabling controlled decryption.
• Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.

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.

👉 Sonar's full article covers CMK setup, rotation behaviour, and AWS KMS revocation details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect key lifecycle controls to broader identity and access decisions across the programme.