generated from coulomb/repo-seed
121 lines
3.7 KiB
Markdown
121 lines
3.7 KiB
Markdown
# Pattern Admission And Review Criteria
|
|
|
|
Status: review checklist refreshed for NK-WP-0010
|
|
|
|
## Purpose
|
|
|
|
This checklist controls how new patterns enter and graduate inside the
|
|
security architecture pattern infospace.
|
|
|
|
NK-WP-0010 admitted every exact pattern named in the genesis catalogue as
|
|
`seed` or stronger. The next reviews should focus on evidence quality and
|
|
maturity promotion rather than admission.
|
|
|
|
## Lifecycle
|
|
|
|
```text
|
|
seed -> draft -> reviewed -> canonical -> deprecated
|
|
```
|
|
|
|
## Admission Criteria
|
|
|
|
### Seed
|
|
|
|
A pattern can enter as `seed` when:
|
|
|
|
- it describes a recurring security architecture problem;
|
|
- it has a source, observation, workplan, incident, or external reference;
|
|
- it is clearly not just a one-off implementation note.
|
|
|
|
### Draft
|
|
|
|
A pattern can move to `draft` when it has:
|
|
|
|
- problem;
|
|
- context;
|
|
- forces and tradeoffs;
|
|
- solution sketch;
|
|
- known failure modes;
|
|
- related capabilities;
|
|
- initial NetKingdom or ecosystem mapping.
|
|
|
|
### Reviewed
|
|
|
|
A pattern can move to `reviewed` when it has:
|
|
|
|
- threat-model clarity;
|
|
- vendor-neutral framing;
|
|
- at least one open-source or self-hosted implementation option when
|
|
possible;
|
|
- commercial/provider options where relevant;
|
|
- operability notes;
|
|
- audit hooks;
|
|
- failure-mode behavior;
|
|
- readiness-level fit;
|
|
- owning repo or component named;
|
|
- evidence needed for verification.
|
|
|
|
### Canonical
|
|
|
|
A pattern can move to `canonical` when:
|
|
|
|
- NetKingdom architecture accepts it as the recommended pattern;
|
|
- implementation anchors exist or are intentionally scheduled;
|
|
- one or more workplans, ADRs, tutorials, or runbooks point to it;
|
|
- the pattern has clear prohibited alternatives or anti-patterns;
|
|
- verification evidence has been captured at the intended readiness
|
|
level.
|
|
|
|
### Deprecated
|
|
|
|
A pattern moves to `deprecated` when:
|
|
|
|
- it is replaced by a stronger pattern;
|
|
- implementation experience shows the pattern is unsafe or too costly;
|
|
- platform direction changes;
|
|
- vendor or technology assumptions no longer hold.
|
|
|
|
Deprecated patterns remain visible with their reason and replacement.
|
|
|
|
## Review Checklist
|
|
|
|
| Criterion | Question |
|
|
| --- | --- |
|
|
| Vendor neutrality | Can the pattern be understood without committing to a single product? |
|
|
| Threat model | Does it name the realistic failures or attacks it reduces? |
|
|
| Ownership | Are platform, product, tenant, and provider responsibilities clear? |
|
|
| Operability | Can an operator deploy, monitor, rotate, and recover it? |
|
|
| Auditability | Are security-relevant events and correlation ids defined? |
|
|
| Failure behavior | Does it fail closed or document controlled exceptions? |
|
|
| Readiness fit | Is RL0-RL4 applicability explicit? |
|
|
| Evidence | What proves implementation is correct? |
|
|
| Anti-patterns | What common unsafe shortcuts are prohibited? |
|
|
| Tutorial handoff | Does NK-WP-0009 need a tutorial for it? |
|
|
|
|
## Current Canonical Candidates
|
|
|
|
- STS credential vending.
|
|
- Secret zero avoidance.
|
|
- Delegated authorization.
|
|
- Break-glass access.
|
|
- Short-lived credentials.
|
|
- Policy Decision Point / Policy Enforcement Point.
|
|
|
|
These are candidates, not automatically canonical. Each still needs the
|
|
checklist evidence before the infospace marks it canonical.
|
|
|
|
## NK-WP-0010 Review Backlog
|
|
|
|
Use `artifacts/generated/research-pattern-normalization.md` as the
|
|
backlog for maturity promotion. Strong first review candidates are:
|
|
|
|
- Central Identity Provider and Identity Broker, because they shape
|
|
key-cape/Keycloak integration.
|
|
- Tenant Membership Boundary and Tenant Context Propagation, because
|
|
they protect multi-tenant correctness.
|
|
- Policy-as-Code Admission Control, Pod Security Baseline/Restricted,
|
|
and Signed Image Admission, because they form the platform deployment
|
|
gate.
|
|
- Security Event Taxonomy and Tenant Audit Log View, because they define
|
|
what can become tenant-visible evidence.
|