coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
security-canon/SCOPE.md
tegwick 8ab4891043 Adopt SEC-DSM 1.0 as the secrets-practice standard. 
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
2026-10-11 23:41:30 +02:00

4.6 KiB
Raw Permalink Blame History

SCOPE

Reviewed: 2026-10-03 (Europe/Berlin), following the completed vocabulary work and SEC-ADR-001.

Current repository scope

The repository publishes Mode of Authority draft 0.2.0 vocabulary artifacts, mode/dimension catalogs, declared imports, a federation interface, cross-canon mappings and orientation surfaces. SECURITY-WP-0001 is finished. The retained v0.1 research draft is historical, not the current orientation artifact. There is no service code; SEC-ADR-001 keeps validation in InfoTechCanon's service.

It also publishes the DevOps Secrets Management Standard (SEC-DSM 1.0.0) at infospace/standards/devops-secrets-management/. That standard states the normative secrets-management practice. It does not operate custody, issue credentials, or decide authorization. SECURITY-WP-0002 records the insertion.

Ownership and boundaries

Following INTENT.md, SecurityCanon occupies the Taxonomy layer and owns security concept definitions and their cross-canon mappings. It imports shared roots from InfoTechCanon and does not redefine them.

Out of scope, with the owner named:

  • the CARING access governance standard and its Kubernetes RBAC benchmark, the access-control model, and the identity model — InfoTechCanon, by SEC-ADR-001 D1 and D3
  • any CLI, HTTP API, or validation service — InfoTechCanon's service surface, by SEC-ADR-001 D4; integration is via the canon-federation interface card
  • security architecture and standards of record for the estate — NetKingdom
  • authorization decisions — access-engine (runtime/product flex-auth)
  • login, OIDC, MFA — key-cape / Keycloak
  • credential custody and issuance — secrets-engine over OpenBao; operational routing and SSH certificates — ops-warden. The practice those systems follow is this canon's DevOps Secrets Management Standard; the operation stays theirs
  • adversarial evidence and findings practice — whitehat-security
  • shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
  • consumer runtime state, enforcement, observation, and adoption evidence — the consumers

Planned scope

The near-term deliverable is the architecture-layer vocabulary, not a migration.

Deliverable Task
Mode of Authority promoted to a checkable Tier-1 artifact SECURITY-WP-0001-T06
Terminology separation from CARING and the access-control model SECURITY-WP-0001-T07
Federation interface card declaring Auth Mode as an export SECURITY-WP-0001-T04
Orientation surfaces: vocabulary card, design heuristic, disambiguation page SECURITY-WP-0001-T06
DevOps Secrets Management Standard (SEC-DSM 1.0.0) SECURITY-WP-0002

InfoTechCanon artifacts this canon references rather than absorbs:

Path in info-tech-canon Relationship
infospace/standards/caring/ implementation layer; imports the vocabulary
infospace/models/access-control/ owns Subject, Principal, IdentityReference
infospace/models/identity/ shared root; stays upstream
infospace/models/security/ boundary under review in SECURITY-WP-0001-T02
infospace/models/devsecops/ boundary under review in SECURITY-WP-0001-T02

Open questions, answered under SECURITY-WP-0001 and no longer carried:

  • the security and DevSecOps models stay in InfoTechCanon. Both were the only remaining migration candidates and neither cleared the bar of demonstrably helping both canons (SECURITY-DEC-2026-003);
  • the small-saas profile's security artifacts stay whole in InfoTechCanon. A SecurityCanon example references them by id across the federation interface rather than relocating them;
  • the Actor/Subject naming question, analysed in the implications note and decided under SECURITY-WP-0001-T07: the on-behalf-of dimension is AuthorityContext and no upstream concept is redefined.

Concept placement across the boundary — one owning canon and one import direction per shared concept — is recorded in concept-placement.md, with the supporting survey of InfoTechCanon's existing authority vocabulary in infotechcanon-authority-survey.md.

Exclusions and evolution

No service surface is in scope, now or later: SEC-ADR-001 D4 settles that SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A check that does not exist is a change request against InfoTechCanon.

A dedicated identity or personhood canon may eventually be right. It is deferred and belongs to no current workplan.