53 lines
2 KiB
Markdown
53 lines
2 KiB
Markdown
|
# SCOPE
|
||
|
|
|
||
|
|
Reviewed: 2026-09-20 (Europe/Berlin).
|
||
|
|
|
||
|
|
## Current repository scope
|
||
|
|
|
||
|
|
Bootstrap. The repository carries governance files — INTENT, GOAL, SCOPE,
|
||
|
|
AGENTS, repo classification — and one active workplan. It holds no canon
|
||
|
|
content and no service code yet.
|
||
|
|
|
||
|
|
## Ownership and boundaries
|
||
|
|
|
||
|
|
Following [INTENT.md](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:
|
||
|
|
|
||
|
|
- security architecture and standards of record for the estate — NetKingdom
|
||
|
|
- authorization decisions — flex-auth
|
||
|
|
- login, OIDC, MFA — key-cape / Keycloak
|
||
|
|
- secret custody and credential issuance — OpenBao, ops-warden
|
||
|
|
- 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 extraction candidates in InfoTechCanon, pending the disposition review in
|
||
|
|
`SECURITY-WP-0001-T02`:
|
||
|
|
|
||
|
|
| Source path in info-tech-canon | Kind |
|
||
|
|
| --- | --- |
|
||
|
|
| `infospace/models/security/` | model |
|
||
|
|
| `infospace/models/access-control/` | model |
|
||
|
|
| `infospace/models/devsecops/` | model |
|
||
|
|
| `infospace/standards/caring/` | standard |
|
||
|
|
| `infospace/standards/caring/benchmarks/kubernetes-rbac/` | benchmark |
|
||
|
|
|
||
|
|
Open boundary questions the disposition review must answer, not assume:
|
||
|
|
|
||
|
|
- whether `infospace/models/identity/` is security terminology or a shared root
|
||
|
|
that stays in InfoTechCanon;
|
||
|
|
- how the small-saas profile's security artifacts (policy, control, evidence,
|
||
|
|
incident) split between the two canons;
|
||
|
|
- which InfoTechCanon concepts become declared imports rather than moves.
|
||
|
|
|
||
|
|
## Exclusions and evolution
|
||
|
|
|
||
|
|
No service surface, CLI, HTTP API, or validation tooling is in scope until the
|
||
|
|
canon content exists and a demand for them is recorded. Whether SecurityCanon
|
||
|
|
reuses InfoTechCanon's Python service or ships its own is deferred.
|