council-forge is an artifact-first multi-agent governance template (a single source of truth that propagates to downstream repos). This policy covers how to report a vulnerability, how we triage and remediate, and the good-faith terms for security researchers. It implements SSDF RV.1.3 (a documented vulnerability-disclosure-and-remediation policy) and the intake side of RV.1.1. The machine-checkable intake file lives at .well-known/security.txt and is validated in CI by artifacts/scripts/security_txt_gate.py (per-PR and on a schedule, so it cannot silently lapse).

Please report privately — do not open a public issue for a suspected vulnerability.

1. Preferred: GitHub private vulnerability reporting — https://github.com/arcobaleno64/council-forge/security/advisories/new (the "Report a vulnerability" button). This opens a private draft advisory only the maintainers can see.
2. Alternative: email the contact listed in .well-known/security.txt.

Please include: affected file/script/workflow, a description of the issue and its impact, and reproduction steps or a proof of concept where possible.

council-forge is maintained on a best-effort basis. We do not promise a fixed response time we cannot reliably meet (see the OWASP Vulnerability Disclosure guidance and GitHub's coordinated disclosure guidance, which deliberately set no hard deadline). Our intent:

• Acknowledgement: we aim to acknowledge a report promptly (best effort).
• Coordinated disclosure: we ask that you give us a reasonable window — by default up to 90 days — to remediate before any public disclosure, and we will coordinate timing with you. This window is a convention (cf. ISO/IEC 29147 coordinated disclosure), not a guarantee.
• Credit: with your consent, we will credit you in the advisory / release notes.

NIST SSDF SP 800-218 v1.1 (RV.2) requires risk-based assessment and prioritization but does not define numeric remediation deadlines. The targets below are council-forge's own self-imposed conventions, derived from common industry practice (CVSS severity bands) and are explicitly not mandated by SSDF:

KEV override: a vulnerability listed in the CISA Known Exploited Vulnerabilities catalog (or otherwise observed exploited in the wild) is treated as Critical regardless of CVSS score, per the spirit of CISA BOD 22-01.

When a confirmed vulnerability becomes an incident (e.g. exploitation, exposure of a downstream), we follow the incident-response runbook (a NIST SP 800-61 shaped detect → triage → contain → eradicate → recover → post-incident/root-cause flow). The root-cause / post-incident analysis feeds artifacts/improvement/PROCESS_LEDGER.md.

We support good-faith security research. If you make a good-faith effort to comply with this policy — accessing only your own accounts/data or test data, avoiding privacy violations, service degradation, and data destruction, and giving us reasonable time to remediate before disclosure — we will not pursue or support legal action against you for that research, and we will work with you to understand and resolve the issue quickly. (Adapted from the open disclose.io / dioterms conventions. This is not legal advice; per OWASP, consult a lawyer for binding terms.)

This policy covers the council-forge repository itself (its scripts, workflows, governance artifacts, and templates). Downstream terminal repos generated from template/ maintain their own security policies; this repo's docs/templates/security/ directory provides reusable templates (SCA / SAST / SBOM / security.txt) for them to adopt.

council-forge publishes a content-addressed integrity manifest of its release surface (the propagated template/ SSOT snapshot) at .well-known/release-manifest.json, and a detached signature is verified in CI by the native gpg --verify step of the release-integrity job. The signing public key (when provisioned by the operator) is published at .well-known/release-signing.pub, and its fingerprint is the trust anchor pinned via EXPECTED_SIGNING_FINGERPRINT. Acquirers should obtain that fingerprint out-of-band (not from the same commit). The full key lifecycle — generation, out-of-repo storage, rotation, revocation, protection, and periodic review (SSDF PS.2.1 Example 2/3) — is documented in docs/security/release-signing.md. No private key is ever committed to this repository.

Reproducing the digests (acquirers): the manifest declares its canonicalisation in the digest_canonicalization field (text-eol-lf-v1, schema @2). To recompute a sha256 and compare, LF-normalise text files (CRLF/CR → LF) before hashing; binary files (not UTF-8-decodable, or containing a NUL byte) are hashed raw. This makes the content-address identical across platforms regardless of working-tree line endings.

See docs/security_cadence.md for how disclosure intake, the weekly Codex Council audit, the quarterly threat model, the continuous SAST/SCA/SBOM/secret scans, and the release-integrity / signing review fit together.