Sicherheitslücken melden

Richtlinie zur koordinierten Offenlegung von Schwachstellen. Stand: 24.09.2026.

1. Worum es geht

Sicherheit hat bei Frederich Engineering Vorrang vor Geschwindigkeit und Funktionen. Wenn Sie eine Sicherheitslücke in einem unserer Produkte oder Dienste finden, möchten wir davon erfahren, um sie schnell zu beheben. Diese Richtlinie beschreibt, wie Sie melden, was Sie von uns erwarten können und welche Regeln für Ihre Tests gelten.

2. Geltungsbereich

• Klarfeed Cloud (klarfeed.app) und die Klarfeed-Website (klarfeed.com)
• Software von Frederich Engineering, die wir verkaufen oder veröffentlichen (z. B. Klarfeed zum Selbst-Hosten), in der jeweils aktuellen Version
• unsere Firmen-Website frederich-engineering.com

Nicht im Geltungsbereich sind Dienste Dritter, die wir nutzen (z. B. Stripe, Hetzner, unser E-Mail-Anbieter) -- bitte melden Sie dort direkt -- sowie Feeds und Websites Dritter, die in Klarfeed angezeigt werden.

3. So melden Sie

E-Mail an security@frederich-engineering.com, möglichst mit:

• betroffenem Produkt oder Dienst und Version bzw. URL,
• Beschreibung der Lücke und ihrer Auswirkung,
• Schritten zum Nachvollziehen (Proof of Concept),
• Ihrem Namen oder Pseudonym, wenn Sie genannt werden möchten.

Sie können auf Deutsch oder Englisch schreiben. Bitte verschlüsseln Sie vertrauliche Details mit unserem PGP-Schlüssel (RSA 4096, gültig bis 30.06.2027), Fingerabdruck:
2D28 1AA4 8156 6C99 B747 6DEB 7E91 8184 7FC9 FEFE

4. Was Sie von uns erwarten können

Wir sind ein kleines Unternehmen und versprechen nur, was wir halten können:

• Eingangsbestätigung innerhalb von 3 Werktagen.
• Erste Einschätzung (bestätigt / nicht nachvollziehbar / kein Sicherheitsproblem) innerhalb von 10 Werktagen.
• Wir halten Sie über den Stand der Behebung auf dem Laufenden.
• Behebung: kritische Lücken so schnell wie möglich, Ziel für alle bestätigten Lücken höchstens 90 Tage.
• Veröffentlichung: abgestimmt mit Ihnen; Standard ist nach der Behebung, spätestens 90 Tage nach der Meldung, sofern wir nichts anderes vereinbaren. Auf Wunsch nennen wir Sie als Finder.
• Wo sinnvoll, beantragen wir eine CVE-Kennung.
• Wir erfüllen unsere gesetzlichen Meldepflichten, insbesondere nach dem EU Cyber Resilience Act.

Wir zahlen derzeit keine Prämien (kein Bug-Bounty-Programm).

5. Regeln für Tests und unsere Zusage

Wenn Sie in gutem Glauben und nach diesen Regeln handeln, werden wir keine Strafanzeige stellen und keine zivilrechtlichen Schritte gegen Sie einleiten. Wir können nicht für Dritte (z. B. Behörden) sprechen, bestätigen aber auf Nachfrage, dass Ihre Tests im Rahmen dieser Richtlinie lagen.

• Testen Sie nur mit eigenen Konten und eigenen Daten. Für Klarfeed Cloud können Sie uns um einen Testzugang bitten.
• Greifen Sie nicht auf Daten anderer Nutzer zu. Stoßen Sie doch darauf: sofort aufhören, nichts speichern oder weitergeben, und uns melden.
• Keine Tests, die den Dienst beeinträchtigen (Denial of Service, Lasttests, Massen-Anfragen, Spam).
• Kein Social Engineering, kein Phishing, kein physischer Zugriff; keine Angriffe auf unsere Mitarbeiter, Dienstleister oder Hoster.
• Nutzen Sie eine Lücke nur so weit, wie es für den Nachweis nötig ist; keine Hintertüren, keine dauerhaften Änderungen.
• Veröffentlichen Sie Details erst nach Abstimmung mit uns (Abschnitt 4).

6. Was wir in der Regel nicht als Lücke behandeln

• Berichte automatischer Scanner ohne nachgewiesene Auswirkung
• fehlende Sicherheits-Header oder Cookie-Flags ohne konkreten Angriff
• Self-XSS, Clickjacking auf Seiten ohne sicherheitsrelevante Aktion
• SPF-/DKIM-/DMARC-Hinweise, Banner- und Versionsangaben
• Denial of Service durch reine Last
• Angriffe, die ein bereits kompromittiertes Gerät oder physischen Zugriff voraussetzen

Im Zweifel: melden Sie trotzdem.

Report a vulnerability

Coordinated vulnerability disclosure policy. Last updated: 2026-09-24.

1. Purpose

At Frederich Engineering, security comes before speed and features. If you find a security vulnerability in one of our products or services, we want to hear about it so we can fix it quickly. This policy explains how to report, what you can expect from us, and the rules for your testing.

2. Scope

• Klarfeed Cloud (klarfeed.app) and the Klarfeed website (klarfeed.com)
• Software by Frederich Engineering that we sell or publish (e.g. self-hosted Klarfeed), current version
• our company website frederich-engineering.com

Out of scope: third-party services we use (e.g. Stripe, Hetzner, our e-mail provider) -- please report to them directly -- and third-party feeds and websites shown in Klarfeed.

3. How to report

E-mail security@frederich-engineering.com, ideally with:

• the affected product or service and version or URL,
• a description of the issue and its impact,
• steps to reproduce (proof of concept),
• your name or handle if you would like to be credited.

English or German is fine. Please encrypt sensitive details with our PGP key (RSA 4096, valid until 2027-06-30), fingerprint:
2D28 1AA4 8156 6C99 B747 6DEB 7E91 8184 7FC9 FEFE

4. What you can expect from us

We are a small company and only promise what we can keep:

• Acknowledgement within 3 business days.
• Initial assessment (confirmed / not reproducible / not a security issue) within 10 business days.
• We keep you updated on the fix.
• Fix: critical issues as fast as possible, target for every confirmed issue 90 days at most.
• Disclosure: coordinated with you; by default after the fix, at the latest 90 days after your report, unless we agree otherwise. We credit you if you wish.
• Where appropriate, we request a CVE ID.
• We meet our legal reporting obligations, in particular under the EU Cyber Resilience Act.

We currently pay no rewards (no bug bounty).

5. Testing rules and our commitment

If you act in good faith and follow these rules, we will not file a criminal complaint or take civil action against you. We cannot speak for third parties (e.g. authorities), but on request we will confirm that your testing was within this policy.

• Test only with your own accounts and data. For Klarfeed Cloud you can ask us for a test account.
• Do not access other users' data. If you come across it anyway: stop, do not keep or share it, and tell us.
• No testing that degrades the service (denial of service, load tests, mass requests, spam).
• No social engineering, phishing or physical access; no attacks on our staff, contractors or hosting providers.
• Exploit an issue only as far as needed to demonstrate it; no backdoors, no persistent changes.
• Publish details only after coordinating with us (section 4).

6. What we usually do not treat as a vulnerability

• automated scanner reports without demonstrated impact
• missing security headers or cookie flags without a concrete attack
• self-XSS, clickjacking on pages without a security-relevant action
• SPF/DKIM/DMARC findings, banners and version disclosure
• denial of service by sheer volume
• attacks that require an already compromised device or physical access

When in doubt, report anyway.