tegwick
8ab4891043
Insert DevOps Secrets Management Canon v1.0 unchanged, with a placement preface that keeps shared roots upstream. Publish it on the federation card. Assistant: grok Assistant-Session: 01a12ce1-7ded-7e03-a845-2ece8a573af4
2165 lines
No EOL
59 KiB
Markdown
2165 lines
No EOL
59 KiB
Markdown
---
|
||
id: sec-dsm:DevOpsSecretsManagementStandard
|
||
title: SecurityCanon DevOps Secrets Management Standard
|
||
short_name: SEC-DSM
|
||
type: standard
|
||
standard_family: SecurityCanon
|
||
repository_context: security-canon
|
||
recommended_path: standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
|
||
status: stable
|
||
version: 1.0.0
|
||
canonical_owner: SecurityCanonDevOpsSecretsManagementStandard
|
||
namespace: sec-dsm
|
||
classification: standard
|
||
abstraction_layer: standard
|
||
primary_cluster: secrets-management
|
||
conformance_posture: normative
|
||
imports:
|
||
- InfoTechCanonCore
|
||
- InfoTechCanonAccessControlModel
|
||
- InfoTechCanonIdentityModel
|
||
- InfoTechCanonOrganizationModel
|
||
- sec-authority:ModeOfAuthority
|
||
related:
|
||
- sec-authority:ModeOfAuthority
|
||
- InfoTechCanonCaringAccessGovernanceStandard
|
||
owned_concepts:
|
||
- SecretsPreferenceHierarchy
|
||
- DynamicCredential
|
||
- ProducerCredential
|
||
- SecretsDecisionProcedure
|
||
- SecretsException
|
||
provenance:
|
||
source_file: DevOpsSecretsManagementCanon-v1.0.md
|
||
source_sha256: ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f
|
||
inserted: "2026-10-11"
|
||
insertion_decision: SECURITY-DEC-2026-004
|
||
---
|
||
|
||
# SecurityCanon DevOps Secrets Management Standard
|
||
|
||
**Short name:** `SEC-DSM`
|
||
**Document status:** Stable standard
|
||
**Version:** 1.0.0
|
||
**Repository context:** `security-canon`
|
||
**Document type:** SecurityCanon domain standard
|
||
**Conformance posture:** Normative (RFC 2119, as stated in the body)
|
||
|
||
## Position in SecurityCanon
|
||
|
||
This artifact is a Tier-3 standard. It states what a secrets-management practice must do. It does not operate custody, issue credentials, or render an authorization decision.
|
||
|
||
SecurityCanon owns the practice requirements in the body (`DSM-*`), the preference hierarchy, and the decision procedure. Shared roots stay where [SEC-ADR-001](../../../docs/adr-001-securitycanon-boundary.md) and [concept placement](../../interfaces/concept-placement.md) put them. Section 4 of the inserted text uses Principal, Secret, Credential, and Capability as working language for this practice. That use does not transfer ownership and does not redefine the upstream concept:
|
||
|
||
| Term in the body | How to read it here |
|
||
| --- | --- |
|
||
| Principal | The InfoTechCanon access-control Principal. This standard does not define a second one. |
|
||
| Authority | The InfoTechCanon organization-model Authority. Auth Mode qualifies how it is exercised. |
|
||
| Capability | The InfoTechCanon capability, used here as authority to perform an operation. Not a second Capability concept. |
|
||
| Scope | The InfoTechCanon identity-model Scope, when the body means a boundary. A credential's "scope" in the ordinary engineering sense is the authority it grants, and the body says so in place. |
|
||
| Secret, Credential | Practice terms for material whose disclosure grants or enables authority. No upstream artifact currently owns a competing definition. If one is later declared, this standard imports it. |
|
||
| Identity Assertion | Practice term for short-lived evidence of identity. Identity itself stays in InfoTechCanon. |
|
||
|
||
Estate application belongs to the consumers. Gate House teaches and supervises. secrets-engine materializes credentials. ops-mason builds routes. ops-warden operates lanes. A NetKingdom obligation that is stricter than this standard is the estate's to record. This standard is not edited to fit one estate.
|
||
|
||
The body below is the inserted source, unchanged. Provenance file `DevOpsSecretsManagementCanon-v1.0.md`, SHA-256 `ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f`, adopted by SECURITY-DEC-2026-004 on 2026-10-11.
|
||
|
||
---
|
||
|
||
# DevOps Secrets Management Canon
|
||
|
||
**Version:** 1.0
|
||
**Status:** Stable Canon
|
||
**Domain:** DevOps, Platform Engineering, Identity, Security, CI/CD, Runtime Operations
|
||
|
||
---
|
||
|
||
# 1. Purpose
|
||
|
||
The DevOps Secrets Management Canon defines a technology-independent model and normative practices for managing credentials, cryptographic material, workload authentication, and secret-bearing capabilities across software-development and production environments.
|
||
|
||
Its strategic objective is:
|
||
|
||
> **Reduce persistent secrets to governed exceptions and prefer identity-mediated, short-lived capabilities wherever possible.**
|
||
|
||
Secrets management is therefore not primarily a storage problem.
|
||
|
||
It is the discipline of controlling an authority lifecycle:
|
||
|
||
```text
|
||
avoid
|
||
↓
|
||
identify
|
||
↓
|
||
authorize
|
||
↓
|
||
issue
|
||
↓
|
||
deliver
|
||
↓
|
||
consume
|
||
↓
|
||
renew / rotate
|
||
↓
|
||
expire / revoke
|
||
↓
|
||
detect
|
||
↓
|
||
recover
|
||
↓
|
||
audit
|
||
```
|
||
|
||
The desired end state is not a better collection of passwords.
|
||
|
||
It is an environment in which principals authenticate through identity and receive narrowly scoped capabilities only for the time they require them.
|
||
|
||
When a target can authorize a principal directly through trustworthy native or federated identity, that direct path is generally preferable to introducing an additional secret or credential broker.
|
||
|
||
---
|
||
|
||
# 2. Normative Language
|
||
|
||
The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, **SHOULD NOT**, **MAY**, and **OPTIONAL** are to be interpreted according to BCP 14 / RFC 2119 and RFC 8174 when, and only when, they appear in uppercase.
|
||
|
||
A **MUST** expresses a requirement necessary for full conformance unless an explicitly governed exception exists.
|
||
|
||
A **SHOULD** expresses a strong recommendation that may be violated when the trade-off has been consciously evaluated and documented.
|
||
|
||
A **MAY** expresses a legitimate implementation choice.
|
||
|
||
---
|
||
|
||
# 3. Scope and Intended Audience
|
||
|
||
The canon applies to secrets and credential-like capabilities used by:
|
||
|
||
- humans;
|
||
- CI/CD pipelines;
|
||
- build systems;
|
||
- deployment systems;
|
||
- applications;
|
||
- containers;
|
||
- Kubernetes workloads;
|
||
- infrastructure automation;
|
||
- autonomous or semi-autonomous agents;
|
||
- service-to-service communication;
|
||
- databases;
|
||
- cloud providers;
|
||
- third-party APIs;
|
||
- signing systems;
|
||
- certificate authorities;
|
||
- recovery procedures.
|
||
|
||
The canon is primarily intended for **production environments and non-trivial engineering organizations**.
|
||
|
||
Smaller teams and early-stage systems SHOULD use the preference hierarchy, decision procedure, and Minimum Viable Adoption Profile without assuming they must immediately operate a full capability-broker architecture.
|
||
|
||
The canon describes a **direction of travel**, not a requirement to maximize architectural sophistication regardless of cost.
|
||
|
||
---
|
||
|
||
# 4. Core Concepts
|
||
|
||
## 4.1 Principal
|
||
|
||
A **Principal** is an entity that may be authenticated.
|
||
|
||
Examples include:
|
||
|
||
- human;
|
||
- CI job;
|
||
- Kubernetes workload;
|
||
- service;
|
||
- repository;
|
||
- deployment;
|
||
- build agent;
|
||
- autonomous agent.
|
||
|
||
Principals SHOULD have individual identities rather than inheriting shared credentials.
|
||
|
||
---
|
||
|
||
## 4.2 Identity Assertion
|
||
|
||
An **Identity Assertion** is short-lived evidence establishing the identity or relevant attributes of a principal.
|
||
|
||
Examples include:
|
||
|
||
- OIDC token;
|
||
- projected Kubernetes ServiceAccount token;
|
||
- SPIFFE SVID;
|
||
- cloud workload-identity assertion;
|
||
- hardware-backed human authentication.
|
||
|
||
An identity assertion is not equivalent to an ordinary application secret.
|
||
|
||
---
|
||
|
||
## 4.3 Secret
|
||
|
||
A **Secret** is information whose unauthorized disclosure grants, contributes to, or meaningfully enables authority not intended for the observer.
|
||
|
||
Examples include:
|
||
|
||
- password;
|
||
- API token;
|
||
- private key;
|
||
- symmetric encryption key;
|
||
- OAuth client secret.
|
||
|
||
---
|
||
|
||
## 4.4 Credential
|
||
|
||
A **Credential** is material presented to establish identity or exercise authority.
|
||
|
||
A credential MAY itself be secret.
|
||
|
||
Credentials may be:
|
||
|
||
```text
|
||
static
|
||
rotated
|
||
leased
|
||
ephemeral
|
||
derived
|
||
federated
|
||
```
|
||
|
||
---
|
||
|
||
## 4.5 Capability
|
||
|
||
A **Capability** is authority to perform a particular operation against a resource.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
read bucket X
|
||
write table Y
|
||
deploy service Z
|
||
sign artifact A
|
||
publish image B
|
||
```
|
||
|
||
A capability does not necessarily require possession of a persistent secret.
|
||
|
||
---
|
||
|
||
## 4.6 Dynamic Credential
|
||
|
||
A **Dynamic Credential** is generated on demand for a particular consumer or execution and possesses a defined lifetime.
|
||
|
||
Examples include:
|
||
|
||
- temporary database account;
|
||
- cloud STS credential;
|
||
- SSH certificate;
|
||
- short-lived X.509 certificate;
|
||
- temporary access token.
|
||
|
||
---
|
||
|
||
## 4.7 Producer Credential
|
||
|
||
A **Producer Credential** authorizes creation or issuance of other credentials.
|
||
|
||
Examples include:
|
||
|
||
- database administrator authority used by a broker to create temporary users;
|
||
- CA signing authority;
|
||
- cloud role capable of issuing temporary credentials.
|
||
|
||
Producer credentials are intrinsically high-value assets.
|
||
|
||
---
|
||
|
||
## 4.8 Secrets Authority
|
||
|
||
The **Secrets Authority** is the authoritative control plane responsible for one or more secret or credential lifecycles.
|
||
|
||
A Secrets Authority MAY:
|
||
|
||
- store secrets;
|
||
- issue credentials;
|
||
- broker capabilities;
|
||
- rotate credentials;
|
||
- revoke credentials;
|
||
- enforce policy;
|
||
- record audits.
|
||
|
||
---
|
||
|
||
## 4.9 Issuer
|
||
|
||
An **Issuer** creates a credential or identity assertion.
|
||
|
||
The issuer MAY differ from the Secrets Authority.
|
||
|
||
For example:
|
||
|
||
```text
|
||
Secrets Authority → requests database credential
|
||
Database → creates database principal
|
||
```
|
||
|
||
or:
|
||
|
||
```text
|
||
CI platform → issues OIDC assertion
|
||
Cloud STS → issues temporary cloud credential
|
||
```
|
||
|
||
---
|
||
|
||
## 4.10 Delivery Adapter
|
||
|
||
A **Delivery Adapter** transports secret material from an authority to a consumer.
|
||
|
||
Examples include:
|
||
|
||
- direct API;
|
||
- secrets agent;
|
||
- CSI driver;
|
||
- External Secrets Operator;
|
||
- temporary filesystem;
|
||
- injected environment variable.
|
||
|
||
A delivery adapter MUST NOT implicitly be considered the authoritative source of the secret.
|
||
|
||
---
|
||
|
||
## 4.11 Root of Trust
|
||
|
||
A **Root of Trust** is authority that cannot itself depend entirely upon the normal secrets-management hierarchy.
|
||
|
||
Examples include:
|
||
|
||
- HSM root key;
|
||
- root CA;
|
||
- recovery key;
|
||
- bootstrap key;
|
||
- platform-root authority.
|
||
|
||
Roots of trust SHOULD be few, explicit, and exceptionally protected.
|
||
|
||
---
|
||
|
||
## 4.12 Standing Authority
|
||
|
||
**Standing Authority** is authority available to a principal independently of an immediate task.
|
||
|
||
Examples include:
|
||
|
||
- long-lived API tokens;
|
||
- persistent administrative accounts;
|
||
- permanent cloud access keys;
|
||
- broad agent credentials.
|
||
|
||
Reducing standing authority is a primary objective of the canon.
|
||
|
||
The preference hierarchy, maturity model, and exposure model should all be interpreted partly as mechanisms for reducing standing authority.
|
||
|
||
---
|
||
|
||
# 5. Preference Hierarchy
|
||
|
||
Implementations SHOULD prefer mechanisms in the following order:
|
||
|
||
```text
|
||
1. Native identity with no transferable secret
|
||
2. Federated / workload identity
|
||
3. Ephemeral dynamically issued credential
|
||
4. Automatically rotated credential
|
||
5. Centrally managed static secret
|
||
6. Manually managed static secret
|
||
```
|
||
|
||
Moving downward SHOULD require increasing justification.
|
||
|
||
Moving upward generally reduces one or more of:
|
||
|
||
- standing authority;
|
||
- credential lifetime;
|
||
- credential replication;
|
||
- number of eligible consumers.
|
||
|
||
This hierarchy is not absolute.
|
||
|
||
The correct architecture is the **highest practical level that provides acceptable reliability, operational cost, compatibility, and security for the system concerned**.
|
||
|
||
---
|
||
|
||
# 6. Transitional and Constrained Environments
|
||
|
||
Not every target supports federation, dynamic credentials, or modern workload identity.
|
||
|
||
Typical constraints include:
|
||
|
||
- legacy databases;
|
||
- appliances;
|
||
- old protocols;
|
||
- third-party APIs exposing only static tokens;
|
||
- SaaS platforms with manually generated API keys;
|
||
- network devices;
|
||
- software that reads credentials only during startup;
|
||
- rate-limited or unavailable credential issuers.
|
||
|
||
The canon does not require constructing elaborate intermediary systems merely to simulate ephemeral credentials where doing so creates more operational risk than it removes.
|
||
|
||
## DSM-TRANS-001 — Highest Practical Mechanism
|
||
|
||
A system **SHOULD** use the highest mechanism in the preference hierarchy that the target and operating environment can reliably support.
|
||
|
||
## DSM-TRANS-002 — Govern the Residual Secret
|
||
|
||
When a static credential cannot reasonably be eliminated, it **MUST** receive:
|
||
|
||
- explicit ownership;
|
||
- central authoritative storage;
|
||
- minimum feasible scope;
|
||
- rotation policy;
|
||
- revocation procedure;
|
||
- inventory coverage;
|
||
- leak detection where practical.
|
||
|
||
## DSM-TRANS-003 — Do Not Fake Dynamism
|
||
|
||
A platform **SHOULD NOT** add complex credential issuance layers merely to claim dynamic-secret maturity when the resulting architecture increases failure probability without materially reducing authority, lifetime, or exposure.
|
||
|
||
## DSM-TRANS-004 — Record Elimination Potential
|
||
|
||
Persistent credentials **SHOULD** record whether elimination depends on:
|
||
|
||
- target-system modernization;
|
||
- vendor capability;
|
||
- protocol migration;
|
||
- platform work;
|
||
- contract change;
|
||
- application redesign.
|
||
|
||
This turns persistent secrets into visible engineering debt.
|
||
|
||
## DSM-TRANS-005 — Account for Issuer Dependency
|
||
|
||
Systems using dynamic credentials **MUST** consider failure of the credential issuer.
|
||
|
||
Relevant design concerns include:
|
||
|
||
- issuer availability;
|
||
- issuance latency;
|
||
- rate limits;
|
||
- lease renewal failure;
|
||
- clock skew;
|
||
- transient identity-provider failure;
|
||
- dependency during disaster recovery.
|
||
|
||
## DSM-TRANS-006 — Degraded Operation
|
||
|
||
Where continued operation during issuer outage is necessary, the system **SHOULD** define a deliberate degraded-operation strategy.
|
||
|
||
Examples include:
|
||
|
||
- use of an already valid lease until expiry;
|
||
- local credential-agent caching within bounded TTL;
|
||
- fail-closed behavior;
|
||
- tightly governed emergency credentials.
|
||
|
||
Indefinite caching **MUST NOT** silently convert ephemeral credentials into persistent credentials.
|
||
|
||
---
|
||
|
||
# 7. Fundamental Requirements
|
||
|
||
## DSM-ARCH-001 — Minimize Persistent Secrets
|
||
|
||
Systems **MUST** attempt to eliminate persistent credentials when equivalent authority can be provided using native or federated identity.
|
||
|
||
## DSM-ARCH-002 — Static Secrets Are Exceptions
|
||
|
||
Long-lived static credentials **MUST** be treated as managed exceptions rather than the preferred authentication mechanism.
|
||
|
||
Each material static production secret **MUST** have:
|
||
|
||
- owner;
|
||
- purpose;
|
||
- consumers;
|
||
- authority;
|
||
- rotation policy;
|
||
- revocation procedure.
|
||
|
||
## DSM-ARCH-003 — Separate Identity From Authority
|
||
|
||
Authentication and authorization **MUST** be treated as separate decisions.
|
||
|
||
Proof that a workload is `service-A` **MUST NOT** by itself imply unrestricted access to resources associated with `service-A`.
|
||
|
||
## DSM-ARCH-004 — Separate Control Plane From Delivery
|
||
|
||
The authoritative secrets-management system **SHOULD** be distinguishable from delivery mechanisms.
|
||
|
||
Kubernetes Secrets, CI variables, mounted files, and environment variables **SHOULD NOT** be considered canonical sources when another authoritative system exists.
|
||
|
||
## DSM-ARCH-005 — Optimize for Operability
|
||
|
||
Security architecture **MUST** account for availability and operational failure.
|
||
|
||
A theoretically stronger credential model **SHOULD NOT** be adopted without considering whether failures will cause teams to bypass it.
|
||
|
||
---
|
||
|
||
# 8. Developer Experience and Adoption
|
||
|
||
Security mechanisms that are difficult to use create incentives for unmanaged credentials.
|
||
|
||
The preferred mechanism SHOULD therefore also become the normal engineering path.
|
||
|
||
## DSM-DX-001 — Secure Path of Least Resistance
|
||
|
||
Platform teams **SHOULD** make the preferred identity and credential mechanism easier to adopt than unmanaged static secrets.
|
||
|
||
## DSM-DX-002 — Golden Paths
|
||
|
||
Organizations operating shared platforms **SHOULD** provide reusable integrations such as:
|
||
|
||
- CI templates;
|
||
- deployment templates;
|
||
- workload-identity modules;
|
||
- Terraform modules;
|
||
- Helm components;
|
||
- SDK helpers;
|
||
- secrets-policy templates.
|
||
|
||
## DSM-DX-003 — Self-Service
|
||
|
||
Routine credential and identity provisioning **SHOULD** be self-service where policy permits.
|
||
|
||
Security teams SHOULD NOT become a manual transport layer for ordinary application credentials.
|
||
|
||
## DSM-DX-004 — Local Development
|
||
|
||
The secrets architecture **SHOULD** define an explicit development workflow.
|
||
|
||
Local development SHOULD prefer:
|
||
|
||
- developer identity;
|
||
- development-only authority;
|
||
- temporary credentials;
|
||
- local emulation.
|
||
|
||
Production credentials SHOULD NOT be required for normal development.
|
||
|
||
### Non-normative implementation note
|
||
|
||
Where integration testing requires real external services, useful patterns include:
|
||
|
||
- developer-scoped cloud roles;
|
||
- short-lived developer credentials;
|
||
- isolated test tenants;
|
||
- sandbox APIs;
|
||
- contract testing;
|
||
- service emulation;
|
||
- explicitly time-bounded and audited exceptional production access for debugging.
|
||
|
||
Such mechanisms should preserve the separation between routine development and production authority.
|
||
|
||
## DSM-DX-005 — Debuggability
|
||
|
||
Identity and federation failures **SHOULD** be diagnosable without revealing secret values.
|
||
|
||
Useful diagnostics include:
|
||
|
||
- authenticated principal;
|
||
- token issuer;
|
||
- intended audience;
|
||
- policy decision;
|
||
- requested capability;
|
||
- denial reason;
|
||
- credential expiry.
|
||
|
||
## DSM-DX-006 — Avoid Security Escape Hatches Becoming Defaults
|
||
|
||
Break-glass tokens, personal access tokens, manually copied credentials, and similar compatibility paths **MUST NOT** become undocumented normal workflows.
|
||
|
||
---
|
||
|
||
# 9. Identity Practices
|
||
|
||
## DSM-ID-001 — Unique Workload Identity
|
||
|
||
Every security-relevant workload **SHOULD** possess its own identifiable runtime identity.
|
||
|
||
Production workloads **MUST NOT** depend upon a shared generic credential where individual workload identity is technically practical.
|
||
|
||
For systems claiming maturity level M3 or higher, unique workload identity is expected for applicable new production workloads unless an explicit exception exists.
|
||
|
||
## DSM-ID-002 — Federated Authentication
|
||
|
||
Workloads **SHOULD** authenticate using environmental or federated identity.
|
||
|
||
Preferred mechanisms include:
|
||
|
||
- OIDC;
|
||
- cloud workload identity;
|
||
- Kubernetes workload identity;
|
||
- SPIFFE;
|
||
- equivalent cryptographically verifiable identities.
|
||
|
||
For systems claiming maturity level M3 or higher, federation or an equivalent non-static identity mechanism is expected for new integrations where supported by the target.
|
||
|
||
## DSM-ID-003 — Eliminate Secret Zero
|
||
|
||
A workload **SHOULD NOT** require a long-lived bootstrap secret merely to authenticate to the secrets-management system.
|
||
|
||
## DSM-ID-004 — Human and Machine Identity Separation
|
||
|
||
Human credentials and workload credentials **MUST** be distinguishable.
|
||
|
||
Human credentials **MUST NOT** be embedded into automated workloads.
|
||
|
||
Machine credentials **SHOULD NOT** routinely be used interactively by humans.
|
||
|
||
---
|
||
|
||
# 10. Authorization Practices
|
||
|
||
## DSM-AUTH-001 — Least Authority
|
||
|
||
Credentials and capabilities **MUST** provide only the authority required for their intended operation.
|
||
|
||
## DSM-AUTH-002 — Contextual Scope
|
||
|
||
Where supported, authorization **SHOULD** constrain:
|
||
|
||
```text
|
||
principal
|
||
resource
|
||
operation
|
||
environment
|
||
time
|
||
```
|
||
|
||
Additional useful attributes include:
|
||
|
||
```text
|
||
repository
|
||
branch
|
||
namespace
|
||
deployment
|
||
tenant
|
||
runtime
|
||
job
|
||
commit
|
||
```
|
||
|
||
## DSM-AUTH-003 — Environment Isolation
|
||
|
||
Development, staging, and production authority **MUST** be independently scoped.
|
||
|
||
Compromise of a development credential **MUST NOT** inherently provide production authority.
|
||
|
||
## DSM-AUTH-004 — Tenant Isolation
|
||
|
||
Credentials crossing tenant security boundaries **MUST** be explicitly modeled and authorized.
|
||
|
||
Shared credentials between independent tenants **MUST NOT** be used.
|
||
|
||
---
|
||
|
||
# 11. Issuance Practices
|
||
|
||
## DSM-ISSUE-001 — Prefer Dynamic Issuance
|
||
|
||
When a target permits credentials to be issued dynamically, dynamic issuance **SHOULD** be preferred over retrieval of persistent credentials.
|
||
|
||
## DSM-ISSUE-002 — Shortest Practical Lifetime
|
||
|
||
Dynamically issued credentials **MUST** have a bounded lifetime.
|
||
|
||
TTL **SHOULD** approximate the expected duration of the task plus reasonable operational margin.
|
||
|
||
## DSM-ISSUE-003 — Per-Execution Credentials
|
||
|
||
Build jobs, deployment jobs, and autonomous-agent executions **SHOULD** receive credentials unique to the execution where supported.
|
||
|
||
## DSM-ISSUE-004 — Producer Credential Protection
|
||
|
||
Producer credentials **MUST** receive stronger protection than ordinary consumer credentials.
|
||
|
||
They **SHOULD** use, where practical:
|
||
|
||
- workload identity;
|
||
- hardware protection;
|
||
- automated rotation;
|
||
- constrained network access;
|
||
- highly restrictive policy.
|
||
|
||
---
|
||
|
||
# 12. Storage Practices
|
||
|
||
## DSM-STORE-001 — Authoritative Storage
|
||
|
||
Every persistent secret **MUST** have one identifiable authoritative source.
|
||
|
||
## DSM-STORE-002 — Minimize Copies
|
||
|
||
Secret replication **SHOULD** be minimized.
|
||
|
||
Each additional persisted copy SHOULD be regarded as increased exposure surface.
|
||
|
||
## DSM-STORE-003 — Encrypt at Rest
|
||
|
||
Persisted secrets **MUST** be cryptographically protected at rest.
|
||
|
||
Encryption keys **SHOULD** be governed independently from ordinary application access.
|
||
|
||
## DSM-STORE-004 — No Plaintext Source Control
|
||
|
||
Plaintext credentials **MUST NOT** be committed to version-control systems.
|
||
|
||
## DSM-STORE-005 — Git-Encrypted Secrets
|
||
|
||
Encrypted secrets **MAY** be stored in Git when declarative state provides a deliberate operational benefit.
|
||
|
||
Such storage:
|
||
|
||
- **MUST** use independently controlled encryption keys;
|
||
- **MUST** support key rotation;
|
||
- **SHOULD** restrict decryption to intended environments;
|
||
- **MUST NOT** be confused with dynamic secrets management.
|
||
|
||
---
|
||
|
||
# 13. Delivery Practices
|
||
|
||
## DSM-DELIV-001 — Prefer Direct Consumption
|
||
|
||
Consumers **SHOULD** obtain capabilities directly from their authority or issuer when practical.
|
||
|
||
## DSM-DELIV-002 — Minimize Persistence During Delivery
|
||
|
||
Credentials **SHOULD** remain resident for the minimum practical duration.
|
||
|
||
Preferred mechanisms include:
|
||
|
||
```text
|
||
memory
|
||
ephemeral filesystem
|
||
short-lived local agent
|
||
direct request
|
||
```
|
||
|
||
## DSM-DELIV-003 — Environment Variables
|
||
|
||
Environment variables containing high-value secrets **SHOULD** be avoided where safer delivery mechanisms exist.
|
||
|
||
They **MAY** be used for compatibility with software requiring them.
|
||
|
||
## DSM-DELIV-004 — Kubernetes Secret Replication
|
||
|
||
Replication into Kubernetes Secret objects **SHOULD** occur only when required by the consuming workload or ecosystem.
|
||
|
||
## DSM-DELIV-005 — Delivery Policy
|
||
|
||
Delivery adapters **MUST NOT** broaden authority beyond the policy of the authoritative system.
|
||
|
||
---
|
||
|
||
# 14. Rotation Practices
|
||
|
||
## DSM-ROT-001 — Rotation Policy
|
||
|
||
Every persistent production credential **MUST** have a rotation policy.
|
||
|
||
## DSM-ROT-002 — Automatic Rotation
|
||
|
||
Credentials that can reliably be rotated automatically **SHOULD** be rotated automatically.
|
||
|
||
## DSM-ROT-003 — Rotation Includes Adoption
|
||
|
||
Rotation **MUST NOT** be considered complete merely because the authoritative value changed.
|
||
|
||
Complete rotation consists of:
|
||
|
||
```text
|
||
issue
|
||
→ distribute
|
||
→ adopt
|
||
→ validate
|
||
→ revoke old
|
||
```
|
||
|
||
## DSM-ROT-004 — Zero/Low-Downtime Rotation
|
||
|
||
Systems requiring continuous availability **SHOULD** support overlapping validity, dual credentials, or equivalent safe transition mechanisms.
|
||
|
||
## DSM-ROT-005 — Dynamic Issuance Preferred
|
||
|
||
Where practical, dynamic issuance **SHOULD** replace periodic static-secret rotation.
|
||
|
||
---
|
||
|
||
# 15. Expiry and Revocation
|
||
|
||
## DSM-REV-001 — Bounded Validity
|
||
|
||
Temporary credentials **MUST** expire automatically.
|
||
|
||
## DSM-REV-002 — Explicit Revocation
|
||
|
||
Security-significant credentials **SHOULD** support explicit revocation in addition to expiry.
|
||
|
||
## DSM-REV-003 — Known Revocation Procedure
|
||
|
||
Every persistent production credential **MUST** have a known method of revocation.
|
||
|
||
## DSM-REV-004 — Compromise Response
|
||
|
||
A credential suspected of disclosure **MUST** be considered compromised.
|
||
|
||
Removing the exposed value from source code, logs, or configuration **MUST NOT** constitute sufficient remediation.
|
||
|
||
The credential **MUST** be revoked or replaced.
|
||
|
||
---
|
||
|
||
# 16. Detection Practices
|
||
|
||
## DSM-DETECT-001 — Secret Detection
|
||
|
||
Repositories containing production software **MUST** use automated secret detection.
|
||
|
||
## DSM-DETECT-002 — Layered Detection
|
||
|
||
Secret detection **SHOULD** occur at multiple boundaries where practical:
|
||
|
||
```text
|
||
developer environment
|
||
push
|
||
repository
|
||
CI pipeline
|
||
logs
|
||
artifacts
|
||
runtime
|
||
```
|
||
|
||
## DSM-DETECT-003 — Push Prevention
|
||
|
||
Organizations **SHOULD** prevent recognized credentials from entering source-control history where tooling can do so reliably.
|
||
|
||
## DSM-DETECT-004 — Detection-to-Revocation
|
||
|
||
Detection mechanisms **SHOULD** integrate with automated or semi-automated revocation procedures.
|
||
|
||
A finding without a response mechanism is incomplete control.
|
||
|
||
---
|
||
|
||
# 17. CI/CD Practices
|
||
|
||
## DSM-CI-001 — CI/CD Is Production Security Infrastructure
|
||
|
||
Any CI/CD system able to modify production **MUST** be treated as production-grade security infrastructure.
|
||
|
||
## DSM-CI-002 — OIDC/Federation
|
||
|
||
CI jobs **SHOULD** exchange short-lived execution identity for external capabilities rather than use stored infrastructure credentials.
|
||
|
||
This requirement is platform-independent and applies to systems such as GitLab CI, GitHub Actions, cloud-native build services, and other CI platforms capable of workload federation.
|
||
|
||
## DSM-CI-003 — Pipeline Change Authority
|
||
|
||
Authorization to modify security-relevant pipeline code **MUST** be considered capable of affecting the credentials obtainable through that pipeline.
|
||
|
||
## DSM-CI-004 — Secret Masking Is Not Protection
|
||
|
||
CI log masking **MUST NOT** be treated as sufficient protection of credentials.
|
||
|
||
## DSM-CI-005 — Job-Scoped Credentials
|
||
|
||
CI credentials **SHOULD** be scoped to individual jobs or executions and expire after execution completes.
|
||
|
||
---
|
||
|
||
# 18. Kubernetes Practices
|
||
|
||
## DSM-K8S-001 — ServiceAccount Identity
|
||
|
||
Kubernetes workloads **SHOULD** use workload identity rather than static application credentials wherever supported.
|
||
|
||
## DSM-K8S-002 — Projected ServiceAccount Tokens
|
||
|
||
Workloads requiring Kubernetes ServiceAccount tokens **SHOULD** use short-lived projected tokens obtained through the TokenRequest mechanism rather than legacy indefinitely valid ServiceAccount token Secrets.
|
||
|
||
Tokens **SHOULD** be:
|
||
|
||
- expiration-bound;
|
||
- audience-bound where supported;
|
||
- associated with the intended workload context.
|
||
|
||
## DSM-K8S-003 — External Authority
|
||
|
||
Kubernetes **SHOULD NOT** become the default authoritative store for organization-wide high-value secrets when a dedicated authority exists.
|
||
|
||
## DSM-K8S-004 — Native Cloud Identity Before Secret Brokerage
|
||
|
||
When the cloud platform can authorize a Kubernetes workload directly through native workload identity, that path **SHOULD** generally be preferred over routing the request through a secrets broker solely for credential issuance.
|
||
|
||
For example:
|
||
|
||
```text
|
||
Pod identity
|
||
↓
|
||
cloud workload federation
|
||
↓
|
||
cloud API
|
||
```
|
||
|
||
may be preferable to:
|
||
|
||
```text
|
||
Pod
|
||
↓
|
||
secrets authority
|
||
↓
|
||
temporary cloud credential
|
||
↓
|
||
cloud API
|
||
```
|
||
|
||
when both provide equivalent policy and audit guarantees.
|
||
|
||
## DSM-K8S-005 — External Secrets Operator
|
||
|
||
External Secrets Operator **MAY** be used as synchronization and reconciliation infrastructure.
|
||
|
||
Its use **MUST** deliberately define:
|
||
|
||
- refresh behavior;
|
||
- ownership;
|
||
- deletion semantics;
|
||
- target namespace;
|
||
- access scope.
|
||
|
||
## DSM-K8S-006 — Secrets Store CSI
|
||
|
||
Secrets Store CSI or equivalent runtime mounting **SHOULD** be considered when applications can consume file-mounted credentials.
|
||
|
||
Synchronization into Kubernetes Secret objects **SHOULD** remain disabled when unnecessary.
|
||
|
||
## DSM-K8S-007 — Namespace Isolation
|
||
|
||
Access to secret material **MUST** be scoped according to workload and namespace boundaries rather than assuming namespace membership alone implies authority.
|
||
|
||
---
|
||
|
||
# 19. Cryptographic Key Practices
|
||
|
||
Credentials and data-encryption keys are related but distinct security objects.
|
||
|
||
A typical envelope-encryption hierarchy may contain:
|
||
|
||
```text
|
||
KEK — Key Encryption Key
|
||
↓
|
||
DEK — Data Encryption Key
|
||
↓
|
||
encrypted application data
|
||
```
|
||
|
||
## DSM-KEY-001 — Non-Exportability
|
||
|
||
High-value root keys, signing keys, and KEKs **SHOULD** be non-exportable where the workflow permits it.
|
||
|
||
## DSM-KEY-002 — KMS/HSM
|
||
|
||
Root signing, encryption, wrapping, and similar high-value keys **SHOULD** use dedicated KMS or HSM facilities appropriate to their risk.
|
||
|
||
## DSM-KEY-003 — Cryptographic Operations Instead of Key Retrieval
|
||
|
||
Applications **SHOULD** request cryptographic operations from trusted services rather than retrieve master keys when practical.
|
||
|
||
For example:
|
||
|
||
```text
|
||
sign(data)
|
||
unwrap(DEK)
|
||
decrypt(small_payload)
|
||
```
|
||
|
||
is preferable to:
|
||
|
||
```text
|
||
get_root_private_key()
|
||
get_KEK()
|
||
```
|
||
|
||
## DSM-KEY-004 — Local Key Material
|
||
|
||
Applications **MAY** require temporary possession of key material such as DEKs when performing local high-volume encryption.
|
||
|
||
Such key material **SHOULD**:
|
||
|
||
- be narrowly scoped;
|
||
- have bounded lifetime where practical;
|
||
- avoid persistence;
|
||
- be wrapped by independently controlled KEKs.
|
||
|
||
## DSM-KEY-005 — Keyless Signing
|
||
|
||
Software build and artifact-signing workflows **SHOULD** prefer ephemeral or keyless signing schemes where ecosystem compatibility permits.
|
||
|
||
---
|
||
|
||
# 20. Human Handling
|
||
|
||
## DSM-HUM-001 — No Human Transport
|
||
|
||
Humans **SHOULD NOT** normally act as the transport mechanism for production secrets.
|
||
|
||
Examples include:
|
||
|
||
```text
|
||
password manager → CI variable
|
||
chat → terminal
|
||
ticket → Kubernetes Secret
|
||
vault UI → .env
|
||
```
|
||
|
||
## DSM-HUM-002 — Human Readability
|
||
|
||
Production credentials **SHOULD NOT** routinely require humans to view their plaintext value.
|
||
|
||
## DSM-HUM-003 — Break Glass
|
||
|
||
Emergency human access **MUST** use explicitly identified break-glass procedures.
|
||
|
||
Break-glass activity **MUST** be:
|
||
|
||
- exceptional;
|
||
- attributable;
|
||
- auditable;
|
||
- time-bounded where practical.
|
||
|
||
---
|
||
|
||
# 21. Agents and Automated Systems
|
||
|
||
## DSM-AGENT-001 — Agent Identity
|
||
|
||
Autonomous and semi-autonomous agents **MUST** authenticate using distinguishable workload identities.
|
||
|
||
## DSM-AGENT-002 — Per-Run Identity
|
||
|
||
Where practical, agent executions **SHOULD** receive execution-specific identity.
|
||
|
||
Agent identity **SHOULD** be distinguishable at least by:
|
||
|
||
```text
|
||
agent
|
||
run/task
|
||
environment
|
||
authority context
|
||
```
|
||
|
||
## DSM-AGENT-003 — Short Agent Identity Lifetime
|
||
|
||
Agent identity and derived capabilities **SHOULD** have short bounded lifetimes related to task execution.
|
||
|
||
Capabilities **SHOULD** expire or be revoked when the task:
|
||
|
||
- completes;
|
||
- fails;
|
||
- is cancelled;
|
||
- loses authorization.
|
||
|
||
## DSM-AGENT-004 — No Embedded Master Credential
|
||
|
||
Agents **MUST NOT** receive persistent platform-wide master credentials merely because their behavior is dynamic.
|
||
|
||
## DSM-AGENT-005 — Capability Brokerage
|
||
|
||
Agents **SHOULD** request narrowly scoped capabilities when required rather than maintaining broad standing authority.
|
||
|
||
## DSM-AGENT-006 — Deterministic Enforcement
|
||
|
||
Security boundaries controlling agent access to secret-bearing capabilities **MUST** use deterministic policy enforcement.
|
||
|
||
LLM reasoning **MUST NOT** constitute the sole authorization mechanism.
|
||
|
||
## DSM-AGENT-007 — Prevent Credential Accumulation
|
||
|
||
Agent frameworks **MUST NOT** silently accumulate credentials across tasks.
|
||
|
||
Credential caches, tool contexts, memory stores, workspaces, and execution sandboxes **SHOULD** be cleared or invalidated according to task lifecycle.
|
||
|
||
## DSM-AGENT-008 — Tool Authority Is Agent Authority
|
||
|
||
Authority reachable through an agent's tools **MUST** be included when evaluating the agent's effective security authority.
|
||
|
||
This includes intermediate tool and service credentials that the model itself cannot inspect or retrieve.
|
||
|
||
For example:
|
||
|
||
```text
|
||
agent
|
||
↓
|
||
tool A
|
||
↓
|
||
service B
|
||
↓
|
||
credential C
|
||
↓
|
||
system D
|
||
```
|
||
|
||
If use of tool A allows the agent to cause actions in system D through credential C, the resulting authority is part of the agent's effective authority.
|
||
|
||
A hidden credential is not outside the security boundary merely because the model never sees its bytes.
|
||
|
||
---
|
||
|
||
# 22. Audit and Observability
|
||
|
||
## DSM-AUDIT-001 — Audit Security-Relevant Operations
|
||
|
||
The secrets or capability authority **MUST** record applicable:
|
||
|
||
- authentication;
|
||
- authorization;
|
||
- retrieval;
|
||
- issuance;
|
||
- renewal;
|
||
- rotation;
|
||
- revocation;
|
||
- administrative changes.
|
||
|
||
## DSM-AUDIT-002 — Never Audit Plaintext Secrets
|
||
|
||
Audit records **MUST NOT** contain plaintext secret values.
|
||
|
||
## DSM-AUDIT-003 — Attribution
|
||
|
||
Audit records **SHOULD** identify:
|
||
|
||
```text
|
||
principal
|
||
resource
|
||
operation
|
||
policy context
|
||
time
|
||
result
|
||
execution identity
|
||
```
|
||
|
||
## DSM-AUDIT-004 — Audit Integrity
|
||
|
||
Security audit records **SHOULD** be protected from modification by systems and actors whose activity they record.
|
||
|
||
High-assurance environments **SHOULD** export audit evidence to an independent security domain.
|
||
|
||
## DSM-AUDIT-005 — Identity Failure Observability
|
||
|
||
Authentication and federation failures **SHOULD** emit sufficient structured telemetry to diagnose:
|
||
|
||
- issuer mismatch;
|
||
- audience mismatch;
|
||
- token expiration;
|
||
- policy denial;
|
||
- trust-chain failure;
|
||
- lease failure;
|
||
|
||
without disclosing credentials.
|
||
|
||
---
|
||
|
||
# 23. Roots of Trust and Recovery
|
||
|
||
## DSM-ROOT-001 — Enumerate Roots
|
||
|
||
Every deployment **MUST** identify its roots of trust.
|
||
|
||
Unknown roots constitute an architecture defect.
|
||
|
||
## DSM-ROOT-002 — Minimize Roots
|
||
|
||
The number of roots of trust **SHOULD** be minimized.
|
||
|
||
## DSM-ROOT-003 — Root Isolation
|
||
|
||
Root credentials **MUST NOT** be handled through ordinary application secret-delivery mechanisms unless the mechanism is explicitly designed for that assurance level.
|
||
|
||
## DSM-ROOT-004 — Recovery
|
||
|
||
Recovery procedures **MUST** be documented and periodically tested.
|
||
|
||
## DSM-ROOT-005 — Quorum for Extreme Authority
|
||
|
||
Where feasible, operations capable of compromising the entire secrets hierarchy **SHOULD** require multi-party authorization.
|
||
|
||
### Non-normative topology note
|
||
|
||
High-assurance multi-region, multi-account, or multi-cluster deployments should explicitly model:
|
||
|
||
- which roots are shared and which are independent;
|
||
- cross-region or cross-account trust relationships;
|
||
- issuer failure boundaries;
|
||
- disaster-recovery trust bootstrap;
|
||
- audit paths crossing administrative boundaries;
|
||
- whether compromise of one cluster or account can mint authority in another.
|
||
|
||
Replication should not accidentally turn one regional or cluster root into an undocumented global root.
|
||
|
||
Independent audit sinks can be especially important where the same administrative plane controls several trust domains.
|
||
|
||
---
|
||
|
||
# 24. Inventory and Discovery
|
||
|
||
## DSM-INV-001 — Secret Inventory
|
||
|
||
Organizations **MUST** maintain an inventory of security-significant persistent credentials.
|
||
|
||
## DSM-INV-002 — Inventory Attributes
|
||
|
||
An inventory entry **SHOULD** contain:
|
||
|
||
```yaml
|
||
id:
|
||
kind:
|
||
authority:
|
||
issuer:
|
||
owner:
|
||
consumers:
|
||
environment:
|
||
resources:
|
||
operations:
|
||
created_at:
|
||
expires_at:
|
||
rotation_policy:
|
||
revocation_method:
|
||
delivery_method:
|
||
classification:
|
||
maturity_level:
|
||
discovery_source:
|
||
verification_state:
|
||
```
|
||
|
||
## DSM-INV-003 — Ownership
|
||
|
||
Every material production credential **MUST** have an accountable owner.
|
||
|
||
## DSM-INV-004 — Automated Discovery
|
||
|
||
Inventory **SHOULD** combine declared information with automated discovery where practical.
|
||
|
||
Discovery sources MAY include:
|
||
|
||
- secrets authorities;
|
||
- CI variables;
|
||
- cloud IAM;
|
||
- Kubernetes;
|
||
- repositories;
|
||
- secret scanners;
|
||
- runtime telemetry;
|
||
- configuration systems.
|
||
|
||
## DSM-INV-005 — Evidence State
|
||
|
||
Inventory systems **SHOULD** distinguish between:
|
||
|
||
```text
|
||
declared
|
||
discovered
|
||
verified
|
||
inferred
|
||
unknown
|
||
```
|
||
|
||
information.
|
||
|
||
Discovery MUST NOT silently be treated as complete inventory.
|
||
|
||
## DSM-INV-006 — Discovered but Unowned
|
||
|
||
A discovered production credential without a known owner **MUST** be treated as a security finding.
|
||
|
||
It SHOULD be:
|
||
|
||
1. contained if necessary;
|
||
2. attributed;
|
||
3. assigned an owner;
|
||
4. revoked if no legitimate use is established.
|
||
|
||
## DSM-INV-007 — Orphan Detection
|
||
|
||
Secrets without known consumers **SHOULD** be investigated and revoked where legitimate use cannot be established.
|
||
|
||
---
|
||
|
||
# 25. Exception Management
|
||
|
||
## DSM-EXC-001 — Explicit Exceptions
|
||
|
||
Violation of a **MUST** requirement **MUST** be represented as an explicit exception.
|
||
|
||
## DSM-EXC-002 — Exception Record
|
||
|
||
An exception **MUST** record:
|
||
|
||
```text
|
||
requirement
|
||
affected system
|
||
reason
|
||
owner
|
||
risk
|
||
compensating controls
|
||
approval
|
||
review/expiry date
|
||
elimination path or review trigger
|
||
```
|
||
|
||
## DSM-EXC-003 — Exceptions Expire or Revalidate
|
||
|
||
Security exceptions **SHOULD** have an expiration date or mandatory revalidation trigger.
|
||
|
||
Permanent silent exceptions are prohibited.
|
||
|
||
## DSM-EXC-004 — Elimination Path
|
||
|
||
Where an exception represents technical debt, the record **SHOULD** state what event could remove it.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
vendor adds OIDC
|
||
legacy database upgraded
|
||
application migrated
|
||
protocol retired
|
||
new platform capability delivered
|
||
```
|
||
|
||
---
|
||
|
||
# 26. Anti-Pattern Catalogue
|
||
|
||
## DSM-AP-001 — Secrets in Git
|
||
|
||
Plaintext credentials committed to source control.
|
||
|
||
## DSM-AP-002 — CI Variable as Universal Vault
|
||
|
||
The CI system becomes the indefinite organization-wide credential database.
|
||
|
||
## DSM-AP-003 — Shared Production Account
|
||
|
||
Unrelated workloads share a single production identity.
|
||
|
||
## DSM-AP-004 — Vault Token Beside Application
|
||
|
||
A permanent vault token is distributed to workloads to obtain other secrets.
|
||
|
||
The secret-zero problem has merely moved.
|
||
|
||
## DSM-AP-005 — Eternal API Token
|
||
|
||
A third-party token has no owner, expiry expectation, rotation process, or revocation procedure.
|
||
|
||
## DSM-AP-006 — Kubernetes as Universal Vault
|
||
|
||
All organizational credentials are replicated into Kubernetes regardless of need.
|
||
|
||
## DSM-AP-007 — Human Rotation Ritual
|
||
|
||
Operators copy replacement credentials manually between multiple systems.
|
||
|
||
## DSM-AP-008 — Rotation Without Adoption
|
||
|
||
The authority changes the credential but consumers retain the previous value.
|
||
|
||
## DSM-AP-009 — Deleting the Leak
|
||
|
||
A credential is removed from Git or logs and considered trustworthy again without revocation.
|
||
|
||
## DSM-AP-010 — Secret Scanning Without Response
|
||
|
||
Secret detection creates findings but no response mechanism exists.
|
||
|
||
## DSM-AP-011 — Masked Means Safe
|
||
|
||
A credential is considered secure because CI log masking is enabled.
|
||
|
||
## DSM-AP-012 — Developer Production Secret
|
||
|
||
Developers routinely retain production credentials locally.
|
||
|
||
## DSM-AP-013 — Root Everywhere
|
||
|
||
The secrets broker uses broad producer authority where narrower delegation is practical.
|
||
|
||
## DSM-AP-014 — One Credential Per Environment
|
||
|
||
All workloads in an environment receive the same shared secret.
|
||
|
||
## DSM-AP-015 — Secrets Manager as Generic Database
|
||
|
||
The secrets platform becomes a generic configuration store, obscuring authority boundaries.
|
||
|
||
## DSM-AP-016 — LLM Gatekeeper
|
||
|
||
An LLM independently decides whether secret-bearing authority may be issued.
|
||
|
||
## DSM-AP-017 — Permanent Agent Authority
|
||
|
||
An autonomous agent receives broad standing credentials because future actions cannot be predicted.
|
||
|
||
## DSM-AP-018 — Dynamic at Any Cost
|
||
|
||
A complex dynamic-credential architecture is introduced despite low-value credentials, poor target support, severe reliability issues, and no meaningful reduction in standing authority.
|
||
|
||
## DSM-AP-019 — Undebuggable Federation
|
||
|
||
Identity failures are opaque, causing engineers to bypass workload identity using personal or static credentials.
|
||
|
||
## DSM-AP-020 — Hidden Credential Through Tooling
|
||
|
||
An agent, script, or platform appears credentialless while one of its tools or intermediate services exercises broad persistent credentials on its behalf.
|
||
|
||
---
|
||
|
||
# 27. Maturity Model
|
||
|
||
Maturity SHOULD be assessed independently for:
|
||
|
||
1. individual credentials;
|
||
2. applications;
|
||
3. platforms;
|
||
4. organizational portfolios.
|
||
|
||
An organizational maturity level **MUST NOT** conceal lower-level exceptions.
|
||
|
||
Maturity levels describe dominant architectural practice, not the complete absence of lower-level mechanisms.
|
||
|
||
---
|
||
|
||
## DSM-M0 — Scattered
|
||
|
||
Characteristics:
|
||
|
||
- credentials in source trees;
|
||
- local `.env` files;
|
||
- manually managed CI variables;
|
||
- shared accounts;
|
||
- unclear owners;
|
||
- inconsistent rotation.
|
||
|
||
M0 is non-conformant for security-significant production credentials.
|
||
|
||
---
|
||
|
||
## DSM-M1 — Vaulted
|
||
|
||
Characteristics:
|
||
|
||
- secrets centralized;
|
||
- encrypted at rest;
|
||
- authenticated access;
|
||
- basic access control;
|
||
- reduced plaintext distribution.
|
||
|
||
The organization has solved primarily **where secrets live**.
|
||
|
||
---
|
||
|
||
## DSM-M2 — Managed
|
||
|
||
Characteristics:
|
||
|
||
- documented lifecycle;
|
||
- rotation;
|
||
- secret detection;
|
||
- defined revocation;
|
||
- audit trails;
|
||
- break-glass procedures;
|
||
- orphan detection.
|
||
|
||
The organization manages **secrets as governed assets**.
|
||
|
||
---
|
||
|
||
## DSM-M3 — Federated
|
||
|
||
Characteristics:
|
||
|
||
- workload identity established;
|
||
- OIDC/workload federation common;
|
||
- secret-zero patterns reduced;
|
||
- human and machine identities separated;
|
||
- new compatible workloads normally receive distinct machine identity.
|
||
|
||
The organization increasingly manages **identities rather than passwords**.
|
||
|
||
---
|
||
|
||
## DSM-M4 — Ephemeral
|
||
|
||
Characteristics:
|
||
|
||
- dynamic database credentials;
|
||
- short-lived certificates;
|
||
- temporary cloud authorization;
|
||
- job-specific capabilities;
|
||
- automatic expiry;
|
||
- explicit leasing and revocation.
|
||
|
||
The organization manages **temporary authority**.
|
||
|
||
---
|
||
|
||
## DSM-M5 — Capability Brokered
|
||
|
||
Characteristics:
|
||
|
||
- standing credentials minimized;
|
||
- workloads request capabilities rather than bags of secrets;
|
||
- authorization uses identity and context;
|
||
- high-value keys remain non-exportable where practical;
|
||
- agents receive per-operation or per-task authority;
|
||
- root credentials are highly isolated.
|
||
|
||
The organization primarily manages **authority rather than secret material**.
|
||
|
||
---
|
||
|
||
# 28. Minimum Viable Adoption Profile
|
||
|
||
The maturity model describes architectural evolution.
|
||
|
||
It is not necessary to reach M3–M5 before gaining substantial security value.
|
||
|
||
A team beginning at M0/M1 SHOULD first establish the following baseline.
|
||
|
||
## DSM-CORE-1 — Minimum Viable Adoption
|
||
|
||
For security-significant production systems:
|
||
|
||
- no plaintext secrets in Git;
|
||
- one identifiable authority for each persistent secret;
|
||
- known owner;
|
||
- known consumers where practical;
|
||
- environment separation;
|
||
- defined revocation method;
|
||
- rotation policy;
|
||
- automated secret scanning;
|
||
- CI masking treated only as defense in depth;
|
||
- development credentials separated from production;
|
||
- explicit exceptions;
|
||
- workload federation preferred for new integrations when readily available.
|
||
|
||
This typically corresponds to a healthy **M2 trajectory**.
|
||
|
||
## DSM-CORE-2 — Next Best Investment
|
||
|
||
After DSM-CORE-1, teams SHOULD prioritize elimination of the credentials with the highest combination of:
|
||
|
||
```text
|
||
authority × lifetime × exposure × operational frequency
|
||
```
|
||
|
||
rather than attempting indiscriminate migration of every secret at once.
|
||
|
||
---
|
||
|
||
# 29. Measurement Model
|
||
|
||
Metrics SHOULD distinguish what can be measured directly from what requires cross-system inference.
|
||
|
||
## 29.1 Tier A — Authority-Native Metrics
|
||
|
||
Usually straightforward to instrument:
|
||
|
||
| Metric | Target |
|
||
|---|---:|
|
||
| Credentials with known owner | 100% |
|
||
| Credentials with expiry metadata | ↑ |
|
||
| Rotation success rate | → 100% |
|
||
| Credentials issued dynamically | ↑ |
|
||
| Credential TTL distribution | ↓ |
|
||
| Revocation events | observable |
|
||
| Failed issuance/renewal rate | low |
|
||
| Active leases | observable |
|
||
| Authentication failures | observable |
|
||
|
||
## 29.2 Tier B — Cross-System Inventory Metrics
|
||
|
||
Require correlation between several systems:
|
||
|
||
| Metric | Target |
|
||
|---|---:|
|
||
| Credentials with identified consumers | 100% |
|
||
| Shared production credentials | → 0 |
|
||
| Orphaned credentials | → 0 |
|
||
| Workloads using federation | ↑ |
|
||
| CI variables containing credentials | ↓ |
|
||
| Kubernetes Secret copies | ↓ where avoidable |
|
||
| Static-to-ephemeral ratio | ↓ |
|
||
|
||
## 29.3 Tier C — Exposure and Runtime Metrics
|
||
|
||
Often require advanced discovery or telemetry:
|
||
|
||
| Metric | Target |
|
||
|---|---:|
|
||
| Physical/logical copies per credential | ↓ |
|
||
| Effective standing authority | ↓ |
|
||
| Detection-to-revocation time | ↓ |
|
||
| Runtime credential exposure duration | ↓ |
|
||
| Unknown/unmanaged credential rate | → 0 |
|
||
|
||
Tier C metrics SHOULD carry an explicit **coverage or confidence indication**.
|
||
|
||
A metric based on 60% discovery coverage MUST NOT be presented as complete estate knowledge.
|
||
|
||
---
|
||
|
||
# 30. Exposure Model
|
||
|
||
A useful conceptual risk proxy is:
|
||
|
||
```text
|
||
Exposure Risk
|
||
∝
|
||
authority
|
||
× lifetime
|
||
× copies
|
||
× accessibility
|
||
```
|
||
|
||
Security controls therefore have four fundamental levers:
|
||
|
||
```text
|
||
reduce authority
|
||
reduce lifetime
|
||
reduce copies
|
||
reduce eligible access
|
||
```
|
||
|
||
Standing authority is a particularly important combination of the first two dimensions: significant authority that remains continuously available creates exposure even while it is not actively being used.
|
||
|
||
The preference hierarchy in Section 5 is valuable precisely because movement upward usually reduces several exposure dimensions simultaneously.
|
||
|
||
Replacing a shared permanent cloud key with federated job identity, for example, can simultaneously reduce:
|
||
|
||
- scope;
|
||
- lifetime;
|
||
- copies;
|
||
- number of eligible consumers;
|
||
- standing authority.
|
||
|
||
---
|
||
|
||
# 31. Tool Mapping
|
||
|
||
The canon deliberately does not prescribe individual products.
|
||
|
||
Tools occupy architectural roles.
|
||
|
||
| Tool / Class | Authority | Identity | Dynamic issuance | Rotation | Delivery | Detection | Crypto |
|
||
|---|---:|---:|---:|---:|---:|---:|---:|
|
||
| OpenBao | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
|
||
| HashiCorp Vault | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
|
||
| GitLab Secrets Manager | ✓ | GitLab-native | partial | ✓ | ✓ | GitLab ecosystem | — |
|
||
| CI OIDC issuers | — | ✓ | via federation | — | — | — | — |
|
||
| AWS Secrets Manager | ✓ | IAM | target-dependent | ✓ | ✓ | — | KMS |
|
||
| AWS STS | — | ✓ | ✓ | n/a | ✓ | — | — |
|
||
| GCP Secret Manager | ✓ | IAM/WIF | target-dependent | ✓ | ✓ | — | KMS |
|
||
| GCP Workload Identity | — | ✓ | ✓ | n/a | ✓ | — | — |
|
||
| Azure Key Vault | ✓ | Entra | target-dependent | ✓ | ✓ | — | ✓ |
|
||
| SPIFFE/SPIRE | — | ✓ | identity issuance | automatic | ✓ | — | PKI |
|
||
| External Secrets Operator | — | workload | — | sync | ✓ | — | — |
|
||
| Secrets Store CSI | — | workload | — | refresh | ✓ | — | — |
|
||
| SOPS + age/KMS | encrypted state | key identity | — | external | GitOps | — | ✓ |
|
||
| Sealed Secrets | encrypted state | cluster | — | limited | GitOps | — | ✓ |
|
||
| Sigstore/Cosign | — | OIDC | signing identity | n/a | — | transparency | ✓ |
|
||
| HSM/KMS | key authority | IAM | operations | ✓ | API | audit | ✓ |
|
||
| Infisical | ✓ | ✓ | ✓ | ✓ | ✓ | integrations | varies |
|
||
| Akeyless | ✓ | ✓ | ✓ | ✓ | ✓ | integrations | ✓ |
|
||
| Doppler | ✓ | ✓ | target-dependent | ✓ | ✓ | integrations | — |
|
||
| CyberArk | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | integrations |
|
||
|
||
Capability presence does not imply equivalent assurance, maturity, or suitability.
|
||
|
||
Tool capabilities also evolve independently of the canon. A tool mapping therefore SHOULD be treated as implementation guidance rather than a normative property of the canon.
|
||
|
||
---
|
||
|
||
# 32. Reference Architecture
|
||
|
||
A high-maturity implementation may resemble:
|
||
|
||
```text
|
||
┌───────────────────────┐
|
||
│ HUMAN IDENTITY │
|
||
│ SSO / MFA / Hardware │
|
||
└───────────┬───────────┘
|
||
│
|
||
▼
|
||
┌────────────────────────────────────────────────────┐
|
||
│ IDENTITY PLANE │
|
||
│ │
|
||
│ CI OIDC │ Kubernetes │ SPIFFE │ Cloud Workload ID │
|
||
└───────────────────────┬────────────────────────────┘
|
||
│ identity assertion
|
||
▼
|
||
┌────────────────────────────────────────────────────┐
|
||
│ POLICY / CAPABILITY CONTROL │
|
||
│ │
|
||
│ policy │ context │ least authority │ leases │
|
||
└───────────────────────┬────────────────────────────┘
|
||
│
|
||
┌─────────────┴─────────────┐
|
||
▼ ▼
|
||
┌──────────────────┐ ┌──────────────────────┐
|
||
│ SECRETS / CRED. │ │ NATIVE IDENTITY │
|
||
│ AUTHORITY │ │ TARGET │
|
||
│ │ │ │
|
||
│ KV / PKI / DB / │ │ Cloud IAM / API │
|
||
│ transit / lease │ │ accepting federation│
|
||
└────────┬─────────┘ └──────────────────────┘
|
||
│
|
||
▼
|
||
┌────────────────────────────────────────────────────┐
|
||
│ DELIVERY │
|
||
│ Direct API │ Agent │ CSI │ ESO │ ephemeral file │
|
||
└───────────────────────┬────────────────────────────┘
|
||
▼
|
||
┌────────────────────────────────────────────────────┐
|
||
│ CONSUMERS │
|
||
│ CI │ workloads │ services │ agents │ humans │
|
||
└────────────────────────────────────────────────────┘
|
||
|
||
|
||
┌───────────────────────┐
|
||
│ ROOT OF TRUST │
|
||
│ KMS │ HSM │ Root CA │
|
||
│ quorum/recovery │
|
||
└──────────┬────────────┘
|
||
│ protects / anchors
|
||
└──────────────► identity, policy and secret planes
|
||
|
||
|
||
All security-significant planes
|
||
│
|
||
▼
|
||
┌────────────────────────────────────────────────────┐
|
||
│ INDEPENDENT AUDIT / SECURITY TELEMETRY │
|
||
│ immutable or independently protected where needed │
|
||
└────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
The architecture explicitly permits two high-quality paths:
|
||
|
||
```text
|
||
identity → native target
|
||
```
|
||
|
||
and:
|
||
|
||
```text
|
||
identity → broker → issued capability → target
|
||
```
|
||
|
||
A broker SHOULD NOT be inserted merely because one exists.
|
||
|
||
In multi-region, multi-account, or multi-cluster environments, the boundaries between identity, authority, roots of trust, and independent audit SHOULD be modeled explicitly rather than assumed to be global.
|
||
|
||
---
|
||
|
||
# 33. CI Platform Mapping
|
||
|
||
The principles are CI-platform independent.
|
||
|
||
A modern CI environment SHOULD attempt:
|
||
|
||
```text
|
||
job
|
||
↓
|
||
short-lived CI identity
|
||
↓
|
||
OIDC / federation
|
||
↓
|
||
target policy
|
||
↓
|
||
temporary capability
|
||
```
|
||
|
||
This pattern applies to:
|
||
|
||
- GitLab CI;
|
||
- GitHub Actions;
|
||
- cloud build platforms;
|
||
- self-hosted CI systems supporting OIDC or equivalent federation.
|
||
|
||
Stored CI variables remain appropriate for compatibility cases, but SHOULD be treated as the lower part of the preference hierarchy rather than the architectural default.
|
||
|
||
---
|
||
|
||
# 34. GitLab-Oriented Mapping
|
||
|
||
GitLab SHOULD be used as appropriate as:
|
||
|
||
- CI workload-identity issuer;
|
||
- repository policy boundary;
|
||
- workflow and deployment authority;
|
||
- secret-detection surface;
|
||
- project/group secret authority where useful.
|
||
|
||
GitLab Secrets Manager MAY be useful for:
|
||
|
||
- project-level static secrets;
|
||
- group-level secrets;
|
||
- credentials tightly coupled to GitLab authorization;
|
||
- targets incapable of dynamic issuance.
|
||
|
||
GitLab CI variables SHOULD NOT become:
|
||
|
||
- the organization-wide vault;
|
||
- the default location for cloud master credentials;
|
||
- the normal bootstrap mechanism for external secrets systems.
|
||
|
||
GitLab OIDC SHOULD be preferred where supported for:
|
||
|
||
```text
|
||
GitLab → secrets authority
|
||
GitLab → cloud IAM
|
||
GitLab → deployment platform
|
||
GitLab → federated external service
|
||
```
|
||
|
||
---
|
||
|
||
# 35. OpenBao/Vault-Oriented Mapping
|
||
|
||
A general-purpose secrets authority can provide:
|
||
|
||
```text
|
||
Secrets Authority
|
||
Credential Broker
|
||
Dynamic Credential Issuance
|
||
PKI
|
||
Cryptographic Transit
|
||
Lease Management
|
||
Revocation
|
||
Audit Source
|
||
```
|
||
|
||
It SHOULD NOT automatically become the location for every item of sensitive configuration merely because it can store arbitrary values.
|
||
|
||
The desired pattern remains:
|
||
|
||
```text
|
||
identity
|
||
↓
|
||
policy
|
||
↓
|
||
specific capability
|
||
```
|
||
|
||
rather than:
|
||
|
||
```text
|
||
application
|
||
↓
|
||
large bag of persistent secrets
|
||
```
|
||
|
||
---
|
||
|
||
# 36. Kubernetes-Oriented Mapping
|
||
|
||
A preferred decision path is:
|
||
|
||
```text
|
||
Kubernetes workload
|
||
│
|
||
▼
|
||
projected workload identity
|
||
│
|
||
├──────────────► cloud/native federation ──► target
|
||
│
|
||
└──────────────► secrets authority
|
||
│
|
||
├── dynamic credential
|
||
└── required static secret
|
||
│
|
||
┌─────┴─────┐
|
||
▼ ▼
|
||
direct/CSI ESO
|
||
│
|
||
▼
|
||
Kubernetes Secret
|
||
```
|
||
|
||
The **shortest trustworthy path** SHOULD generally be preferred.
|
||
|
||
---
|
||
|
||
# 37. Decision Procedure
|
||
|
||
Whenever a new credential is proposed, the designer SHOULD answer the following questions in order.
|
||
|
||
### Q1 — Can the operation use identity directly?
|
||
|
||
If yes:
|
||
|
||
**do not create a secret.**
|
||
|
||
### Q2 — Can the target accept federated identity?
|
||
|
||
If yes:
|
||
|
||
**federate.**
|
||
|
||
### Q3 — Can the target issue an ephemeral credential?
|
||
|
||
If yes and operationally viable:
|
||
|
||
**issue dynamically.**
|
||
|
||
### Q4 — Can an existing static credential be automatically rotated?
|
||
|
||
If yes:
|
||
|
||
**manage and rotate it centrally.**
|
||
|
||
### Q5 — Must a persistent static credential exist?
|
||
|
||
If yes:
|
||
|
||
**vault it and manage it explicitly.**
|
||
|
||
Then determine:
|
||
|
||
```text
|
||
Who owns it?
|
||
Who consumes it?
|
||
What authority does it grant?
|
||
How is it delivered?
|
||
How many known copies exist?
|
||
How is it rotated?
|
||
How is it revoked?
|
||
How is leakage detected?
|
||
How is use audited?
|
||
What happens if the issuer is unavailable?
|
||
When could this credential be eliminated?
|
||
```
|
||
|
||
This decision procedure is the minimum conceptual implementation of the canon.
|
||
|
||
---
|
||
|
||
# 38. Conformance
|
||
|
||
A system is **Fully Canon Conformant** when:
|
||
|
||
1. all applicable **MUST** requirements are satisfied; or
|
||
2. violations exist only as explicit DSM-EXC exceptions.
|
||
|
||
A declaration SHOULD take the form:
|
||
|
||
```text
|
||
DevOps Secrets Management Canon v1.0
|
||
|
||
System: payment-platform
|
||
Adoption Profile: Full
|
||
Maturity: DSM-M4
|
||
|
||
Discovery Coverage:
|
||
declared/inventory: 100%
|
||
automated-discovery estimate: 87%
|
||
runtime-discovery estimate: 65%
|
||
|
||
Exceptions:
|
||
- EXC-042 legacy-bank-api-token
|
||
- EXC-057 vendor-sftp-password
|
||
```
|
||
|
||
Discovery coverage SHOULD be included when materially incomplete discovery could affect the credibility of a maturity claim.
|
||
|
||
Teams not yet ready for full conformance MAY instead declare:
|
||
|
||
```text
|
||
Adoption Profile: DSM-CORE-1
|
||
```
|
||
|
||
provided this is not represented as full canon conformance.
|
||
|
||
---
|
||
|
||
# 39. Portfolio Conformance
|
||
|
||
Organizations SHOULD NOT claim a single maturity level without describing the distribution of authorities or credentials.
|
||
|
||
A preferred representation is:
|
||
|
||
```text
|
||
M0 0%
|
||
M1 4%
|
||
M2 11%
|
||
M3 27%
|
||
M4 46%
|
||
M5 12%
|
||
```
|
||
|
||
The distribution SHOULD ideally distinguish important credential classes.
|
||
|
||
For example:
|
||
|
||
```text
|
||
Cloud workloads M4
|
||
Database access M4
|
||
Third-party SaaS M2
|
||
Legacy appliances M1
|
||
CI identity M3
|
||
Signing M5
|
||
```
|
||
|
||
Portfolio declarations SHOULD state material discovery limitations.
|
||
|
||
For example:
|
||
|
||
```text
|
||
Coverage:
|
||
managed authorities 98%
|
||
CI systems 100%
|
||
Kubernetes clusters 95%
|
||
third-party SaaS 70%
|
||
developer-held material unknown
|
||
```
|
||
|
||
A maturity declaration describes what is known about the estate; it MUST NOT imply that unknown areas have been proven free of unmanaged credentials.
|
||
|
||
---
|
||
|
||
# 40. Non-Normative Framework Alignment
|
||
|
||
This section is informational and does not establish compliance.
|
||
|
||
The canon is broadly compatible with the direction of established security frameworks.
|
||
|
||
## Zero Trust
|
||
|
||
The strongest alignment is with zero-trust architecture principles:
|
||
|
||
- authenticate explicitly;
|
||
- authorize per request;
|
||
- minimize implicit trust;
|
||
- limit standing privilege;
|
||
- use contextual policy;
|
||
- prefer short-lived credentials.
|
||
|
||
The M3–M5 progression can be seen as increasingly complete application of these ideas to machine and workload authority.
|
||
|
||
## NIST Cybersecurity Framework
|
||
|
||
Relevant themes include:
|
||
|
||
- asset and identity awareness;
|
||
- access control;
|
||
- credential protection;
|
||
- continuous monitoring;
|
||
- detection;
|
||
- incident response;
|
||
- recovery.
|
||
|
||
The canon adds a more specific credential-lifecycle and workload-identity model beneath those higher-level outcomes.
|
||
|
||
## NIST SP 800-53
|
||
|
||
The canon overlaps especially with control families concerned with:
|
||
|
||
- access control;
|
||
- identification and authentication;
|
||
- audit and accountability;
|
||
- configuration management;
|
||
- system and communications protection;
|
||
- incident response.
|
||
|
||
It should not be treated as a replacement for an SP 800-53 control assessment.
|
||
|
||
## ISO/IEC 27001
|
||
|
||
Relevant areas include:
|
||
|
||
- identity management;
|
||
- authentication information;
|
||
- access rights;
|
||
- privileged access;
|
||
- cryptography;
|
||
- logging;
|
||
- secure development;
|
||
- configuration management;
|
||
- incident management.
|
||
|
||
The canon can provide an implementation-oriented secrets-management submodel beneath an ISO 27001 ISMS.
|
||
|
||
## Compliance Principle
|
||
|
||
Compliance frameworks tend to ask:
|
||
|
||
> Is credential risk controlled?
|
||
|
||
The canon additionally asks:
|
||
|
||
> Why does this credential exist at all?
|
||
|
||
That second question is what drives movement from M2 toward M3–M5.
|
||
|
||
---
|
||
|
||
# 41. Governing Principles
|
||
|
||
The central design principle of this canon is:
|
||
|
||
> **A persistent secret represents deferred identity or capability engineering.**
|
||
|
||
Sometimes that debt is rational.
|
||
|
||
Legacy systems exist. Third-party APIs expose fixed tokens. Recovery authorities cannot always be eliminated. Dynamic issuance can introduce real dependencies and operational cost.
|
||
|
||
The canon therefore does not demand maximal machinery.
|
||
|
||
Instead, every persistent secret should provoke these questions:
|
||
|
||
> Why must this authority exist as a credential?
|
||
> Why must the credential persist?
|
||
> Why must its value be readable?
|
||
> Why must it be copied?
|
||
> Why must more than one principal possess it?
|
||
> What prevents us from moving it one level upward in the preference hierarchy?
|
||
|
||
The desired long-term trajectory is:
|
||
|
||
```text
|
||
secret storage
|
||
↓
|
||
secret lifecycle management
|
||
↓
|
||
workload identity
|
||
↓
|
||
ephemeral credentials
|
||
↓
|
||
capability brokerage
|
||
```
|
||
|
||
But the operational rule is:
|
||
|
||
> **Move authority upward only when the resulting system is both more secure and sustainably operable.**
|
||
|
||
The end state of mature secrets management is not the elimination of every secret.
|
||
|
||
It is the transition from managing secret material to:
|
||
|
||
> **managing explicit, bounded, observable authority.** |