SECURITY.md — Trinity Accord Security and Correction Policy
Scope
This document covers the security policy for the Trinity Accord repository, including vulnerability reporting, correction and revocation procedures, and the non-deletion/tombstone policy that preserves the integrity of the public trust protocol.
Reporting Contact
Security vulnerabilities and data integrity issues should be reported via:
- GitHub Private Vulnerability Reporting (preferred): Repository → Security → Report a vulnerability
- GitHub Security Advisories: Repository → Security → Advisories → New draft security advisory
- Private issue with the
securitylabel
Do not disclose vulnerabilities publicly before they are triaged.
Control-Plane Incident Response
If repository control-plane settings are compromised or drift from the documented baseline:
- Branch protection removed: Immediately re-enable via Settings → Branches. Check
CONTROL-PLANE-BASELINE.mdfor required settings. - CODEOWNERS enforcement disabled: Re-enable “Require review from Code Owners” in branch protection.
- Actions permissions widened: Revert to restricted settings. Audit recent workflow runs for unauthorized changes.
- Tag/release tampered: Check corrections-index for revocation records. Run release verifier against known-good manifests.
- Secrets leaked: Revoke immediately. Rotate all potentially affected credentials. Add revocation record to corrections-index.
- Unauthorized push to main: Force-revert if branch protection was bypassed. Audit all commits since last verified state.
Run python3 scripts/audit_control_plane.py --check to detect settings drift.
Severity Levels
| Level | Description |
|---|---|
| Critical | Compromise of trust-root keys, Bitcoin inscription integrity, or authority manifest. Immediate response required. |
| High | Incorrect attestation counts, missing revocation records, or corrections-index integrity failures. Response within 24 hours. |
| Medium | Schema validation bypasses, missing lifecycle metadata, or stale copy propagation issues. Response within 72 hours. |
| Low | Documentation gaps, non-critical metadata inconsistencies, or cosmetic issues. Response within 1 week. |
Response Process
- Triage — Assess severity and scope of the issue.
- Preserve — Ensure no existing records are hard-deleted. All corrections use tombstone records.
- Update corrections-index — Add correction, revocation, or supersession records to
api/corrections-index.json. - Regenerate digests — Recompute
source_digestfor any modified index files. - Run tests — Execute all CI validators and lifecycle tests to confirm the fix.
- Publish notice — Update affected public entrypoints and announce the correction.
Non-Deletion / Tombstone Policy
No public trust record may be hard-deleted. We do not silently delete any record that was once public. When a record is corrected, revoked, superseded, or invalidated:
- The original record remains in place with lifecycle metadata added.
- A tombstone entry is added to
api/corrections-index.json. - The record’s
is_currentis set tofalseandhistorical_record_onlyis set totrue. - The
counts_as_independent_attestationfield is set tofalsefor revoked/superseded records.
This ensures full auditability and prevents silent revision of the public trust record.
Stale Copy Notice
If any cached, quoted, or mirrored copy of this repository’s data conflicts with the current api/corrections-index.json, the corrections index takes precedence. Always verify against the canonical source:
- Corrections index:
https://www.trinityaccord.org/api/corrections-index.json - Canonical repository:
https://github.com/thechurchofagi/trinity-accord
Boundary Statement
This security policy governs repository-maintained trust records. It does not amend the Bitcoin Originals. The Bitcoin inscriptions are canonical; all repository files are non-amending mirrors. Corrections and revocations apply only to repository-maintained indexes and metadata.
Cold-Start Recovery
For cold-start recovery after compromise, see RECOVERY.md and api/recovery-index.json.