tegwick
1ac4f56783
Scaffold the repository to the repo-manager standard and establish its governance surface: INTENT declaring the Taxonomy-layer claim and boundary against NetKingdom, flex-auth, key-cape, OpenBao and whitehat-security; GOAL with migration invariants and success gates; SCOPE listing the extraction candidates and the unresolved boundary questions; AGENTS repo identity; repo classification. Add SECURITY-WP-0001 covering registration, the disposition review of InfoTechCanon's security material, the reference-impact survey, the federation interface card, and the handoff to a migration workplan. No canon content is moved yet — the migration waits on the reviewed disposition. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj Assistant: claude-code Assistant-Model: opus Assistant-Process: 36656@bnt-lap001 Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
90 lines
4.4 KiB
Markdown
90 lines
4.4 KiB
Markdown
# Intent
|
|
|
|
SecurityCanon provides an implementation-neutral vocabulary and canonical model
|
|
for security-related concepts. It extends InfoTechCanon in the same architectural
|
|
role that CommerceCanon serves for commercial terminology and InterfaceCanon for
|
|
interface terminology: import shared roots, contribute a focused domain model,
|
|
and avoid redefining concepts another canon already owns.
|
|
|
|
## Origin and demand
|
|
|
|
The initial demand is the repository owner's 2026-09-20 request to refine
|
|
InfoTechCanon by moving its IT-security material into a dedicated canon.
|
|
InfoTechCanon has accumulated security content — a security model, an access
|
|
control model, a DevSecOps model, the CARING access governance standard, and the
|
|
CARING Kubernetes RBAC benchmark — that is orthogonal to its taxonomy-layer role
|
|
and better served by a canon with its own review cadence and consumers.
|
|
|
|
Extraction is a migration, not a rewrite. Source artifacts keep their provenance,
|
|
and InfoTechCanon retains the shared roots that security terminology imports.
|
|
|
|
## Layer and boundary
|
|
|
|
SecurityCanon declares itself part of the **Taxonomy** layer under the NetKingdom
|
|
Security Layer Model. It produces security terminology, semantic contracts, and
|
|
compatibility rules for independently owned systems.
|
|
|
|
SecurityCanon owns security concept definitions and their cross-canon mappings.
|
|
It does not own a runtime position, enforcement, or state on which another layer
|
|
depends:
|
|
|
|
- **NetKingdom** owns its security architecture, its standards of record,
|
|
including the security layer model, and any NetKingdom-specific profiles that
|
|
import this canon.
|
|
- **flex-auth** owns authorization decisions; **key-cape** and Keycloak own
|
|
login, OIDC, and MFA; **OpenBao** owns secret custody. SecurityCanon describes
|
|
those concepts; it does not perform them.
|
|
- **whitehat-security** owns adversarial evidence and findings practice.
|
|
- **InfoTechCanon** remains the authority for the shared roots — artifact,
|
|
ownership, relationship, mapping, assimilation, profile, pattern, conformance,
|
|
provenance, and interface mechanisms — that this canon imports.
|
|
- Consumers own their own adoption evidence and importing profiles.
|
|
|
|
A generic security semantic contract belongs here; a security obligation imposed
|
|
on a concrete estate belongs to the owner of that estate.
|
|
|
|
## Primary utility
|
|
|
|
SecurityCanon helps turn security integration by interpretation into integration
|
|
by declared semantic contract. It provides:
|
|
|
|
- canonical security concepts with clear ownership,
|
|
- orthogonal security standards that import rather than redefine,
|
|
- mappings to external security standards, frameworks, and regulations,
|
|
- benchmarks that test a standard against a concrete native access model,
|
|
- application profiles for concrete implementation contexts,
|
|
- and retrieval-friendly markdown artifacts for humans, agents, and tools.
|
|
|
|
## Design stance
|
|
|
|
SecurityCanon follows InfoTechCanon's stance: markdown-first but machine-readable,
|
|
network-shaped rather than purely hierarchical, pattern-oriented rather than merely
|
|
taxonomic, externally mappable without being externally constrained, and
|
|
orthogonal without becoming isolated.
|
|
|
|
External standards influence SecurityCanon through mappings and assimilation.
|
|
They do not define its internal semantics directly.
|
|
|
|
## Core commitments
|
|
|
|
1. Every canonical security concept has a clear owner.
|
|
2. Concepts are imported from their owning canon, never redefined.
|
|
3. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified.
|
|
4. Migrated artifacts preserve provenance and their InfoTechCanon history.
|
|
5. Profiles constrain standards for concrete implementation contexts.
|
|
6. Artifacts are useful to both humans and agents.
|
|
7. Evolution preserves provenance, compatibility information, and rationale.
|
|
|
|
## Non-goals
|
|
|
|
SecurityCanon does not replace external standards such as NIST, ISO 27001, CIS,
|
|
OWASP, or MITRE ATT&CK. It does not define one mandatory security model every
|
|
system must fully implement, operate consumer systems, enforce policy, issue
|
|
credentials, or provide production authorization or detection services.
|
|
|
|
## Direction of travel
|
|
|
|
The repository should initially establish the canon skeleton and federation
|
|
interface, then receive the security material extracted from InfoTechCanon with
|
|
its provenance intact, then publish mappings and at least one worked profile.
|
|
Stable promotion requires reviewed mappings and concrete consumer evidence.
|