coulomb/ops-mason
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Require the SEC-DSM decision procedure on new credentials.

Browse source 
Construction plans answer Q1–Q5 and name the preference-hierarchy level before a static secret or AppRole is proposed.

Assistant: grok
Assistant-Session: 01a12ce1-7ded-7e03-a845-2ece8a573af4
This commit is contained in:
tegwick 2026-10-11 23:41:31 +02:00
parent 5f09c2614f
commit d86ad141be
3 changed files with 51 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

17
docs/construction-plan-format.md
View file

@ -98,6 +98,23 @@ one-line reuse-vs-new rationale referencing section 2. Every item names
exactly what OpenBao object it touches (policy name, AppRole name, KV
path) — no vague "provision access" line items.
Before any new credential, answer SecurityCanon `SEC-DSM` §37 in order and
name the preference-hierarchy level (§5) the proposal lands on:
```text
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 viable, issue dynamically.
Q4 Can an existing static credential be rotated automatically? If yes, manage it centrally.
Q5 Must a persistent static credential exist? If yes, vault it and name owner,
consumer, authority, delivery, copies, rotation, revocation, detection, and
what would eliminate it.
```
A plan that creates a static secret or AppRole without those answers is not
ready for section 4. `DSM-TRANS-003`: do not add an issuance layer only to
claim dynamic maturity.
### 4. Review notes (phase 2)
Filled in during the self-review pass, before a human ever sees the