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 10 activities (levels 1–5) that treats certificates as a first-class thread alongside secrets.

L1: keep secrets out of code 'No brainers'

• No secrets in source code
• Secrets stored outside the codebase

L2: centralize and control

• Centralized secret management
• Access-controlled and audited secret access

L3: automate and assure

• Automated secret rotation (incl. automated certificate renewal — ACME/cert-manager)
• Secret-access monitoring and alerting
• Certificate and secret expiry alerting

L4: eliminate standing credential exposure

• Dynamic and short-lived secrets (incl. short-lived mTLS/SPIFFE certs)
• Elimination of long-lived static secrets

L5: secretless

• Secretless and just-in-time credential brokering

[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.