Veredictum

Public git repository on GitHub: https://github.com/rubentalstra/Veredictum

git — every change is tracked, and every commit in the history is OpenPGP-signed (the main ruleset refuses an unsigned one).

Every change reaches main as a squash-merged pull request as soon as it is green, so main is the interim version between releases and is publicly readable at https://github.com/rubentalstra/Veredictum/commits/main . CHANGELOG.md accumulates the unreleased entries.

git, a distributed version control system.

One SemVer version per release, held in Cargo.toml, checked against the tag by the release pipeline (the tag matches the manifest version step) and against CITATION.cff and .zenodo.json, and reported by veredictum --version.

Semantic Versioning 2.0.0, stated in CHANGELOG.md and carried by the tags (0.0.1-alpha.1 through 0.1.0-alpha.4): https://github.com/rubentalstra/Veredictum/blob/main/CHANGELOG.md

Every release is a v-prefixed git tag, and the refs/tags/v* ruleset requires the tag to be signed and forbids deleting or moving it: https://github.com/rubentalstra/Veredictum/tags

CHANGELOG.md follows Keep a Changelog 1.1.0, a user-visible change must add its entry in the same pull request (CI enforces this), and the release pipeline extracts that section verbatim as the GitHub release body: https://github.com/rubentalstra/Veredictum/releases

No publicly known vulnerability has been fixed in any release so far, so no release notes name one. When one is fixed, SECURITY.md commits to naming the reporter in the advisory and the changelog, and the CVE with it.

CONTRIBUTING.md points at the tracker with three typed templates, and SUPPORT.md routes questions, instrument defects, disputed catalogue expectations and vulnerability reports separately: https://github.com/rubentalstra/Veredictum/blob/main/SUPPORT.md

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

Every issue in the tracker is triaged and answered; the tracker is the project's working surface rather than an inbox (past #100 filed, 10 open at the time of writing, the rest closed with their resolution recorded). No report has been left without a response.

Enhancement requests use their own template and are answered on the issue: accepted with a milestone, or closed with the reason. GOVERNANCE.md § What this project will not do records the standing refusals in advance, so a request that falls there gets a documented answer: https://github.com/rubentalstra/Veredictum/blob/main/GOVERNANCE.md

The GitHub issue tracker and Discussions are public and permanently readable: https://github.com/rubentalstra/Veredictum/issues?q=is%3Aissue

SECURITY.md: do not open a public issue, report through GitHub private vulnerability reporting, with the expected contents listed: https://github.com/rubentalstra/Veredictum/blob/main/SECURITY.md

GitHub private vulnerability reporting is enabled and is the documented route (https://github.com/rubentalstra/Veredictum/security/advisories/new). SECURITY.md § Repository security settings records it as the posture of record.

No vulnerability report has been received to date, so there is none to have responded to. SECURITY.md commits to an acknowledgement within 5 working days and an assessment with a severity and fix window within 14 calendar days.

cargo builds the workspace from source: cargo build --locked --workspace --all-targets, run on every pull request and push by the CI build & test job. The toolchain pins itself from rust-toolchain.toml, so there is nothing to install by hand.

cargo and rustc, the standard Rust build tooling, with the exact channel pinned in rust-toolchain.toml and the dependency set locked in a committed Cargo.lock.

The whole build runs on FLOSS: rustc and cargo (MIT/Apache-2.0), cargo-nextest, cargo-deny, cargo-hack and cargo-machete, on GitHub-hosted Linux runners.

An automated test suite in the repository: 365 test functions across 61 files, run by cargo nextest run --locked --workspace, plus veredictum validate over the whole artifact tree (every machine gate over the catalogue, zero findings the only passing result) and the verification pack, a recorded transcript with adjudicated verdicts that any runner claiming this catalogue must reproduce.

cargo nextest run (the project's runner by decision, configured in .config/nextest.toml). CONTRIBUTING.md § The gates lists it with the rest of the gate commands.

The suite covers the instrument's functionality rather than a corner of it: 365 tests over the parsers, the artifact model, the assertion vocabulary and the verdict computation, plus the console SSR suite, the catalogue-wide validate gate, the console journey tests and the fuzz harnesses. Coverage is measured by cargo-llvm-cov and published continuously through SonarQube Cloud, whose live badge is in the README badge row: https://sonarcloud.io/component_measures?id=rubentalstra_Veredictum&metric=coverage

.github/workflows/ci.yml runs on every pull request and every push to main, with all jobs (guards, workflow-audit, dockerfile lint, rustfmt, clippy, build and test, rustdoc, MSRV, cargo-deny, fuzz-harness build, unused dependencies, console journeys, screenshot guard) gathered behind a single required conclusion check, and a CI guard that fails if any job is left out of it: https://github.com/rubentalstra/Veredictum/actions/workflows/ci.yml

CONTRIBUTING.md § Pull requests: tests accompany behaviour changes; and § Hard rules: never weaken, skip or delete a test, never edit a test to route around a defect it exposes — leave it failing with a TODO naming its issue. Coverage ratchets up only: https://github.com/rubentalstra/Veredictum/blob/main/CONTRIBUTING.md

The policy is applied in practice: the three document-processing defects found by fuzzing (literal nesting depth, brace-expansion variants, citation-resolution stack overflow) each landed in 0.1.0-alpha.4 with their pinned regression test, and every added catalogue case is its own negative or positive test: https://github.com/rubentalstra/Veredictum/releases

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

Warning flags are on by default and turned up: the workspace lint tables in Cargo.toml put clippy::all and clippy::pedantic at deny, add a long list of named bug-class lints at deny (unwrap_used, expect_used, panic, indexing_slicing, as_conversions, iter_over_hash_type and more), and set rust lints unsafe_code = forbid, dead_code = deny, non_ascii_idents = forbid: https://github.com/rubentalstra/Veredictum/blob/main/Cargo.toml

CI runs cargo clippy --locked --workspace --all-targets -- -D warnings (plus the console's ssr and wasm hydrate targets) and cargo fmt --all --check on every pull request and push, so a warning fails the build and main carries none.

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

ARCHITECTURE.md is the design record, and the security-relevant design is stated rather than assumed: the instrument trusts only the released specifications and its own recorded inputs, a verdict is a pure function of four inputs so no server-controlled value can influence its own result, and records are sealed with a SHA-256 digest manifest and a detached OpenPGP signature that verify-record re-checks. SECURITY.md § Scope notes names the trust boundaries that matter here (credentials for the system under test, verdict integrity, release-artifact integrity): https://github.com/rubentalstra/Veredictum/blob/main/ARCHITECTURE.md

The common error classes are addressed by construction and by machine check: memory unsafety is out of reach (unsafe_code = forbid), the lint set denies the specific classes that produce wrong answers (unwrap/expect/panic, indexing_slicing, string_slice, as_conversions, precedence_bits, integer overflow via overflow-checks in release), every reader that parses outside input has a fuzz harness, and CodeQL plus SonarQube Cloud run their security queries on every pull request.

Only published standard primitives: SHA-256 (FIPS 180-4) for the digest manifest, OpenPGP detached signatures for sealing a record, TLS via rustls for every outbound connection, and JWT (RFC 7519) for bearer authentication against a system under test. Nothing bespoke.

The project implements no cryptography of its own. It calls maintained libraries: sha2, pgp, rustls (through reqwest with default features off), and jsonwebtoken on aws-lc-rs: https://github.com/rubentalstra/Veredictum/blob/main/app/veredictum/Cargo.toml

Every cryptographic dependency is FLOSS under MIT and/or Apache-2.0 (sha2, pgp, rustls, aws-lc-rs, jsonwebtoken), and cargo-deny gates the licence set on every pull request.

SHA-256 digests throughout (no truncation). TLS key exchange and cipher suites are rustls defaults, which are TLS 1.2/1.3 suites at current key sizes. The OpenPGP signing key is the operator's own, and MAINTAINERS.md documents the project's own signing identities.

No broken or known-insecure primitive is used or accepted anywhere: no MD5, no SHA-1, no DES/3DES/RC4, and no TLS below 1.2 (rustls implements 1.2 and 1.3 only).

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.

All network security is standard TLS through rustls, whose default suites are ECDHE (TLS 1.2) and TLS 1.3, both forward-secret. No bespoke transport cryptography exists.

The project stores no passwords for authentication of external users. The web console has no login at all (which is why the publish flag binds it to loopback), and credentials for a system under test are never stored: the party's IXIT declares only the name of the environment variable, so the secret stays in the operator's environment and never enters the catalogue, a record or a log.

Where a cryptographic random value is needed — the nonce in the detached OpenPGP signature over a record manifest — the source is the operating system CSPRNG, rand::rngs::OsRng (app/veredictum/src/exec/signature.rs, app/veredictum/src/record.rs). The seeded arrival schedule in the load generator is deliberately reproducible and is not a security value.

Every delivery channel is HTTPS with an integrity check on top: release binaries carry a sha256sum, a CycloneDX SBOM and a Sigstore bundle verified by gh attestation verify --signer-workflow, container images are pulled by digest from GHCR with provenance attestations, and the crate comes from crates.io over HTTPS. The verification commands are published: https://veredictum.eu/docs/installation.html

No hash or signature is ever delivered over an unsigned or unencrypted channel: checksums and Sigstore bundles are release assets on the HTTPS GitHub release page, attestations are verified against the signing workflow identity rather than a hash published beside the file, and release tags are signed under a ruleset that forbids moving or deleting them.

No vulnerability has been reported in this project to date, so none is outstanding. The machinery to meet the window is in place and running: cargo-deny against the RustSec advisory database on every pull request, Dependabot security updates exempt from the update cooldowns, weekly Trivy scans of the published image that file their own tracking issue, and an accepted-advisory VEX register with a CI guard that refuses an advisory exception without a published OpenVEX justification.

There are no known critical or medium vulnerabilities in this project, publicly reported or otherwise, and none outstanding. SECURITY.md states the only supported version is the most recent release: a fix lands on main and ships in the next tagged release, with no backport line.

No credential is committed. Secret scanning and push protection are enabled on the repository (SECURITY.md § Repository security settings records the posture, including the two sub-settings still to be switched on, with their real state), and the design keeps credentials out of the tree by construction: a party's IXIT declares only the name of the environment variable that carries the credential, and leaking one into an artifact, a log, a recorded exchange or an error message is an in-scope vulnerability in this instrument.

Several static analysers run on every pull request: CodeQL (https://github.com/rubentalstra/Veredictum/actions/workflows/codeql.yml), clippy at deny-tier with -D warnings, SonarQube Cloud (quality gate, reliability, security and maintainability ratings, all live in the README badge row), cargo-deny, cargo-machete, zizmor and actionlint over the workflows, hadolint over the Dockerfile, and Trivy over the published image.

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

Findings are fixed rather than filed: CodeQL and Scorecard results land in GitHub code scanning, cargo-deny failures block the merge, and an accepted advisory is only accepted with a published OpenVEX justification that a CI guard (scripts/checks/vex-advisories.sh) requires — security/vex/ carries the record. SECURITY.md § The Scorecard Branch-Protection warns, adjudicated shows the same treatment applied to each analyser warning first-hand rather than chased as a number.

On every pull request and every push to main, and again on a weekly schedule for CodeQL, Scorecard and the published-image scan. No analysis lane is scheduled-only without also running on the merge path.

cargo-fuzz (libFuzzer) harnesses in their own nightly workspace cover the readers that parse outside input — the citation readers, the decision tables, histogram decoding and the vendored archetype and template corpus packs. The scheduled lane fuzzes weekly (https://github.com/rubentalstra/Veredictum/actions/workflows/fuzz.yml) and CI compiles every harness on each pull request that touches the sources, so the lane cannot rot silently. The full test suite also runs against the instrument as built, and the release profile keeps overflow-checks on.

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