Proposal: add a "Secret and Certificate Management" sub-dimension

[jdsmithit]

Problem

The model currently has no coherent coverage of secret or certificate management. Secrets appear only as a single managing-secrets implementation reference pulled into an Infrastructure Hardening activity, there is nothing that measures whether secrets are kept out of code, centrally managed, rotated, short-lived, or eliminated. Certificate lifecycle (expiry, renewal, short-lived/mTLS) isn't represented at all, despite expired certificates being a leading cause of avoidable outages and short-lived certs / workload identity being where credential management is heading.

Proposal

Add a new Secret and Certificate Management sub-dimension under the Implementation dimension: a maturity ladder of 15 activities (levels 1–5) that treats certificates as a first-class thread alongside secrets.

L1 : No brainers: find secrets and detect them

• No plaintext secrets in source code
• Secret scanning of repositories

L2: don't hold the secret in the first place

• Prevention of secrets reaching the repository
• Encrypted (sealed) secrets in version control
• Secret delivery without human access

L3: centralize and control what must be stored

• Inventory of secrets and certificates
• Centralized secret management
• Access-controlled and audited secret access
• Dynamic and short-lived secrets estate-wide (incl. mTLS/SPIFFE)

L4 : automate and assure

• Platform-native federated workload identity adopt the mechanism)
• Automated secret rotation (incl. ACME/cert-manager renewal)
• Secret and certificate monitoring

L5: no standing secret material

• Elimination of long-lived static secrets
• Secretless and just-in-time credential brokering

#87

[wurstbrot]

Hi @jdsmithit ,

I feel the jump from L1 to L2 is too big. E.g. you could use encrypted (sealed) secrets on level 2 which are not centralized.

[wurstbrot]

I think that gitops needs to be covered. e.g. a developer is not having access to secrets.

tools like https://www.kubecost.com/kubernetes-devops-tools/kubernetes-external-secrets/ or https://sda-se.github.io/mongodb-operator/ might be useful for that.

[jdsmithit]

Okkk.... iv been thinking and i think this is a better way....

L1 : No brainers: keep secrets them out, detect them

• No plaintext secrets in source code
• Secret detection and prevention controls (scanning, pre-commit hooks, push protection)

L2: don't hold the secret in the first place

• Encrypted (sealed) secrets in version control
• Secret delivery without human access

L3: centralize and control what must be stored

• Inventory of secrets and certificates
• Centralized secret management
• Access-controlled and audited secret access
• Dynamic and short-lived secrets estate-wide (incl. mTLS/SPIFFE)

L4 : automate and assure

• Platform-native federated workload identity adopt the mechanism)
• Automated secret rotation (incl. ACME/cert-manager renewal)
• Secret and certificate monitoring

L5: no standing secret material

• Elimination of long-lived static secrets
• Secretless and just-in-time credential brokering

If we are happy with the overall direction ill draft the pr

[jdsmithit]

I think that gitops needs to be covered. e.g. a developer is not having access to secrets.

tools like https://www.kubecost.com/kubernetes-devops-tools/kubernetes-external-secrets/ or https://sda-se.github.io/mongodb-operator/ might be useful for that.

Covered with "Secret delivery without human access" Level 2 kept it generic but gitops/ESO and explained in the task,

[vbakke]

'Secret delivery without human access' as a level 2 I find hard to implement.

We evaluated HashiCorp vs Oracle OCI Vault. HashiCorp apparently takes a lot of effort to maintain properly by the DevOps team.

OCI Vault was also difficult to set up in a way that was dynamic enough for us, i.e some secrets were only for one app, other secrets were shared by a groups of apps, and some secretes were sort of wide area, with many apps requiring access to it.

Storing these in a way that stops human access is not easy. A developer can anyway just make the app fetch it and log it in a non-obvious way. And somewhere there is a key to access the store, since the app need the secret in clear text.

I hope I'm wrong. But if not, I think this is a harsh requirement for a level 2 activity, in my opinion. 🙂

[wurstbrot]

L1 needs to be easy, you have 2-3 activities in here:
Secret detection and prevention controls (scanning, pre-commit hooks, push protection)

Which one is the one you want? regular scanning, pre commit hook, push protection?
I feel regular scanning is easyer then effective push protection in most environments.

Push protection in bitbucket is very basic (not as good as gitleaks). Push protection is easy from a "who is responsible for the secret" view.
regular scanning is easy to perform but whom to report the findings to might be difficult to determine.
pre-commit hook can be disabled, therefore not level 1 from my point of view. But: Pre-commit hook is the only one preventing a secret to be commited. Notice: Commits can be reverted afterwards also

[wurstbrot]

@vbakke

'Secret delivery without human access' as a level 2 I find hard to implement. [...]

Vault is level 3 Centralized secret management in the proposal.

@jdsmithit
In K8S, a project team often has access to secrets in their controlled namespace (hopefully as less members as possible).
No access at all is difficult in level 2. No access outside of runtime (also during delivery) should be easy with sealed secrets or vault.

[jdsmithit]

The reason I put push protection at level 1 is that most SCM vendors now ship it as a server side switch, so it's not much work to turn on.

Quick rundown:

• GitHub (Cloud & Enterprise): Native UI toggles for secret scanning and push blocking out of the box.
• GitLab: GA (17.5+) native pre-receive blocking with instance-, group-, and project-level controls.
• Azure DevOps: Native toggle at the organization/project level via GHAS.
• Bitbucket DC: Native secret scanning, limited push enforcement varies by version.

But you're right, it's not that simple. The blocker isn't difficulty, it's licensing. GitHub private repos need Secret Protection (about $19 per committer a month), Azure DevOps has no free option at all, and GitLab needs Ultimate.

So in DSOMM terms it's knowledge 1, time 1, resources 3. Easy to do, might cost you.

I've split it like you suggested:

L1 Secret scanning: detective, works everywhere. I've put your point about findings needing a named owner straight into the measure.

L2 Prevention of secrets reaching the repository: server side enforcement, either native push protection or a pre-receive hook running
gitleaks. That way Bitbucket and ADO shops can still get there without paying.

Pre-commit is in there as defence in depth only, not the control, since it can be disabled.

Fine with L2 if that's what everyone thinks.

L1 : No brainers: find secrets and detect them

• No plaintext secrets in source code
• Secret scanning of repositories

L2: don't hold the secret in the first place

• Prevention of secrets reaching the repository
• Encrypted (sealed) secrets in version control
• Secret delivery without human access

L3: centralize and control what must be stored

• Inventory of secrets and certificates
• Centralized secret management
• Access-controlled and audited secret access
• Dynamic and short-lived secrets estate-wide (incl. mTLS/SPIFFE)

L4 : automate and assure

• Platform-native federated workload identity adopt the mechanism)
• Automated secret rotation (incl. ACME/cert-manager renewal)
• Secret and certificate monitoring

L5: no standing secret material

• Elimination of long-lived static secrets
• Secretless and just-in-time credential brokering