# 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://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 |
|---|---|
| 2.0.x (latest: 2.0.0 on crates.io) | Yes |
| Older than 2.0 | 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](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).