FerroCHART is an openEHR form builder and renderer: it compiles operational templates into forms and commits the results to an openEHR CDR. This document says which versions receive security fixes and how to report a vulnerability privately.
FerroCHART is in its design phase and has no release. Once releases begin, security fixes apply to the latest released version only; there is no back-port line.
| Version | Supported |
|---|---|
| Latest release | ✅ |
| Older releases | ❌ |
main (unreleased) |
best effort |
Once the project reaches 1.0 this table will name a supported minor line.
Do not open a public issue for a security vulnerability. Report it privately through GitHub's private vulnerability reporting:
- Open the private advisory form: https://github.com/FerroHEALTH/FerroCHART/security/advisories/new. You can also reach it from the repository's Security tab under Report a vulnerability.
- Describe the issue, the affected version or commit, and a reproduction if you have one.
This opens a private advisory visible only to you and the maintainer. If you cannot use GitHub's form, contact the maintainer through their GitHub profile and ask for a private channel before sending any details.
Please include, where you can:
- the affected version, tag, or commit;
- a description of the impact (what an attacker can do);
- steps to reproduce, a proof of concept, or a failing request;
- any suggested remediation.
Never include patient data in a report. FerroCHART sits in the path of clinical data at the point a clinician types it, so a reproduction is easy to build from real content by accident. Redact it, or synthesize an equivalent case.
This is a solo-maintained project, so timelines are best effort rather than a contractual service-level agreement:
- Acknowledgement of your report within about 5 business days.
- An initial assessment (is it valid, how severe) within about 10 business days.
- A fix or a mitigation plan for a confirmed vulnerability as a priority, released as a new patch version. A published release is immutable and its tag cannot be moved or deleted, so a fix ships forward as a new version rather than by re-tagging.
You will be kept informed through the private advisory and, with your consent, credited when the advisory is published. Please give a reasonable window to release a fix before any public disclosure (coordinated disclosure).
In scope: the FerroCHART server and libraries in this repository, its mapping handling, its build and release pipeline, and its published artifacts.
Out of scope: a vulnerability in a third-party dependency with no
FerroCHART-specific impact (report those upstream; Dependabot and cargo deny
track advisories here), a vulnerability in the openEHR CDR or the terminology
server a deployment points FerroCHART at (report those to that project), and an
issue that requires an already-compromised host or a misconfiguration outside
FerroCHART's control.
Every archive a v* tag publishes carries a SHA-256 checksum, a Sigstore
build-provenance bundle, a CycloneDX SBOM and an SBOM attestation. The
container image carries provenance for its index and for each platform
manifest, plus an SPDX SBOM per platform, all pushed as OCI referrers. The
binaries and the image are built in reusable workflows, so a verifier can
insist on the lane that produced an artifact rather than on the repository
alone:
gh attestation verify ferrochart-<tag>-<target>.tar.gz \
-R FerroHEALTH/FerroCHART \
--signer-workflow FerroHEALTH/FerroCHART/.github/workflows/release-build.yml
gh attestation verify oci://ghcr.io/ferrohealth/ferrochart:<version> \
-R FerroHEALTH/FerroCHART \
--signer-workflow FerroHEALTH/FerroCHART/.github/workflows/release-image.ymlReleases up to v0.1.0 were built before the repository moved to the
FerroHEALTH organization: they are signed as rubentalstra/FerroCHART
and their image is ghcr.io/rubentalstra/ferrochart, so verify those
with the old names in every command above. The same manifests are also
at ghcr.io/ferrohealth/ferrochart, copied by digest.
The lane that emits these landed after v0.0.1, so the first release carrying
them is the next one; v0.0.1 published archives and checksums only. The full
asset inventory, the SLSA claim and what it does not cover are docs/release.md.