Sicherheitsrichtlinie

Version	2026-09-29
Relevant für	Nutzer der AtroCore-Plattform, Sicherheitsforscher

1. Zweck und Geltungsbereich

1.1. Diese Richtlinie beschreibt, welche Versionen von AtroCore Fehlerbehebungen und Sicherheitsupdates erhalten, wie Schwachstellen eingestuft und beseitigt werden, wie Sicherheitsupdates veröffentlicht werden und wie Sie uns eine Schwachstelle melden können. Sie legt außerdem die Regeln für Sicherheitsforschung an AtroCore sowie unsere Zusagen gegenüber Personen fest, die Schwachstellen in gutem Glauben melden.

1.2. Diese Richtlinie gilt für:

die AtroCore-Plattform und die von der AtroCore GmbH bereitgestellten Module, einschließlich der REST-API und der Import-/Export-Feed-Schnittstellen
die von der AtroCore GmbH betriebenen SaaS-Umgebungen
die öffentlichen Websites und Webanwendungen der AtroCore GmbH.

1.3. Schwachstellen in in AtroCore enthaltenen Komponenten Dritter, etwa in Bibliotheken, fallen in den Geltungsbereich dieser Richtlinie; wir beseitigen sie in AtroCore. Software und Dienste Dritter, die nicht Bestandteil von AtroCore sind und nicht von der AtroCore GmbH betrieben werden, fallen nicht in ihren Geltungsbereich; bitte melden Sie solche Probleme direkt dem jeweiligen Hersteller.

2. Unterstützte Versionen

2.1. Sicherheitsupdates

2.1.1. Die AtroCore-Plattform und jedes Modul haben eigene Versionsnummern, die jeweils aus einer Haupt-, einer Neben- und einer Patch-Nummer bestehen. Sicherheitsupdates werden für fünf Jahre ab dem Zeitpunkt bereitgestellt, zu dem die betreffende Version erstmals in der Europäischen Union bereitgestellt wurde:

Produkt	Erhält Sicherheitsupdates für	Bereitgestellt als
AtroCore-Plattform und kostenlose Module	Jede Hauptversion	Patch-Release der neuesten Nebenversion dieser Hauptversion
Kostenpflichtige Module	Jede Nebenversion	Patch-Release dieser Nebenversion

2.1.2. Für die Plattform und die kostenlosen Module betreiben Sie die neueste Nebenversion Ihrer Hauptversion, um Sicherheitsupdates zu erhalten. Releases innerhalb einer Hauptversion entfernen keine dokumentierte Funktionalität, sodass die Aktualisierung auf die neueste Nebenversion Ihrer Hauptversion keine Anpassung Ihrer Integrationen erfordert.

2.1.3. Innerhalb einer Hauptversion der Plattform bleiben neue Nebenversionen mit den für diese Hauptversion veröffentlichten Modulversionen kompatibel. Sie können die Sicherheitsupdates der Plattform daher stets installieren, auch wenn Sie Ihre Module nicht aktualisieren.

2.1.4. Für kostenpflichtige Module benötigen Sie kein laufendes Update-Abonnement, um sicher zu bleiben. Sie behalten die Nebenversion, die Sie besitzen, und erhalten deren Sicherheitsupdates als Patch-Releases dieser Nebenversion.

2.1.5. Das Ende des Unterstützungszeitraums jeder Version ist in der AtroCore-Dokumentation unter help.atrocore.com angegeben.

2.1.6. Nach dem Ende des Unterstützungszeitraums erhält eine Version keine Sicherheitsupdates mehr. Um weiterhin Sicherheitsupdates zu erhalten, aktualisieren Sie auf eine Version, die noch unterstützt wird.

2.2. Fehlerbehebungen

2.2.1. Fehlerbehebungen werden im neuesten Release der aktuellen Hauptversion bereitgestellt. Nutzer einer früheren Hauptversion erhalten Fehlerbehebungen durch die Aktualisierung auf die aktuelle Hauptversion. Supportverträge können weitere Versionen vorsehen.

2.3. Fehler und Schwachstellen

2.3.1. Ein Mangel, der ausgenutzt werden kann, um die Vertraulichkeit, Integrität oder Verfügbarkeit von AtroCore oder der damit verarbeiteten Daten zu beeinträchtigen, wird als Schwachstelle behandelt, nicht als Fehler. Dazu gehören auch Mängel, die es einem Angreifer ermöglichen, die Software zum Absturz zu bringen oder unverfügbar zu machen. Schwachstellen werden in jeder unterstützten Version beseitigt, wie in Abschnitt 2.1 beschrieben.

2.4. Kunden mit Lizenz- oder Servicevertrag

2.4.1. Kunden, die eine Lizenz für kostenpflichtige Module besitzen, haben nach Ziffer 10 der Endbenutzer-Lizenzvereinbarung (EULA) von AtroCore weitere Rechte.

2.4.2. Kunden, deren AtroCore-Umgebung von der AtroCore GmbH als SaaS-Dienst betrieben wird, müssen nichts unternehmen: Wir installieren die Sicherheitsupdates in diesen Umgebungen selbst.

2.4.3. Kunden mit einem Lizenz- oder Servicevertrag, die AtroCore selbst betreiben, bieten wir unabhängig von ihrem Supportpaket an, jedes Sicherheitsupdate in ihrer Umgebung durch die AtroCore GmbH zu installieren. Das Angebot erfolgt mit der Benachrichtigung nach Abschnitt 4.4.1.

3. Einstufung des Schweregrads

3.1. Wir stufen den Schweregrad jeder bestätigten Schwachstelle nach den folgenden Klassen ein:

Schweregrad	Beschreibung
Kritisch	Schwachstellen, die einen unbefugten Zugriff auf sensible personenbezogene Daten oder vertrauliche Kundendaten, die Ausführung von Code aus der Ferne oder die vollständige Kompromittierung eines Systems ermöglichen oder die wahrscheinlich zu einer Verletzung des Schutzes personenbezogener Daten führen
Hoch	Schwachstellen, die einen erheblichen unbefugten Zugriff auf Systeme oder Daten, eine Rechteausweitung oder die Umgehung zentraler Authentifizierungs- oder Autorisierungskontrollen ermöglichen
Mittel	Schwachstellen, die ein nennenswertes Sicherheitsrisiko darstellen, deren Ausnutzung jedoch besondere Bedingungen oder eine Mitwirkung des Nutzers erfordert oder die sich nur begrenzt auf die Vertraulichkeit, Integrität oder Verfügbarkeit von Daten auswirken
Niedrig	Schwachstellen mit geringer Ausnutzbarkeit oder Auswirkung, einschließlich informativer Hinweise, geringfügiger Fehlkonfigurationen und Befunde, die ein eher theoretisches als praktisches Risiko darstellen

3.2. Zusätzlich wird jede bestätigte Schwachstelle nach dem Common Vulnerability Scoring System (CVSS) Version 4.0 bewertet. Die Klassen entsprechen den CVSS-Schweregraden wie folgt: Kritisch 9,0–10,0, Hoch 7,0–8,9, Mittel 4,0–6,9, Niedrig 0,1–3,9. Führen der CVSS-Wert und die Beschreibung in Abschnitt 3.1 zu unterschiedlichen Klassen, so ordnen wir die höhere Klasse zu.

4. Veröffentlichung von Sicherheitsupdates

4.1. Sicherheitsupdates werden veröffentlicht, sobald sie fertig sind, nicht nach einem festen Zeitplan. Wir streben an, bestätigte Schwachstellen innerhalb der folgenden Fristen zu beseitigen, gerechnet ab dem Tag, an dem die Schwachstelle bestätigt wurde:

Schweregrad	Zielfrist für die Beseitigung
Kritisch	72 Stunden
Hoch	7 Kalendertage
Mittel	30 Kalendertage
Niedrig	90 Kalendertage

4.2. Sicherheitsupdates sind kostenlos und werden stets als Patch-Releases bereitgestellt, wie in Abschnitt 2.1 beschrieben. Eine Sicherheitsbehebung wird nie ausschließlich in einer neuen Neben- oder Hauptversion bereitgestellt:

Ist das nächste für die betreffende Version geplante Release ein Patch-Release, das innerhalb der Zielfrist nach Abschnitt 4.1 veröffentlicht werden kann, wird die Sicherheitsbehebung in dieses Patch-Release aufgenommen.
Ist das nächste geplante Release eine neue Neben- oder Hauptversion oder kann das geplante Patch-Release nicht innerhalb der Zielfrist veröffentlicht werden, veröffentlichen wir ein eigenes Patch-Release der neuesten Nebenversion, das die Sicherheitsbehebung enthält; die neue Neben- oder Hauptversion enthält sie ebenfalls.

Neue Funktionen sind in einem Sicherheitsupdate nur enthalten, wenn dies unvermeidbar ist, etwa weil die Behebung selbst eine Änderung der Funktionalität erfordert. Ein Sicherheitsupdate kann außerdem weitere Fehlerbehebungen enthalten.

4.3. Sicherheitshinweise und Release Notes

4.3.1. Für jede beseitigte Schwachstelle der AtroCore-Plattform oder ihrer Module, die eine veröffentlichte Version außer einer Beta-Version oder einem Release Candidate betrifft, veröffentlichen wir unabhängig von ihrem Schweregrad einen Sicherheitshinweis. Schwachstellen, die ausschließlich die von der AtroCore GmbH betriebenen SaaS-Umgebungen oder Websites betreffen, beseitigen wir, ohne dass Sie etwas unternehmen müssen, und veröffentlichen hierzu keinen Sicherheitshinweis. Der Sicherheitshinweis beschreibt die Schwachstelle und nennt die betroffenen Versionen, die Schweregradklasse und den CVSS-Wert, die Versionen, mit denen die Schwachstelle beseitigt wird, sowie etwaige Maßnahmen, die Sie ergreifen sollten, bis Sie aktualisieren können.

4.3.2. Wann der Sicherheitshinweis veröffentlicht wird, hängt davon ab, ob die Schwachstelle Angreifern bereits bekannt ist:

Fall	Release Notes des Sicherheitsupdates	Sicherheitshinweis
Die Schwachstelle wird nicht aktiv ausgenutzt und ist nicht öffentlich bekannt	Enthalten zunächst keine Angaben zur Schwachstelle	Wird spätestens 30 Kalendertage nach der Veröffentlichung des Sicherheitsupdates veröffentlicht
Die Schwachstelle wird aktiv ausgenutzt, das heißt, es liegen verlässliche Nachweise vor, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemeigentümers ausgenutzt hat, oder ihre Einzelheiten sind bereits öffentlich bekannt	Kennzeichnen die Sicherheitsbehebung von Anfang an und verweisen auf den Sicherheitshinweis	Wird veröffentlicht, sobald das Sicherheitsupdate veröffentlicht ist

4.3.3. Die Verzögerung gibt Nutzern Zeit, das Sicherheitsupdate zu installieren, bevor Einzelheiten der Schwachstelle öffentlich werden. Wir legen für jede Schwachstelle fest, wie lange die Verzögerung sein muss, höchstens 30 Kalendertage, und verzögern die Veröffentlichung nur so lange, wie Nutzer noch Zeit für die Installation des Sicherheitsupdates benötigen. Erfahren wir vor der Veröffentlichung des Sicherheitshinweises, dass die Schwachstelle aktiv ausgenutzt wird oder öffentlich bekannt geworden ist, veröffentlichen wir den Sicherheitshinweis unverzüglich.

4.3.4. Mit der Veröffentlichung des Sicherheitshinweises ergänzen wir die Release Notes jedes Releases, das die Behebung enthält, um einen Hinweis, der die Sicherheitsbehebung kennzeichnet, mit einem Link auf den Sicherheitshinweis und dessen CVE-Kennung, soweit eine vergeben wurde.

4.4. Veröffentlichung und Benachrichtigung

4.4.1. Wird ein Sicherheitsupdate veröffentlicht, informieren wir jeden Kunden mit einem Lizenz- oder Servicevertrag per E-Mail darüber, welche Versionen Sicherheitsbehebungen enthalten, welcher Schweregradklasse diese angehören und wann der Sicherheitshinweis voraussichtlich veröffentlicht wird, und bieten die Installation des Sicherheitsupdates an (Abschnitt 2.4.3). Bis zur Veröffentlichung des Sicherheitshinweises enthält diese E-Mail keine Einzelheiten der Schwachstelle, und wir bitten die Kunden, sie vertraulich zu behandeln.

4.4.2. Sicherheitshinweise werden als GitHub Security Advisories im jeweiligen Repository veröffentlicht, jeweils mit einer eigenen GHSA-Kennung. Die CVE-Kennung beantragen wir bei GitHub, das CVE-Kennungen für die auf seiner Plattform veröffentlichten Sicherheitshinweise vergibt. Sie können Sicherheitshinweise abonnieren, indem Sie das Repository für Sicherheitsmeldungen beobachten („Watch“). Mit der Veröffentlichung eines Sicherheitshinweises wird sein CVE-Eintrag, soweit eine CVE-Kennung vergeben wurde, in der CVE-Liste veröffentlicht und der Sicherheitshinweis in die GitHub Advisory Database aufgenommen, über die Werkzeuge zur Prüfung von Abhängigkeiten wie Dependabot und composer audit betroffene Installationen warnen. Jeder Sicherheitshinweis wird außerdem auf community.atrocore.com bekannt gegeben, und Kunden mit einem Lizenz- oder Servicevertrag werden per E-Mail darüber informiert.

4.5. Einzelheiten einer Schwachstelle werden nicht veröffentlicht, bevor ein Sicherheitsupdate verfügbar ist, es sei denn, die Schwachstelle wird aktiv ausgenutzt oder ist bereits öffentlich bekannt. In diesem Fall informieren wir die betroffenen Nutzer unverzüglich über die Schwachstelle und über die Maßnahmen, die sie bis zur Verfügbarkeit eines Sicherheitsupdates ergreifen können.

4.6. Wir empfehlen Ihnen, jedes Patch-Release der von Ihnen genutzten Versionen stets unverzüglich zu installieren, nicht nur diejenigen, die als Sicherheitsupdates gekennzeichnet sind. Da die Release Notes eines Sicherheitsupdates zunächst keine Angaben zur Schwachstelle enthalten (Abschnitt 4.3.2), können Sie allein anhand der Release Notes nicht erkennen, ob ein Patch-Release eine Sicherheitsbehebung enthält. Patch-Releases entfernen keine dokumentierte Funktionalität (Abschnitt 2.1.2), sodass ihre Installation keine Anpassung Ihrer Integrationen erfordert. Kunden, deren Umgebung von der AtroCore GmbH als SaaS-Dienst betrieben wird, müssen nichts unternehmen (Abschnitt 2.4.2).

5. Meldung einer Schwachstelle

5.1. Wie Sie melden

5.1.1. Bitte melden Sie Sicherheitslücken nicht über öffentliche GitHub-Issues, -Diskussionen oder -Pull-Requests.

5.1.2. Melden Sie Schwachstellen vertraulich über GitHub, mit der Funktion „Report a vulnerability“ im Reiter „Security“ des betreffenden Repositorys. Dies ist unser bevorzugter Weg: Ihre Meldung bleibt vertraulich und ist unmittelbar mit dem Verfahren für Sicherheitshinweise verknüpft.

5.1.3. Alternativ können Sie per E-Mail an melden, mit dem Betreff „Vulnerability Report – [kurze Beschreibung]“.

5.1.4. Meldungen können auf Deutsch oder Englisch eingereicht werden.

5.1.5. Bitte geben Sie nach Möglichkeit an:

eine Beschreibung der Schwachstelle und ihrer Art (zum Beispiel SQL-Injection, fehlerhafte Zugriffskontrolle oder Offenlegung von Informationen)
das betroffene Produkt, Modul, den betroffenen Dienst oder das betroffene System und die jeweilige Version
eine schrittweise Anleitung zur Reproduktion
die möglichen Auswirkungen, einschließlich der Daten oder Funktionen, die betroffen sein könnten
unterstützendes Material wie Screenshots, Proof-of-Concept-Code oder Mitschnitte von HTTP-Anfragen und -Antworten
Ihre Kontaktdaten, damit wir Rückfragen stellen können.

5.1.6. AtroCore betreibt derzeit kein Bug-Bounty-Programm. Meldungen werden auf freiwilliger Basis und ohne finanzielle Vergütung entgegengenommen, sofern nichts anderes schriftlich vereinbart ist.

5.2. Was Sie von uns erwarten können

5.2.1. Wir bestätigen den Eingang Ihrer Meldung innerhalb von 3 Arbeitstagen und teilen Ihnen unsere erste Einschätzung, einschließlich der Schweregradklasse, innerhalb von 10 Arbeitstagen mit. Benötigen wir für die Einschätzung Ihrer Meldung weitere Informationen, fragen wir bei Ihnen nach; die Frist für unsere erste Einschätzung verlängert sich dann um die Zeit bis zum Eingang Ihrer Antwort. Erhalten wir innerhalb von 20 Arbeitstagen keine Antwort, schließen wir die Meldung; wir nehmen sie wieder auf, wenn Sie die Informationen später nachreichen.

5.2.2. Kann eine Schwachstelle nicht innerhalb der Zielfrist nach Abschnitt 4.1 beseitigt werden, teilen wir Ihnen den Grund und einen neuen Zieltermin mit.

5.2.3. Wir benachrichtigen Sie, wenn das Sicherheitsupdate veröffentlicht ist, und teilen Ihnen den geplanten Veröffentlichungstermin des Sicherheitshinweises mit (Abschnitt 4.3.2). Vor der Veröffentlichung geben wir Ihnen Gelegenheit, den Sicherheitshinweis durchzusehen. Wir benachrichtigen Sie, sobald er veröffentlicht ist, und können Sie mit Ihrer Einwilligung öffentlich nennen.

5.2.4. Wir behandeln Ihre Meldung vertraulich und geben Ihre personenbezogenen Daten ohne Ihre ausdrückliche Einwilligung nicht an Dritte weiter, es sei denn, wir sind gesetzlich dazu verpflichtet.

5.2.5. Sicherheitsforschung, die in gutem Glauben und im Einklang mit Abschnitt 5.3 erfolgt, ist von uns autorisiert. Wir werden im Zusammenhang mit solcher Forschung weder rechtliche Schritte gegen Sie einleiten noch Strafanzeige gegen Sie erstatten. Geht ein Dritter im Zusammenhang damit rechtlich gegen Sie vor, werden wir bekannt machen, dass Ihre Forschung autorisiert war. Diese Zusage kann weder Dritte noch Behörden binden und gilt nicht für Tätigkeiten außerhalb von Abschnitt 5.3.

5.3. Regeln für Sicherheitsforschung

5.3.1. Handeln Sie in gutem Glauben und führen Sie Ihre Forschung so durch, dass weder der AtroCore GmbH noch ihren Kunden noch Personen, deren Daten betroffen sein könnten, ein Schaden entsteht.

5.3.2. Bei der Untersuchung einer möglichen Schwachstelle dürfen Sie nicht:

auf Daten zugreifen oder diese verändern, löschen oder kopieren, soweit dies über das zum Nachweis der Schwachstelle unbedingt Erforderliche hinausgeht
Denial-of-Service-Angriffe oder sonstige Handlungen durchführen, die die Verfügbarkeit oder Leistung unserer Systeme beeinträchtigen
Schadsoftware, Hintertüren oder sonstigen schädlichen Code einschleusen
Social Engineering gegenüber unseren Mitarbeitern, Auftragnehmern oder Kunden betreiben
ohne unsere vorherige schriftliche Zustimmung automatisierte Scan-Werkzeuge gegen Produktivumgebungen einsetzen.

5.3.3. Nutzen Sie, soweit verfügbar, Test- oder Staging-Umgebungen. Wenn Sie unsicher sind, ob eine bestimmte Testhandlung zulässig ist, kontaktieren Sie uns, bevor Sie fortfahren.

5.3.4. Geben Sie uns eine angemessene Gelegenheit, die Schwachstelle zu beseitigen, und unseren Nutzern die Gelegenheit, das Sicherheitsupdate zu installieren, bevor Sie sie offenlegen. Wir bitten Sie, Einzelheiten bis zur Veröffentlichung des Sicherheitshinweises weder zu veröffentlichen noch weiterzugeben, längstens jedoch für 120 Kalendertage ab Ihrer Meldung. Dauert die Beseitigung länger, vereinbaren wir mit Ihnen in gutem Glauben einen verlängerten Zeitplan für die Offenlegung.

6. Nicht erfasste Fälle

6.1. Folgendes fällt nicht in den Geltungsbereich dieser Richtlinie und wird in der Regel nicht als gültige Schwachstellenmeldung anerkannt:

Schwachstellen in Software oder Diensten Dritter, die nicht Bestandteil von AtroCore sind und nicht von der AtroCore GmbH betrieben werden (Abschnitt 1.3)
Probleme, die einen physischen Zugang zu einem Gerät oder System voraussetzen
Social-Engineering- oder Phishing-Angriffe auf unsere Mitarbeiter
Befunde aus volumetrischen Denial-of-Service-Angriffen oder Lasttests; Mängel, die es einem Angreifer ermöglichen, die Software zum Absturz zu bringen oder unverfügbar zu machen, sind Schwachstellen im Geltungsbereich dieser Richtlinie (Abschnitt 2.3)
theoretische Schwachstellen ohne nachgewiesenen oder plausiblen Ausnutzungsweg
fehlende Sicherheits-Header oder TLS-Konfigurationsprobleme bei nicht sensiblen Endpunkten mit vernachlässigbarem Risiko
von automatisierten Scan-Werkzeugen erzeugte Berichte ohne begleitende Analyse oder Nachweis der Ausnutzbarkeit
Probleme, die Versionen betreffen, die nicht mehr unterstützt werden (Abschnitt 2.1).