Security policy
This policy covers the Holger crates in this repository (the holger server, the holger-* crates, the downstream gateway and the CLI), the Holger appliance and estate builds, and the hosted service at https://www.holger.rs. The console (holger-ui) follows the same policy.
Report a vulnerability privately
Write to holger@holger.rs. Start the subject line with SECURITY:.
Do not open a public issue for a vulnerability, and do not push a proof of concept to a public repository. If you want an encrypted channel, say so in a short first mail without details, and we agree on one with you (for example an age key).
What to put in a report
- The version (
holger --version) or the commit, and the crate. - The build: the default build, or the features you turned on (for example
online,jobs,downstream, or the appliance or metered build). - The part of Holger it is in, if you know it: an intake step, a scanner, the provenance verifier, the sync protocol, a package door (Maven, npm, cargo, Python, OCI, Go, APK), the console or the API.
- How to reproduce it: the steps, the
holger.ron, the artifact if one is needed, and a proof of concept if you have one. - What an attacker gains, as you see it. For Holger this includes an artifact that reaches AVAILABLE without passing the steps it should have passed.
- Whether you plan to publish, and when.
- The name you want in the credit, or that you want none.
What happens next
- We acknowledge your report within 14 days.
- We tell you whether we accept it as a vulnerability, and we keep you informed while we work on it.
- Our target is a fix or a documented mitigation within 60 days of the report. For a critical vulnerability we aim for 14 days.
- We agree the publication date with you. By default we publish when the fix is released, and at the latest 90 days after the report.
- We credit you in the CHANGELOG and in the advisory, unless you ask us not to.
Supported versions
Only the latest release line gets security fixes.
| Version | Supported |
| 3.1.x (latest: 3.1.0 on crates.io) | Yes |
| Older than 3.1 | No |
A fix lands on main first and ships in the next release on the supported line.
How fixes are announced
- Every release has a section in CHANGELOG.md. It lists each fixed vulnerability with its CVE, RUSTSEC or GHSA id.
- For a vulnerability in Holger's own code, we publish a RustSec advisory for the affected crate (https://rustsec.org), and we request a CVE or a GHSA where one applies.
- For a vulnerability in a dependency, the CHANGELOG names the upstream advisory and the version that fixes it.
Dependency advisories
deny.toml and cargo-deny check the lock against the RustSec advisory database (cargo deny --locked check advisories). An advisory fails the check unless deny.toml ignores it, and every ignore there states its reason. An ignore is only for an advisory that has no fixed version and that we have checked cannot be reached in Holger (for example RUSTSEC-2026-0387 in crypto-bigint 0.5.5, which reaches Holger only through the PGP signature check, where Holger uses public keys only).