Skip to main content

Reporting Vulnerabilities

Project context: CIVITAS/CORE is delivered as software only. We do not operate production instances. Runtime security and operational controls are the responsibility of each deploying organization ("user‑operators"). This document explains how to report vulnerabilities and how we handle security for the code we publish.

Reporting a vulnerability​

Preferred

  • Email: core@civitasconnect.digital (PGP preferred; key below)
  • Or open a confidential issue in this repository (Issues → New issue → mark as Confidential). Please do not open public issues for vulnerabilities.

What to include

  • A clear description of the issue and impact
  • Affected components and versions (commit/branch or release tag)
  • Reproduction steps or minimal PoC
  • Any workarounds you found
  • Your disclosure timeline preference and a contact for follow‑up

Please avoid

  • Exploiting the vulnerability beyond what is necessary to demonstrate it
  • Accessing, modifying, or exfiltrating data you do not own
  • Public disclosure before coordination (see policy below)

Coordinated disclosure policy​

We follow a coordinated disclosure approach aligned with common industry practice.

  • Triage: within 2 business days we will acknowledge receipt and start triage.

  • Assessment: we assign a severity using CVSS v4 and validate scope.

  • Fix: we target the following maximum timelines from triage (may be faster depending on severity):

    • Critical: 7–14 days
    • High: 30 days
    • Medium: 60 days
    • Low: 90 days

  • Embargo: by default up to 90 days from report; extended only when a fix is ready but coordination with downstreams/operators is required.

  • Credit: we are happy to acknowledge reporters in release notes/advisories (opt‑in).

If a vulnerability is being actively exploited in the wild, we may publish limited details early to protect users while a full fix ships.

Scope​

In scope

  • Source code and artifacts in the CIVITAS/CORE repositories
  • Build, packaging, and release pipelines
  • Default/sample configurations and manifests we ship

Out of scope

  • Production deployments run by user‑operators (contact your operator)
  • Third‑party services/infrastructure (e.g., cloud providers, registries) unless we explicitly own and operate them
  • Social engineering, physical access, and volumetric DoS

Severity​

We score issues roughly with CVSS v4. As a guideline:

  • Critical/High: RCE, auth bypass, integrity compromise of build/release, secret exposure with direct exploitation potential
  • Medium: privilege escalation requiring preconditions, SSRF with meaningful impact, info leaks enabling further compromise
  • Low: best‑practice deviations with limited practical impact, missing hardening in non‑default paths

Supported versions & patch policy​

We maintain security fixes for actively supported release lines.

Release lineStatusSecurity fixes until
v2.0Development

Policy

  • We fix security issues in the latest minor of each supported major.
  • We may publish transitional mitigations/workarounds when patches require broader changes by operators.

Release integrity & supply chain​

To support a transparent supply chain, we aim to provide for each release:

  • Signed artifacts (e.g., container images, archives)
  • SBOM attached to releases

Third‑party dependencies​

  • We track dependencies via automated tooling and issue advisories if upstream CVEs affect us.
  • If the vulnerability is in an upstream project, we will coordinate with that upstream and reflect status here.

Safe‑harbor for good‑faith research​

We will not pursue or support legal action against researchers who:

  • Make a good‑faith effort to comply with this policy
  • Report vulnerabilities promptly and privately
  • Do not compromise privacy or data integrity beyond what is necessary to prove the finding
  • Do not extort or demand payment

If in doubt, ask us at core@civitasconnect.digital before proceeding.

Security communications​

  • Advisories: published with each affected release (changelog + standalone advisory)
  • CVE policy: we request CVEs for confirmed vulnerabilities that warrant one, and reference CVE IDs in advisories
  • Public updates: minimal details until patches are available or operators have a mitigation path

Alignment with our SSDLC​

Our SSDLC emphasizes secure‑by‑default choices, complete mediation, least privilege, and transparent supply chain. Design reviews include lightweight threat modeling for new components/integrations. See the SSDLC for intake/triage, disclosure artifacts, and quality gates.

Responsible disclosure contact​

Appendix A: PGP key for encrypted reports​

TODO

Fingerprint: TODO

Appendix B: Example disclosure timeline​

  1. Day 0: Reporter sends encrypted report → we acknowledge within 2 business days
  2. Day 2–5: Triage and severity assessment; determine scope and owners
  3. Day 5–14: Patch development + tests + backports; prepare advisory draft and mitigations
  4. Day 14–30+: Coordinate with downstreams/operators if needed; prepare release artifacts
  5. Release day: Publish fixed versions, advisory with severity information, credits (if opted‑in), SBOM/provenance
  6. Post‑release: Follow‑up and, if needed, additional hardening guidance

Thank you for helping keep Civitas/Core users safe.