Veredictum

Actively maintained: four releases in the current cycle (0.0.1-alpha.1 through 0.1.0-alpha.4, the latest on 2026-08-27), a tracker past #100 under continuous triage, Dependabot plus a scheduled latest-deps lane and a weekly published-image scan that files its own tracking issue, and CHANGELOG.md accumulating entries between cuts: https://github.com/rubentalstra/Veredictum/releases

GitHub Issues, with three typed templates (defect, enhancement, task), labels and milestones, used for both defects and enhancement requests: https://github.com/rubentalstra/Veredictum/issues

SECURITY.md § Credit: reporters are named in the advisory and the changelog by default, using whatever name and link they give, and declining credit costs nothing and changes nothing about how the report is handled: https://github.com/rubentalstra/Veredictum/blob/main/SECURITY.md

SECURITY.md § Reporting a vulnerability and § What you can expect: private reporting through GitHub Security Advisories, an acknowledgement within 5 working days with a documented public-escalation fallback if it does not arrive, an assessment with a severity and an intended fix window within 14 calendar days, and a coordinated disclosure date agreed with the reporter rather than imposed. Safe harbour is stated. The commitments are framed as commitments to the reporter, not conditions on them: https://github.com/rubentalstra/Veredictum/blob/main/SECURITY.md

CONTRIBUTING.md documents the standards and CLAUDE.md carries the full set: rustfmt, clippy at pedantic-deny, the comment form (line comments only, RFC 505 and RFC 1574, with budgets and typed TODO/NOTE conventions), the citation rule for every expectation, and the test discipline. The machine-readable half is in the repository as configuration: rustfmt.toml, clippy.toml and the workspace lint tables in Cargo.toml: https://github.com/rubentalstra/Veredictum/blob/main/CONTRIBUTING.md

Enforced on every pull request and push, not advisory: cargo fmt --all --check, cargo clippy --locked --workspace --all-targets -- -D warnings (plus the console's ssr and wasm hydrate targets), scripts/checks/comment-style.sh over the whole tree, changelog-structure and same-PR changelog-entry guards, a REUSE lint, an image-label guard, a VEX-advisory guard, zizmor and actionlint over the workflows and hadolint over the Dockerfile — all behind one required conclusion check, with a guard that fails if any job is left out of it: https://github.com/rubentalstra/Veredictum/actions/workflows/ci.yml

The build is cargo end to end, with no bespoke wrapper to swallow anything: it honours the standard cargo and rustc environment conventions (RUSTFLAGS, CARGO_*, profile overrides in Cargo.toml), and native dependencies built through the cc crate honour CC and CFLAGS in the usual way. Nothing in the repository replaces a passed-in flag set.

Deliberate, and commented as such in Cargo.toml: the release profile keeps debug = "line-tables-only" so a production panic names its file and line, and strip stays at its default of none because stripping symbols makes traces incomprehensible. overflow-checks = true is kept on in release for the same reason. Nothing strips by default: https://github.com/rubentalstra/Veredictum/blob/main/Cargo.toml

One cargo workspace with one dependency graph, which cargo builds as a single DAG. There is no recursive make and no per-directory build.

CI builds with --locked against the committed Cargo.lock and a compiler pinned by rust-toolchain.toml; the container build pins its base images by digest (the builder and gcr.io/distroless/cc-debian13:nonroot both by sha256) and a release step checks that the container, rust-toolchain.toml and the Dockerfile agree on the toolchain; release binaries build inside reusable workflows per GitHub's SLSA Build L3 construction and each carries a signed provenance attestation on its digest. A rebuild resolves identical inputs.

Three install paths, all published: prebuilt x86_64 and aarch64 Linux binaries attached to every release with a sha256sum, a CycloneDX SBOM and a Sigstore bundle; a multi-architecture container image on GHCR (ghcr.io/rubentalstra/veredictum); and the crate on crates.io (cargo install veredictum). The installation chapter carries the commands, including the gh attestation verify invocation: https://veredictum.eu/docs/installation.html

Each path follows its ecosystem's own convention rather than inventing one: cargo install honours CARGO_INSTALL_ROOT and --root for the install location (and cargo uninstall removes it), the release tarballs are relocatable single static binaries extracted wherever the operator chooses, and the container image is addressed by tag or digest with the catalogue and specification roots passed in as mounted paths rather than baked in.

git clone, then cargo run -- validate --root artifacts --specs specs/openehr — the toolchain pins itself from rust-toolchain.toml, so there is nothing to install by hand, and cargo-nextest is the only extra tool and only if you intend to run the suite. CONTRIBUTING.md § Setup and § The gates carry the full sequence: https://github.com/rubentalstra/Veredictum/blob/main/CONTRIBUTING.md

Computer-processable, at three levels: Cargo.toml declares the direct dependency set with each pin commented for why it is there, the committed Cargo.lock is the exact resolved graph (this repository ships a binary, so it is committed deliberately), and every release attaches a generated SPDX repository SBOM plus a per-artifact CycloneDX SBOM, both Sigstore-attested. REUSE.toml declares the licensing of the vendored trees machine-readably: https://github.com/rubentalstra/Veredictum/blob/main/Cargo.toml

Four lanes, all running: cargo-deny checks the graph against the RustSec advisory database on every pull request and push; Dependabot raises bump PRs with security updates exempt from the configured cooldowns; a scheduled latest-deps workflow detects in-range upstream breakage; and a weekly Trivy scan of the published container image files or updates its own tracking issue. An accepted advisory needs a published OpenVEX justification in security/vex/, which scripts/checks/vex-advisories.sh enforces: https://github.com/rubentalstra/Veredictum/blob/main/deny.toml

Every reused component is identified and updateable in place. Rust dependencies are ordinary cargo pins in one workspace table with a committed lockfile — no vendored or forked crate copies exist. The vendored material that does exist is specification text and clinical-model corpora, not code: it is fetched by committed scripts (scripts/vendor/adl2-archetypes.sh, ckm-archetypes.sh, ckm-templates.sh), hand-editing it is a hard rule violation, and the fix for any finding inside it is always the script plus a re-run, so an update is a re-vendor rather than a patch to maintain.

The interface documentation is generated from the same source tree, so it cannot lag the code: the published API documentation is complete (https://docs.rs/veredictum — 100% of the crate documented, with missing_docs as a lint), the JSON Schemas in schemas/ are emitted by the instrument itself and drift-tested against the committed copies, and scripts/checks/site-counts.sh fails if the counts the site states disagree with what validate reports. The command reference chapter documents every subcommand: https://veredictum.eu/docs/commands.html

Integration testing runs above the unit level on every pull request and push: cargo nextest run over the whole workspace including the console's SSR suite, veredictum validate over the entire artifact tree (every machine gate over 1103 cases and 247 bindings, zero findings the only passing result), the console journey tests driving the composed console end to end through a browser, and a screenshot guard that fails when a new screen arrives without a capture. An opt-in mode (UI_E2E_REAL_SUTS=1) composes two real CDRs — FerroEHR's published quickstart and EHRbase's official image pairing — and drives the full wizard against each: https://github.com/rubentalstra/Veredictum/actions/workflows/ci.yml

Applied as a rule rather than a habit: CONTRIBUTING.md § Hard rules forbids weakening, skipping or deleting a test or editing one to route around the defect it exposes, and requires a failing test with a TODO naming its issue when the fix is unclear. In practice, the three document-processing defects the fuzzing lane found (literal nesting depth, brace-expansion variants, a citation-resolution stack overflow) each shipped in 0.1.0-alpha.4 with its pinned regression test and its corpus entry kept: https://github.com/rubentalstra/Veredictum/releases

Statement coverage is above 80%, measured by cargo-llvm-cov and published continuously by SonarQube Cloud, whose live coverage badge sits in the README badge row: https://sonarcloud.io/component_measures?id=rubentalstra_Veredictum&metric=coverage . The Sonar lane runs the suite under cargo-llvm-cov and imports the merged lcov through sonar.rust.lcov.reportPaths on every pull request and push. The coverage denominator is deliberately narrower than the analysis scope, with each exclusion carrying its reason in sonar-project.properties: the suite does not measure itself, the CLI entry point is argument plumbing over library functions the suite already drives, and the two document-renderer modules are checked by regenerate-and-diff against committed artifacts rather than by a unit assertion.

CONTRIBUTING.md § Pull requests requires tests to accompany behaviour changes and § Hard rules makes the test discipline non-negotiable (never weaken, skip or delete a test; coverage ratchets up only; a case is added, never removed to make a run green). CI refuses a pull request whose suite is not green, behind the single required conclusion check: https://github.com/rubentalstra/Veredictum/blob/main/CONTRIBUTING.md

Documented in CONTRIBUTING.md as a stated requirement on every contributor, with the full working discipline in CLAUDE.md, and the gate commands listed so a contributor can run exactly what CI will run: https://github.com/rubentalstra/Veredictum/blob/main/CONTRIBUTING.md

Well beyond the defaults. The workspace lint tables put clippy::all and clippy::pedantic at deny and then name dozens of specific bug-class lints at deny (unwrap_used, expect_used, panic, panic_in_result_fn, indexing_slicing, string_slice, as_conversions, iter_over_hash_type, precedence_bits, unchecked_time_subtraction, allow_attributes_without_reason and more, each with its reason in a comment), and the rust table sets unsafe_code = forbid, non_ascii_idents = forbid, dead_code = deny and let_underscore_drop/lock = deny. CI runs clippy with -D warnings on every target, so any of them fails the build: https://github.com/rubentalstra/Veredictum/blob/main/Cargo.toml

The security-relevant design is structural, and ASSURANCE_CASE.md § 2 states the boundaries it rests on (https://github.com/rubentalstra/Veredictum/blob/main/ASSURANCE_CASE.md). A verdict is a pure function of four inputs — the party's statement, the recorded results, the catalogue and the capability matrix — so no server-controlled value can influence its own result, and two independent runners given those inputs must compute identical verdicts; the verification pack exists to check exactly that, so the instrument is not trusted on its own word. The system under test is untrusted by definition: its responses are evidence in a comparison, never instructions, and an expectation is refuted by a better reading of the released specification and by nothing else. Records are sealed with a byte-deterministic SHA-256 digest manifest and a detached RFC 9580 signature that verify-record recomputes — and that plain gpg --verify checks without this binary present — with typed refusals for a manifest entry that would read outside the bundle or silently replace another digest; a performance class is re-derived from the embedded HDR histograms rather than read from a stored summary. Credentials are unrepresentable inline: the IXIT holds environment-variable names and a declared key path, never a secret. Least privilege in the supply chain: ephemeral per-run tokens, crates.io Trusted Publishing with no stored token, and a reviewer-gated environment on the one irreversible leg.

No broken or weak primitive is used or accepted: SHA-256 throughout with no truncation, no MD5, no SHA-1, no DES/3DES/RC4, and TLS through rustls, which implements 1.2 and 1.3 only. Signature verification is a real check rather than a formality — verify-record recomputes every digest and verifies the detached signature, so a substituted byte fails.

Nothing is embedded and nothing needs a recompilation to change. A credential for the system under test never enters the repository at all: the party's IXIT declares only the NAME of the environment variable that carries it, so the secret stays in the operator's environment and out of the catalogue, the records and the logs. The signing key is a file path passed as --sign-key at the moment it is used and is never stored by the tool. The project's own publishing credentials store no secret either — the release lane runs on an ephemeral per-run GITHUB_TOKEN and the crate publishes through crates.io Trusted Publishing (OIDC), as recorded identity by identity in MAINTAINERS.md: https://github.com/rubentalstra/Veredictum/blob/main/MAINTAINERS.md

All network security uses standard published protocols, never bespoke transport cryptography: TLS through rustls on every outbound connection (reqwest is configured with default features off and the rustls feature on, so no platform TLS backend is silently substituted), and JWT (RFC 7519) bearer authentication against a system under test.

The TLS stack is rustls, which implements TLS 1.2 and 1.3 only — an older protocol version is not representable in the library, so there is nothing to disable and no configuration switch that could re-enable one.

rustls with webpki certificate verification is the default on every outbound TLS connection, and there is no escape hatch: no danger_accept_invalid_certs, no accept_invalid_hostnames and no insecure or no-verify option is exposed anywhere in the configuration surface or the code.

Certificate verification happens before anything private is sent: the client is rustls with webpki verification and no way to switch it off, so the JWT bearer token and any basic-auth credential for the system under test only ever travel over a verified TLS session. Private keys are never transmitted or logged — signing is done locally from a key path the operator passes, only the detached signature leaves the process, and pointer_format is a denied lint so addresses cannot leak into Debug output either.

Every release is cryptographically signed and independently verifiable. Each artifact carries a Sigstore bundle and a provenance attestation on its digest, built inside reusable workflows per GitHub's documented SLSA Build L3 construction, alongside sha256 sums, a per-artifact CycloneDX SBOM and a generated SPDX repository SBOM that is itself attested; a release step refuses to publish unless every expected asset is attached, and immutable releases are enabled so the assets and tag freeze at publish. Verification is a documented one-liner — gh attestation verify <artifact> -R rubentalstra/Veredictum --signer-workflow rubentalstra/Veredictum/.github/workflows/release-build.yml : https://veredictum.eu/docs/installation.html

Release tags are OpenPGP-signed by the maintainer key documented in MAINTAINERS.md, and this is enforced rather than customary: the refs/tags/v* ruleset (no bypass) requires a signature and forbids deleting or non-fast-forward-updating a tag, which protects the exact window in which a tag drives the release build. Every commit in the history is signature-verified under the main ruleset as well: https://github.com/rubentalstra/Veredictum/tags

Input is validated against a whitelist by construction, not sanitized after the fact. Artifact and party documents are read through strict typed constructors and refused on undeclared or duplicate keys; the catalogue itself is gated by veredictum validate, where zero findings is the only passing result (id uniqueness, citation resolution against the vendored specification text, binding completeness, and coverage of the enumerated wire surface); AQL and citation input is parsed by grammar-exact parsers that reject rather than guess; and every refusal is kept as its own pinned negative test, so a lenient acceptance is a failing test. The lint set removes the classic silent-acceptance paths (indexing_slicing, string_slice, as_conversions all denied). Every reader that parses outside input has a fuzz harness: https://github.com/rubentalstra/Veredictum/blob/main/fuzz/README.md

The container image is hardened and the hardening is machine-checked: a digest-pinned distroless base (gcr.io/distroless/cc-debian13:nonroot) with an explicit numeric USER 65532:65532 so an orchestrator does not have to resolve a name, no shell and no package manager in the runtime layer, a HEALTHCHECK, OCI metadata that a CI guard (scripts/checks/image-labels.sh) checks agrees with itself, hadolint over the Dockerfile on every pull request and Trivy over the published image weekly. The console binds to loopback unless the operator explicitly publishes it. On the process side the release profile keeps overflow-checks = true, and unsafe_code = forbid removes the memory-unsafety class outright: https://github.com/rubentalstra/Veredictum/blob/main/docker/Dockerfile

ASSURANCE_CASE.md is the assurance argument, and every row names a file in this repository so each claim can be opened and checked: https://github.com/rubentalstra/Veredictum/blob/main/ASSURANCE_CASE.md . § 1 states the assets an attacker would want (verdict integrity — a wrong green is the worst outcome the product has; record integrity across the bundle, the release tarball and the image; confidentiality of the operator's inputs). § 2 is the trust-boundary table: the catalogue and vendored specifications as trusted-and-gated (validate at zero findings, entry point named), the system under test as untrusted by definition (its responses are evidence in a comparison, never instructions, and it cannot move the reference it is measured against), the operator's IXIT holding credential references only so an inline secret is unrepresentable, every console #[server] fn as a public endpoint bound to loopback by default, and the published record as tamper-evident without this tool (byte-deterministic SHA-256 manifest plus an RFC 9580 detached signature that plain gpg --verify checks). § 3 pairs each security-relevant requirement with the check that fails on violation (unsafe_code = forbid, the denied panic and indexing families, overflow-checks, typed errors at every branching boundary). § 4 names the three rules enforced by review alone rather than hiding them — on the project's own principle that a rule with no failing check is a wish. § 5 states what the case does not claim: no formal verification, no console authentication by design, no sanitizing of what is recorded, and that a verified signature says nothing about the conditions the run executed under. The reporting route stays in SECURITY.md, and a stale claim on that page is handled as a defect in the assurance case.

At least one analyser looks specifically for common vulnerability classes on every pull request: CodeQL runs its security query suites over the Rust and GitHub Actions sources on every push and pull request and again weekly, SonarQube Cloud publishes a security rating on the same events, zizmor audits the workflows for the Actions-specific classes (unpinned uses, credential-persisting checkouts, injectable contexts) at --min-severity=low, Trivy scans the published image, and cargo-deny checks the graph against the RustSec advisory database: https://github.com/rubentalstra/Veredictum/actions/workflows/codeql.yml

There is no memory-unsafe code to analyse. unsafe_code = "forbid" applies to the whole workspace, and forbid cannot be relaxed by an attribute — not even #[allow] compiles under it — so introducing unsafe would require a deliberate change to stop inheriting the lint table rather than a local suppression. The libFuzzer harnesses still run over every outside-input reader with sanitizer instrumentation regardless: https://github.com/rubentalstra/Veredictum/blob/main/Cargo.toml