Open security core for dev sec ops on kubernetes
tegwick
584738bd9f
audit-core assented to the approval evidence half with conditions and corrected the rationale twice. Both corrections were against wording this standard had taken from that repository's INTENT rather than its contract. - §4 catalogues audit-core as an Engine, on its own declaration. v0.3 named it as an owner in §9.4 and §13 without listing it — a §11 defect in the standard itself, which audit-core raised. - §9.4 rationale rewritten to cite docs/integrity.md rather than INTENT principle 6: an in-database chain detects a rewritten payload only if the attacker does not recompute the suffix, which a database owner can, and even with external attestation the store is not WORM or object lock. tamper evidence is conditional on live preconditions. - §9.4 gained emission atomicity as approval-engine's obligation, and the prohibition on audit-core exposing an approval-validity query — a boundary audit-core stated unprompted, applying §6.1 to itself. - §9.6 added, estate-wide: evidence proves alteration and truncation, not omission at source. A suppressed revocation leaves the chain intact and verification reports intact. "The audit record proves it happened" is unsound and is replaced with the sound form. - §13 gained two gaps: stronger approval custody (unassigned — deciding whether approvals need archival custody distinct from other sources is doctrine work not yet done) and emission atomicity (approval-engine). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 |
||
|---|---|---|
| .claude | ||
| .forgejo/workflows | ||
| .githooks | ||
| canon | ||
| capabilities/playbooks | ||
| docs | ||
| examples | ||
| history | ||
| identity-provisioner | ||
| keys | ||
| local-identity | ||
| registry | ||
| sso-mfa | ||
| tests | ||
| tools | ||
| wiki | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| .sops.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONFIG.md | ||
| DECISIONS.md | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
NetKingdom
NetKingdom is the canonical security architecture, integration boundary, and bootstrap/reference implementation for NetKingdom environments. It defines identity, tenancy, credential, workload-zone, and security-composition contracts while leaving provider and Railiance execution in their owning repositories.
The dynamic, self-optimizing security platform is the long-term direction in INTENT.md, not a claim about current delivery.
Orientation
- SCOPE.md — what this repo owns, current state, and when it is relevant
- Security layer model — how the security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own
- Security scenario composition — deterministic, plan-only capability and trust composition
- Posture feedback — deterministic, proposal-only posture and evidence remediation findings
Security Infrastructure Documents
- secrets-engine security infrastructure boundary defines how secrets-engine participates in the NetKingdom security infrastructure and how it interacts with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.