Skip to content

Security records

This directory records credential names and custody, access boundaries, review findings and verification evidence. Values, partial values, secret fingerprints, private keys, authorization headers, environment dumps and real memory contents never belong here, including in examples or receipts.

  • Register: repository-derived inventory, holders and proposed rotation intervals. Unknown deployment facts stay explicitly unknown.
  • October 2026 review: access paths, findings and proposed follow-up work, with the required decision maker.
  • October remediation plan: concrete R01–R05 changes, blast radius, rollback and required agreement; five DevOps task briefs await coordinator registration, with delivery evidence.
  • Evidence: checks repeated for the current frozen task v14, with the inherited documentation and current delivery base distinguished.

Security maintains the record and reviews authentication, authorization and secret changes before merge. The role does not grant access, deploy, rotate production credentials without the owner's approval, or gate unrelated work. The assigned canonical role reference is docs/specs/org-v1/K0-roles.md#security; this checkout does not yet contain that section, so the task's supplied security role is the authority here.

Monthly review

The next review is due 2026-11-10, then monthly. Security compares the previous inventory with Compose, configuration, operations scripts, workflows, Bridge contracts and new authentication changes. The owner/DevOps supplies authorized, value-free confirmations of active holders, last rotation dates, expiry, project memberships, OAuth grants, SSH users, CI isolation, and Bridge model/account/repository allowlists. This first task authorizes repository inspection only; it does not authorize collecting those live confirmations.

For each entry, record the confirmation date and evidence reference, last rotation, next due date and approving owner. Until confirmed, use unknown, not an invented issue date. Check that dormant access is removed, scopes still match the consumer and recovery access remains usable. Rotate only in a separately approved operation: provision successor, update the exact consumers, verify them, revoke predecessor, and record non-secret evidence. Preserve old decryption keys while retained backups still need them.

Write review-YYYY-MM.md with findings ordered P1 (security breach, data loss or outage), P2 (reachable incorrect behavior or excessive access), P3 (hardening or unverified gap). Each finding needs a source, consequence, concrete narrowing, implementation owner, required agreement and closure evidence. A hypothetical breach is not evidence that one occurred. Send one owner summary per review: findings, recommendations and decisions needed. Hand the coordinator a follow-up per finding; record its task reference here when one exists. Recommendations are not permissions to implement them.

When an incident is confirmed, add incident-YYYY-MM-DD-<topic>.md recording discovery time, affected component, impact, cause, containment, approved repair, verification and prevention task references, without credential material. No incident is asserted by the first repository-only review. If a possible secret is found, record only possible secret committed at <path>:<line> as P1 and request owner-approved containment through the coordinator.

These files are eligible for the documentation build: mkdocs.yml does not exclude security/. Keep them suitable for publication; private operator identities, live access exports and custody proofs belong in protected records.