This document says which versions receive security fixes, how to report a vulnerability privately, and how a fixed vulnerability is published. The vulnerability-handling policy every FerroHEALTH product shares is on one page of the family book, written by the manufacturer, Cadasto B.V.: https://ferrohealth.eu/docs/security.html.

Only the newest release is supported. When a new release is published, every earlier release stops receiving fixes: there are no maintenance branches, no long-term-support line and no backports. If you are not on the newest release, upgrade; upgrading is free. Under the Cyber Resilience Act, Cadasto B.V. commits to keep publishing security fixes for at least five years after each release (Regulation (EU) 2024/2847 Art 13(8)) and ships them only in the newest release (Art 13(10)).

• Where fixes ship: a security fix ships in a new release. Where it is technically feasible, that release is a patch with the fix alone, so the update is provided separately from functionality updates (Annex I Part II(2)); when a functional change has to ship with it, the release's ### Security section opens with "Shipped with functional changes because:" and the reason, and the release notes carry it (docs/release.md).
• The end month: the release notes of each release state the month its five years end (Art 13(19)), counted from the date of its changelog heading.
• Updates stay available: a published release, its tag and each crate version on crates.io are never deleted.

A pre-release (a tag with a suffix, such as v0.0.4-rc.1) rehearses the release lane and has no support period. main is unreleased and best effort.

Do not open a public issue for a security vulnerability. Report it privately, through either route:

• GitHub private vulnerability reporting ("Report a vulnerability" on the repository's Security tab), which needs a GitHub account; or
• email to info@cadasto.com, the single point of contact of Cadasto B.V., the manufacturer (CRA Art 13(17)), with "FerroPIX vulnerability" in the subject. No account is needed. The address has no published encryption key, so send the details you are comfortable sending by email and say that more is available; a channel for the rest is agreed with you.

Both routes reach the same people and the same procedure.

Never include patient data in a report. FerroPIX cross-references patient identifiers, so a reproduction is easy to build from real ones by accident. Redact them, or synthesize an equivalent case.

FerroPIX is solo-maintained, so these are best effort rather than a contractual service-level agreement. They are the times every product of the Ferro family states: an acknowledgement within about 5 business days, and an initial assessment (is it valid, how severe) within about 10 business days of the report. A confirmed vulnerability is fixed in a new patch version, published within the target for its severity, counted from the confirmed assessment:

If the acknowledgement does not come in time, public disclosure to protect other users is your call.

A reported vulnerability gets a private draft of a GitHub security advisory on this repository the day it is confirmed, and the draft is the record until the fix ships. Every fixed vulnerability is published as that advisory, in the same hour as the release that fixes it: one in FerroPIX's own code, and one for a dependency fix that changes what a published crate builds into. The ### Security entry for the fix in CHANGELOG.md carries the advisory's GHSA- identifier, and the release notes repeat it (CRA Annex I Part II(4), (8)). A dependency finding that an OpenVEX statement under security/vex/ shows does not affect FerroPIX gets no advisory; the changelog entry names that statement instead. CI and the release check both rules (scripts/checks/changelog-security.sh). The advisories are machine-readable through the GitHub REST API (GET /repos/FerroHEALTH/FerroPIX/security-advisories).

A scanner can report a finding in the dependency graph that does not affect what FerroPIX publishes, such as an unmaintained crate that only runs inside the compiler. Such findings are judged in OpenVEX documents under security/vex/, which a scanner reads with trivy --vex. The document is generated from the advisories deny.toml accepts, and CI fails when the two disagree.