FerroEHR

https://github.com/rubentalstra/FerroEHR — public, git.

git. Every commit is additionally required to be cryptographically signed: the
develop branch ruleset carries a required_signatures rule, so an unsigned commit
cannot land.

develop carries the full commit history between releases, not squashed release drops. Every change lands as its own reviewable commit with a descriptive message, and pull requests remain open for inspection after merge.

Repository on GitHub, which uses git. git is distributed.

Each release is a unique SemVer version, tagged vX.Y.Z, and the workspace version in Cargo.toml is bumped in the release pull request. The release workflow refuses a tag that has no matching CHANGELOG.md section, so a version cannot be published without its own entry.

Every release is a git tag vX.Y.Z on the release merge commit.

CHANGELOG.md follows Keep a Changelog 1.1.0 with Added / Changed / Deprecated /
Removed / Fixed / Security sections, written for the end user rather than as
commit prose. It is enforced, not optional: a CI changelog-guard job fails any
pull request with user-visible changes and no [Unreleased] entry, and the release
workflow publishes the GitHub Release from the matching changelog section and
fails if that section is missing. These are curated notes, not version-control log
output.
https://github.com/rubentalstra/FerroEHR/blob/develop/CHANGELOG.md

No publicly known vulnerability (CVE-assigned or equivalent) in FerroEHR's own code has been fixed in any release to date, so there is nothing for the release notes to identify. The criterion's own guidance says to choose N/A when there have been no publicly known vulnerabilities. Security-relevant hardening is recorded in the changelog's Security and Fixed sections regardless.

GitHub Issues, open to anyone. Security reports go through the separate private
process in SECURITY.md.
https://github.com/rubentalstra/FerroEHR/issues

GitHub Issues is the project's authoritative worklist, not a side-channel: each issue carries a contract with acceptance criteria, work is linked back to it, and milestones are the release spine.

Every issue filed has received a substantive response and a triage decision; none is sitting unacknowledged. In candour: the project is young and single-maintainer, so most issues to date were filed by the maintainer from audits and conformance runs. Those still receive an explicit adjudication — implemented, or closed with the reason — rather than accumulating silently.

Same as report_responses: every enhancement request has an answer. Where one is
declined, the reason is recorded on the issue rather than left to lapse.

The GitHub Issues archive is public, searchable, and includes closed issues with
their full discussion. Pull request discussions remain public after merge.
https://github.com/rubentalstra/FerroEHR/issues?q=is%3Aissue

SECURITY.md documents the reporting route, what a reporter can expect, safe
harbour, and credit. It is also published machine-readably as a security.txt per
RFC 9116 at https://ferroehr.eu/.well-known/security.txt
https://github.com/rubentalstra/FerroEHR/blob/develop/SECURITY.md

GitHub private vulnerability reporting is enabled on the repository (verified), so
a reporter can open a private advisory directly from the Security tab without
exposing details. SECURITY.md documents this as the preferred route.
https://github.com/rubentalstra/FerroEHR/security/advisories/new

No vulnerability report has been received in the last 6 months, so there is no response time to measure. The published commitment in SECURITY.md is an acknowledgement within 5 working days — inside the 14-day requirement — with an assessment within a further 10 days.

cargo. cargo build --workspace builds everything from source; the release
artifacts are built by cargo build --release --locked -p ferroehr-server in CI.
The toolchain is pinned by rust-toolchain.toml so a build is reproducible in the
sense that matters: everyone compiles with the same compiler.

cargo, the standard Rust build tool, with no wrapper build system. Container images build with a standard Dockerfile; the Helm chart with helm.

The entire toolchain is FLOSS: the Rust compiler and cargo, PostgreSQL 18 for the integration tests, Docker/BuildKit for images. No proprietary tool is required to build, test or release.

4410 automated tests run by cargo-nextest, plus a 1049-case openEHR conformance
catalogue driven against a live composed server. All of it is in the repository
under the project's MIT licence. How to run it is documented in CONTRIBUTING.md's
"The gates" section (cargo nextest run --workspace) and executed by the CI
workflow on every pull request.

cargo test --workspace works; the project's preferred runner is
cargo nextest run --workspace, which is the standard third-party Rust test
runner. Both are ordinary cargo invocations with no bespoke harness.

GitHub Actions runs the full gate set on every pull request and every push to
develop: build and test against real PostgreSQL 18, clippy with -D warnings,
rustfmt, rustdoc with -D warnings, MSRV verification, cargo-deny, coverage,
codegen drift, browser end-to-end tests, and an aggregate conclusion job.
https://github.com/rubentalstra/FerroEHR/actions/workflows/ci.yml

CONTRIBUTING.md states it as a hard rule, and it is enforced in two directions: new functionality lands with tests, and a test may never be weakened, skipped or deleted to make a build pass, nor edited to route around a bug it exposes. For the conformance surface the rule is stronger — coverage only ratchets upward, and a wire behaviour the specification defines with no covering case is a gap to close.

Recent examples, each visible in the history: the XML reader's nesting bound and
DOCTYPE refusal landed with six asserted-refusal tests
(crates/openehr-its/tests/it/xml_hostile_input.rs); the error-source-chaining
change landed with a test that provokes a real database failure, walks the error
chain, downcasts to the concrete driver error, and asserts the rendered HTTP body
discloses none of it (app/ferroehr-rest/tests/it/error_chain.rs); an authorization
change landed with three new conformance cases plus an exhaustive role-by-route
matrix. Test count has risen with every release.

It is in CONTRIBUTING.md's "Hard rules" section, which is the instructions for change proposals.

Three layers. The compiler: a workspace lint table with rustc lints including
missing_docs and missing_debug_implementations, and unsafe_code = "forbid" — no
unsafe code anywhere, unconditionally. The linter: clippy with clippy::all and
clippy::pedantic denied, plus roughly forty individually denied lints covering
panics, indexing, integer casts, iteration determinism and error hygiene. Rust's
safe mode is the default and unsafe is forbidden outright.

CI runs clippy with -D warnings and rustdoc with RUSTDOCFLAGS="-D warnings", so a single warning fails the build and cannot be merged. There is no warning backlog because a warning cannot land.

clippy::pedantic at deny (not warn) is already beyond common practice, alongside
unsafe_code = "forbid", denied panicking APIs including unwrap/expect/panic!/
indexing/string slicing, a banned-API list enforced at compile time
(SystemTime::now, std::env::var, Uuid::new_v4, chrono), and every suppression
required to carry a reason. Release builds additionally set overflow-checks = true
so integer overflow panics rather than silently wrapping into a wrong clinical
value.

The design applies least privilege (four operation classes with role gating; a
separate read-only role; database roles split so the runtime DSN need not own
DDL), defence in depth (authentication, then EHR_ACCESS, then RBAC, then optional
ABAC, then optional SMART scopes, each able only to narrow what the previous
allowed), fail-closed defaults (an unreachable token issuer is 503 rather than an
allow; a policy engine error is a 500, never a permit; an unconfigured resource
kind denies), simplicity in the security-relevant parts (one configuration root,
one authentication middleware, no hand-rolled cryptography), and input validation
against a whitelist derived from the openEHR specifications rather than a blacklist.
The threat model and the design are documented in
https://ferroehr.eu/docs/latest/security.html

The repository is auditable evidence rather than an assertion. SQL injection: no string-built SQL; parameterised queries and sea-query builders, with a CI gate that fails a pull request introducing string-built SQL. Cross-site scripting and CSRF: the API is JSON/XML with no HTML rendering, plus a strict Content-Security- Policy and a per-response header set. Denial of service: per-route body limits, an AQL result ceiling and statement timeout, connection-level slow-header and HTTP/2 stream bounds, and a two-tier rate limiter. XXE and entity expansion: DOCTYPE refused outright and a nesting bound on the XML reader. Credential handling: Argon2id at the OWASP parameter floor, secrets in a non-rendering wrapper type with file-based delivery, and a CI gate that fails a 5xx response body carrying an internal error value. The hardening programme is documented against the OWASP Cheat Sheet Series, one tracked issue per cheat sheet.

TLS 1.3 (RFC 8446) by default via rustls; Argon2id (RFC 9106) for password hashing; JWT/JOSE per RFC 7519 and the RFC 9068 access-token profile; OpenPGP (RFC 4880/9580) for version signatures; SHA-2 and HMAC. Nothing bespoke.

All cryptography comes from established Rust crates — rustls, argon2, jsonwebtoken, rPGP, sha2, hmac, blake3 — and "never hand-roll crypto or token parsing" is a documented hard rule in the project's own contribution rules. FerroEHR implements no cryptographic primitive.

Every cryptographic dependency is FLOSS (Apache-2.0/MIT), and licences are gated in CI by cargo-deny. The stack is pure Rust with no OpenSSL or other C dependency.

TLS: 1.3 only by default, whose cipher suites are all AEAD with 128-bit or stronger keys; TLS 1.2 is a named opt-in and TLS 1.0/1.1 are not selectable at all. JWT: HMAC secrets under 32 bytes are refused at boot, citing RFC 8725 §3.5. Passwords: Argon2id parameters below the OWASP floor (m=19456, t=2, p=1) are a boot error rather than a warning. Every weaker option is disabled by configuration refusal, not by documentation.

No MD4, MD5, single DES, RC4 or Dual_EC_DRBG anywhere in a default path. The JWT
validator refuses the "none" algorithm and binds the accepted algorithm set to
the key source. TLS 1.3-only by default means no legacy cipher modes are reachable.

No SHA-1 in any security decision. CBC is not reachable under the TLS 1.3 default. Where SHA-256 is used for a non-signature purpose it is stated as such — for example, a verified-Basic-credential cache keys on a SHA-256 digest of the presented header, never on plaintext.

TLS 1.3 mandates ephemeral (X)DHE key agreement, so forward secrecy is a property of the default configuration rather than an option. The TLS floor defaults to 1.3 precisely so this is not left to negotiation.

Argon2id in PHC string format with a per-user salt. FerroEHR never stores or accepts a plaintext password: the configuration takes an Argon2id PHC hash, and a hash that is unparsable, uses a different algorithm, or falls below the OWASP parameter floor is refused at boot. The hash also has a file-based delivery route so it need not sit in a configuration file.

Key generation uses rand's OsRng (the operating system CSPRNG) — see
app/ferroehr/src/versioning/signature/key.rs. TLS key material and nonces come
from rustls with the aws-lc-rs provider. Argon2 salts come from the argon2 crate's
CSPRNG-backed generator. Database identifiers use PostgreSQL 18's native uuidv7();
Uuid::new_v4 is on the project's compile-time banned-API list, so a weak or
inappropriate generator cannot be introduced by accident.

Everything is delivered over HTTPS: releases and source from GitHub, container
images and the Helm chart from GHCR. From v3.17.4 onward every release artifact
also carries signed keyless Sigstore provenance, verifiable with
gh attestation verify, and the release binaries reach SLSA v1.0 Build Level 3 —
so a consumer can verify not merely that the transport was secure but that the
artifact came from this repository's hardened build lane.

Nothing is fetched over plain HTTP. Dependencies are pinned by checksum in Cargo.lock and installed with --locked; container base images are pinned by sha256 digest; every GitHub Action is pinned to a full commit SHA. Integrity comes from digests and signatures, never from a hash retrieved insecurely.

There is no unpatched vulnerability in FerroEHR's own code.

Being precise about dependencies rather than silent: cargo-deny runs in CI against
the RustSec database and is green. Six advisories are reported by OSV-based
scanners, and all six are adjudicated in deny.toml with their reasoning — five
have no fixed upstream release available (the rsa timing sidechannel, where this
project only verifies signatures and holds no RSA private key; two quick-xml
advisories reachable only through an S3 client parsing operator-configured
endpoint responses; two unmaintained-crate advisories for compile-time
proc-macros with no runtime surface). The sixth is a false positive: rkyv appears
in Cargo.lock as an optional dependency our feature set never compiles, verified
with cargo tree. Where a finding in an inherited container layer is unreachable,
the argument is published as an OpenVEX document under security/vex/ so a consumer
can check it rather than take it on trust.
https://github.com/rubentalstra/FerroEHR/blob/develop/deny.toml

The clearest example: an internal audit found the canonical-XML reader had no nesting bound, so a deeply nested document could recurse the parser off the stack — and because a Rust stack overflow aborts rather than unwinding, the panic handler that renders this server's clean 500 could not intercept it, making one request able to end the process for every caller. It was fixed in the same cycle it was found, with a nesting bound, an outright DOCTYPE refusal, and six asserted regression tests so the refusals cannot silently disappear.

Secret scanning runs in CI over the whole tree (Trivy secret scanner, plus GitHub secret scanning with push protection enabled), and it is clean. The publishing lanes hold no long-lived credential at all: crates.io publishing uses OIDC Trusted Publishing, and artifact signing uses keyless Sigstore — there is no private key to leak. One credential-shaped string exists deliberately and is documented as such: the downloadable quickstart carries an Argon2id hash for a throwaway development user, because a self-contained demo cannot reference a secret the reader does not have. It is a development credential by construction and the documentation says to replace it before any real use.

Two, on every pull request and every push. CodeQL analyses both the rust and actions languages (.github/workflows/codeql.yml), with results in the repository's code-scanning alerts. Clippy runs with clippy::all and clippy::pedantic denied plus roughly forty additional denied lints. Both must pass before a merge, so no release can be cut without them.

CodeQL's security query suites are exactly this, and the actions language analysis covers workflow-specific classes such as script injection. Alongside it, zizmor audits every workflow for unpinned actions, excessive permissions, template injection and cache poisoning at --min-severity=low, and repository-specific gates fail a pull request that introduces string-built SQL or a 5xx response body carrying an internal error value.

There is no open code-scanning alert. Because clippy runs at -D warnings and CodeQL results gate the pull request, a finding cannot accumulate: it blocks the merge that introduced it.

On every pull request and every push to develop, plus a weekly scheduled CodeQL run and a weekly OpenSSF Scorecard analysis. Clippy runs on every push.

Three kinds. The conformance runner drives a 1049-case catalogue against a live composed deployment on fresh volumes and computes verdicts from the run records — this is the acceptance gate for every release, and the current record is 1014 of 1014 passing. cargo-fuzz (libFuzzer) harnesses fuzz the parsers that read untrusted input: canonical JSON, canonical XML, AQL, the simplified formats, ADL 2 and OPT 1.4. And a measured-performance instrument runs open-loop sustained load against a live server with re-checkable latency histograms.

The project produces no code in a memory-unsafe language. It is entirely Rust, and
unsafe_code = "forbid" applies workspace-wide — a forbid that no attribute can
relax, so a compilation unit cannot opt back in. There is no unsafe block to
protect.

Debug assertions are on in test and fuzz builds. More unusually, release builds set overflow-checks = true, so integer overflow panics in production rather than silently wrapping into a wrong clinical value — an assertion deliberately left enabled where most projects disable it. The fuzz harnesses treat any panic, abort or hang as a finding, and the conformance catalogue asserts refusals as well as successes, so a specification violation that becomes permissive fails the run.

The conformance baseline only ratchets upward: a run showing any regression against the committed baseline blocks the change, and each failing row is attributed to a specific component with the specification citation before anything is altered. Fuzz findings are fixed and then pinned as asserted regression tests so a fixed crash cannot return unnoticed.