hetzner-rss-processor — Design (DEFERRED)
Status: DEFERRED. Hetzner publishes no first-party security advisories with CVE identifiers in any reachable form. This document records the 2026-05-08 recon (re-confirmed 2026-05-15) so the next person who asks “why is there no Hetzner processor?” can short-circuit the investigation.
1. Overview
- Tier: Tier-2 IaaS (Phase 4)
- Verdict: DEFERRED
- Reason in one sentence: Hetzner runs only an operational status page and ISO 27001 marketing pages — no public channel emits CVE-prefixed advisories, no RSS, no JSON, and the help-center pages cover abuse/phishing reporting policy rather than vulnerabilities.
- Extended dictionary already authored:
internal/critutil/dictionaries/extended/hetzner.json(§15.2). It will sit unused until this doc moves to “implementable”. - Implied processor type if it ever exists:
rss(most likely future shape — Hetzner’s customer comms cadence resembles other DACH-region IaaS that have eventually exposed RSS).
2. Source contract (Phase 0 recon — 2026-05-08, re-confirmed 2026-05-15)
2026-05-15 re-recon: all eight URLs below produce the same result as 2026-05-08. Two additional checks were added this round:
https://www.hetzner.com/.well-known/security.txt— 200 OK (expires 2027-11-11). Advertises an inbound reporting mailbox (security@hetzner.com+ PGP key) for researchers contacting Hetzner. This is the opposite of what we need — it documents how to send reports to Hetzner, not how to consume advisories from them.https://status.hetzner.com/history.rss— 404. Statuspage.io history-RSS export is not enabled for this tenant.
Recon-protocol grid from the plan, walked in order:
| Step | Check | Finding |
|---|---|---|
| 1 | First-party CSAF 2.0 endpoint | None. No provider-metadata.json discoverable on hetzner.com. |
| 2 | First-party CVRF endpoint | None. |
| 3 | First-party RSS / Atom feed | None. https://docs.hetzner.com/security/ returns 404; /news is rate-limited and contains only press/marketing posts (Nokia partnership, certifications). |
| 4 | First-party JSON API listing CVEs | None. |
| 5 | First-party HTML listing → per-bulletin | None. Help-center pages under docs.hetzner.com/general/security-and-identify/ cover abuse/phishing reporting policy, not advisories. |
| 6 | Vendor’s GitHub org publishes Security Advisories | github.com/hetznercloud exists but no Security Advisories tab usage. |
| 7 | CVE alias presence | N/A — no advisory pages exist to inspect. |
| 8 | Anti-bot / chromium required | /news returns HTTP 429 to anonymous fetch (rate-limited, not WAF-blocked); status.hetzner.com is plain Statuspage.io but exposes no security incidents. |
URLs checked:
https://docs.hetzner.com/security/— 404https://status.hetzner.com/— 200; operational status only, incidents are infra (phishing, outages); URL pattern/incident/{uuid}carries no CVE IDshttps://www.hetzner.com/news— 429 (rate-limited)https://docs.hetzner.com/general/security-and-identify/— 200; abuse/phishing policy, no advisorieshttps://docs.hetzner.com/general/company-and-policy/information-security-at-hetzner/— 200; ISO/BSI compliance overview, no feed- Google
site:hetzner.com CVE— zero advisory pages; third-party coverage of any Hetzner incidents lives on bleepingcomputer / itweb / csidb, not on Hetzner itself
11. Deferral rationale + unblock conditions
What we’d accept to flip this to implementable:
- A first-party RSS / Atom feed listing security bulletins with CVE-* in body text (mirrors the Tailscale and Cisco patterns we already ingest).
- A first-party JSON or CSV listing the same.
- Hetzner adopting the GitHub Security Advisories tab on
github.com/hetznercloud.
Related work that may obviate this entirely:
- Hetzner is a thin-margin IaaS reseller; the Linux kernel CVEs that
affect their VPS fleet are already covered by
cisa-kev,nist-nvd, and the per-distro processors (Debian / Ubuntu / Alma). A first-party Hetzner feed would only matter for advisories specific to Hetzner’s own control-plane software (Cloud Console, Hetzner Robot), which they have never publicly disclosed.
What to do if a customer asks for it now:
- Tell them Hetzner advisories are received privately via customer email notifications and there is no public feed to scrape. Recommend their own SIEM rule against the customer-email mailbox if they want VDB coverage.
Recheck cadence: every 6 months. The next recheck is 2026-11-15.
Re-walk the URLs above (including the two added 2026-05-15:
.well-known/security.txt and status.hetzner.com/history.rss); if any
returns CVE-prefixed bulletins — or if .well-known/csaf/provider-metadata.json
ever materialises — lift this deferral and write the implementable doc.
Mermaid architecture / data-flow / decision-tree diagrams (matching the
other processor docs) should be authored at that point, not before:
diagramming a pipeline that does not exist would contradict the DEFERRED
status this page carries.
S3 Persistence
Not used. This processor does not currently archive payloads or quarantine failures to S3. Per the S3 Persistence Contract this is non-compliant — see the compliance matrix for the implementation roadmap.
⚠ Not in the compliance matrix — status needs verification.
Expected paths when implemented:
- Archive:
hetzner/files/{sha256}/{filename} - Quarantine:
failed-feeds/hetzner-rss-processor/{YYYY-MM-DD}/{reason}/{filename} - Likely reasons: (none documented)