Ist Raisetalk sicher? Was wir messen, beheben und veröffentlichen

Eine gestern saubere Basis ist es heute nicht mehr

Software verfällt nicht, weil man sie anfasst. Sie verfällt, weil sich die Welt um sie herum bewegt. Sie haben seit drei Wochen keine Zeile Code geändert, und trotzdem ist Ihr Produkt heute Morgen womöglich verwundbar: Für eine transitive Abhängigkeit, die Sie nie bewusst ausgewählt haben, wurde soeben eine CVE veröffentlicht; das Basis-Image Ihres Containers enthält eine Systembibliothek, die gerade das Supportende erreicht hat; ein von einem Anbieter geliefertes Binary bindet eine zur Kompilierzeit eingefrorene Version einer Fremdbibliothek ein; eine Cloud-Einstellung, die vor einem Jahr als akzeptabel galt, ist zur dokumentierten schlechten Praxis geworden.

Über alle Hersteller hinweg werden inzwischen mehr als hundert Schwachstellen pro Tag veröffentlicht. In diesem Takt lautet die relevante Frage bei der Bewertung eines Anbieters nicht „Sind Sie zertifiziert?". Sie lautet: Was geschieht bei Ihnen zwischen dem Moment, in dem eine Schwachstelle veröffentlicht wird, und dem Moment, in dem sie behoben ist? Wie lange es dauert, über welchen Mechanismus, mit welchem Nachweis, und wer entscheidet, dass sie behoben ist.

Diese Frage betrifft uns in besonderem Maße. Raisetalk verarbeitet Gesprächsaufzeichnungen, Transkripte und personenbezogene Daten von Endkunden, die nie von uns gehört haben: Sie haben schlicht ihre Bank, ihren Versicherer oder ihren Energieversorger angerufen. Das Vertrauen, das man uns entgegenbringt, ist delegiertes Vertrauen, und diese Art von Vertrauen weist man nach, statt sie zu behaupten.

Dieser Artikel beschreibt deshalb die Mechanik, nicht die Absicht. Was wir messen, in welchem Rhythmus, was passiert, wenn eine Meldung auftritt, was wir veröffentlichen, und schließlich, wie sich dieser Ansatz zu den beiden anderen klassischen Antworten des Marktes verhält: Zertifizierung und Penetrationstest.

Was wir fortlaufend analysieren

Als Analyse- und Schutzplattform setzen wir auf Aikido Security. Der Grund für diese Wahl ist einfach: die Abdeckung. Viele Werkzeuge beherrschen eine Sache sehr gut, etwa die statische Codeanalyse oder die Kontrolle der Cloud-Posture. Das Problem ist, dass ein Angreifer seinen Einstiegspunkt nicht nach dem Zuschnitt Ihres Werkzeugkastens wählt. Ein API-Schlüssel in einer Konfigurationsdatei, eine CVE in einem Systempaket eines Container-Images und eine zu weit gefasste IAM-Rolle auf einem Dienstkonto sind aus seiner Sicht vollkommen gleichwertig.

Sechs Oberflächen werden daher fortlaufend überwacht.

Dieser letzte Punkt verdient eine Anmerkung, weil er selten umgesetzt wird. Ein Scanner, der an der Anmeldeseite haltmacht, analysiert nur das Schaufenster. Wir haben dem Scanner deshalb einen authentifizierten Zugang zur API eingerichtet, damit er auch erkundet, was hinter der Authentifizierung liegt, dort, wo die Routen sitzen, die tatsächlich Daten verarbeiten. Das ist unbequemer, denn es erzeugt zwangsläufig mehr Findings. Genau deshalb ist es nützlich.

Was schützt, während der Code läuft

Analysieren heißt herausfinden, was ausgenutzt werden könnte. Schützen heißt aufhalten, was gerade ausgenutzt wird. Das eine ersetzt das andere nicht, und für die zweite Hälfte der Arbeit setzen wir zwei getrennte Bausteine ein.

Eine in die API eingebettete Anwendungs-Firewall. Zen läuft nicht wie eine klassische WAF vor der Anwendung, sondern im Anwendungsprozess selbst, was ihr Zugriff auf Kontext gibt, den die vorgelagerte Instanz nicht hat. Sie sieht nicht nur eine verdächtige Zeichenkette in einer HTTP-Anfrage, sie sieht die tatsächlich gebaute SQL-Abfrage, den tatsächlich ausgeführten Befehl, den tatsächlich geöffneten Dateipfad. Sie kann deshalb unterscheiden, ob eine Zeichenkette wie eine Injection aussieht oder tatsächlich eine erzeugt. Bei uns läuft sie seit Herbst 2025 im Blockiermodus, nicht im reinen Beobachtungsmodus: Ein erkannter Versuch wird abgebrochen, nicht bloß protokolliert.

Diese Entscheidung hat einen Preis, und der gehört benannt: Eine Firewall im Blockiermodus kann theoretisch eine legitime Anfrage abbrechen. Wir stehen dazu, und deshalb werden Versionswechsel dieses Bausteins mit derselben Sorgfalt behandelt wie eine funktionale Änderung, indem vor dem Ausrollen geprüft wird, was sie an den Blockierentscheidungen verändern.

Die Kontrolle der Arbeitsplatzrechner. Der zweite Baustein betrifft unsere eigenen Geräte, jene, von denen aus wir entwickeln und die Produktion administrieren. Festplattenverschlüsselung, Bildschirmsperre, Systemaktualisierungen, aktiver Virenschutz: Diese Kontrollen werden auf jedem Gerät fortlaufend geprüft. Das ist keine dekorative Compliance. Eine tadellose Plattform, die von einem unverschlüsselten und im Zug offen liegen gelassenen Laptop aus administriert wird, bleibt eine verwundbare Plattform, und wer einen Softwarehersteller angreift, nimmt selten zuerst das Produkt ins Visier.

Was passiert, wenn eine Meldung auftritt

Hier entscheidet sich der Unterschied zwischen einer eingekauften Analyseplattform und einer gelebten Sicherheitspraxis. Ein Werkzeug, das zweihundert Meldungen erzeugt, erzeugt zweihundert Meldungen. Es erzeugt keine Sicherheit. Sicherheit beginnt im nächsten Schritt, dem, den niemand in einer Demo zeigt.

Unser Prozess ist schriftlich festgehalten und wird jedes Mal in derselben Reihenfolge durchlaufen.

1. Gruppierung nach Ursache. Eine Gruppe von sechsunddreißig Findings sind fast nie sechsunddreißig Probleme. Oft ist es eine einzige Zeile in einer Lock-Datei für Abhängigkeiten, projiziert auf drei Container-Images und zwei Repositories. Der erste Schritt besteht deshalb darin, die eine Ursache von den betroffenen Oberflächen zu trennen und zu benennen, wie viele eigenständige Korrekturen wirklich nötig sind. Das verhindert, Meldungsvolumen mit Arbeitsaufwand zu verwechseln und sechsunddreißig Symptome dringlich zu behandeln statt eines Problems.

2. Ein Ticket mit Frist. Jede bearbeitete Gruppe führt zu einem Ticket im betroffenen Repository, mit Schweregrad und Bearbeitungsfrist. Nichts lebt allein in einem Dashboard: Was kein Ticket hat, hat keinen Verantwortlichen, und was keine Frist hat, hat keine Priorität.

3. Prüfung im eigenen Code. Das ist der Schritt, den der Scanner nicht für uns übernehmen kann. Eine für eine Bibliothek gemeldete CVE sagt nicht, ob der verwundbare Code von unserem aus erreichbar ist. Wir lesen die betroffenen Dateien, bestätigen die tatsächlich installierte Version, die tatsächlich deklarierte Einschränkung und die realen Aufrufer. Eine SSRF-Schwachstelle in einer Funktion, die wir nie aufrufen, ist nicht so dringend wie eine von einer öffentlichen Route aus erreichbare Deserialisierung. Diese Prüfung führt bisweilen zum gegenteiligen Schluss: Falschmeldung, toter Code oder bereits vorhandene Korrektur. In diesem Fall wird die Entscheidung mit ihrer Begründung dokumentiert, nie durch stilles Ad-acta-Legen.

4. Die Korrektur, und alles, was dazugehört. Ein Behebungsplan endet nicht beim Versionswechsel. Er umfasst ausdrücklich die Schritte außerhalb des Codes: Neubau des Images, Rotation eines Secrets, Umschreiben der Historie, falls ein Zugangsdatum offengelegt wurde, Neustart des betroffenen Dienstes. Ein aus dem Quellcode entferntes, beim Anbieter aber weiterhin gültiges Secret ist kein behobenes Secret.

5. Prüfung nach dem Deployment, dann Abschluss durch einen Menschen. Wir prüfen, dass die Korrektur tatsächlich in dem enthalten ist, was läuft, und nicht nur in dem, was committet wurde. Ein neu gebautes, aber nicht ausgerolltes Image, Traffic, der nach einem Rollback an der alten Revision festgepinnt bleibt: Solche Abweichungen sind klassisch, und sie machen aus einer Korrektur die Illusion einer Korrektur. Erst danach schließt ein Mensch das Ticket.

Die Härtung im Detail

Eine Erkennungsmechanik ist nur so viel wert wie das Fundament, auf das sie angewandt wird. Hier, ohne Anspruch auf Vollständigkeit, die Grundsätze, die die Infrastruktur von Raisetalk heute bestimmen. Sie sind nicht deklarativ: Jeder einzelne wird durch die oben beschriebenen Analysen fortlaufend überprüft, und eine Abweichung wird zur Meldung.

• Kein Container läuft mit Administratorrechten. Sowohl die Master- als auch die Worker-Prozesse laufen unter einem nicht privilegierten Konto, und die Dienste lauschen auf nicht privilegierten Ports.
• Die Images enthalten keine Binaries mit SUID-Bit, und eine Prüfung lässt den Image-Build fehlschlagen, falls doch eines auftaucht. Ein später hinzugefügter Installationsschritt könnte eines wieder einbringen, ohne dass etwas darauf hinweist: Eine Härtung, die sich nicht selbst überwacht, geht beim nächsten Update immer verloren.
• Secure Boot ist aktiv auf den virtuellen Maschinen, sodass die Startkette geprüft wird, bevor das System lädt.
• Der administrative Zugang läuft über die Identität, nie über einen geteilten Schlüssel. Authentifizierung über die Cloud-Identität, projektweite SSH-Schlüssel blockiert, Zugriff auf die Maschinen über einen authentifizierten Tunnel statt über einen exponierten Administrationsport.
• Jeder Dienst läuft unter einem eigenen Konto, beschränkt auf die Rechte, die er wirklich braucht, und nie unter einem Standardkonto: Diese tragen konstruktionsbedingt viel zu weit gefasste Rollen.
• Die Datenbank erzwingt die Verschlüsselung der Verbindungen selbst, statt sie dem Gutdünken des jeweiligen Clients zu überlassen.
• Die öffentliche Website erzwingt eine strikte Content Security Policy, bis hin zum Verbot von Inline-Styles: eine echte Einschränkung für alle, die Komponenten schreiben, und eine Angriffsfläche weniger.

Keiner dieser Punkte ist für sich genommen spektakulär. Es ist ihre Kombination, und vor allem die Tatsache, dass sie dauerhaft und nicht nur einmal bei der Installation geprüft werden, die die eigentliche Arbeit ausmacht.

Wo wir stehen, Stand 19. August 2026

Zum Zeitpunkt der Veröffentlichung dieses Artikels weist das Dashboard im gesamten Perimeter keine offene Meldung aus. Die von der Plattform erzeugten Compliance-Berichte ergeben folgendes Bild.

Die Plattform ordnet Raisetalk zudem den 5 % der am besten abgesicherten Anwendungen ihres Bestands zu. Das ist ein von einem Dritten gelieferter relativer Vergleich, und als solchen führen wir ihn an.

Transparenz: der Bericht, auf Anfrage

Ein Anbieter, der versichert, es sei alles in Ordnung, bittet Sie, ihm zu glauben. Wir lassen Sie lieber selbst hinsehen.

Das Badge im Fußbereich aller Seiten dieser Website öffnet ein Formular zur Anforderung des Sicherheitsauditberichts. Der Bericht wird aus dem tatsächlichen Zustand der Plattform zum Zeitpunkt der Anfrage erzeugt, nicht aus einem einmal verfassten, festen Dokument: Es ist dieselbe Quelle, aus der auch die obigen Zahlen stammen.

Warum auf Anfrage und nicht frei zugänglich? Weil ein Sicherheitsbericht einen technischen Perimeter beschreibt und es zur elementaren Hygiene gehört zu wissen, wem man ihn übermittelt. Das Formular ist kurz, und die Anfrage wird zügig bearbeitet.

Für uns ist das zugleich eine einseitige Verpflichtung. Ein Badge zu veröffentlichen, das Zugang zu einer unabhängigen Messung unseres Sicherheitszustands eröffnet, heißt im Voraus zu akzeptieren, dass ein schlechter Monat sichtbar wird. Genau das macht die Information in der übrigen Zeit wertvoll.

Die anderen Ansätze, und warum sie danach kommen

Zwei Antworten beherrschen den Markt, wenn ein Käufer die Sicherheitsfrage stellt. Beide sind legitim, und beide reichen für sich allein nicht aus. Unsere Position lässt sich in einem Wort zusammenfassen: Reihenfolge.

Die ISO-27001-Zertifizierung

ISO/IEC 27001 zertifiziert ein Managementsystem für Informationssicherheit. Eine akkreditierte Stelle prüft, ob Sie Ihre Risiken erfasst, Maßnahmen definiert und Ihre Verfahren dokumentiert haben und ob Sie das Ganze am Leben halten. Das Zertifikat gilt drei Jahre, mit jährlichen Überwachungsaudits. Das ist ernsthafte Arbeit, sie strukturiert eine Organisation nachhaltig, und sie ist für einen Käufer ein starkes Signal.

Ihre Grenzen ergeben sich aus ihrem Wesen und haben nichts Polemisches. Das Audit arbeitet zu einem gegebenen Zeitpunkt mit Stichproben. Es bestätigt ein Managementsystem, nicht den technischen Zustand Ihres Produkts in dem Moment, in dem Ihr Interessent das Zertifikat liest. Nichts an einem im März erlangten Zertifikat sagt etwas über die im Oktober veröffentlichte kritische Schwachstelle in einer Abhängigkeit der Anwendung aus. Das Zertifikat bescheinigt, dass die Organisation über einen Prozess verfügt, um damit umzugehen, was etwas ganz anderes ist als die Bescheinigung, dass sie es getan hat.

Es ist eine Fotografie, von einem Profi aufgenommen, mit einer ausgezeichneten Kamera. Eine Fotografie bleibt es dennoch.

Der Penetrationstest (Pentest)

Der Penetrationstest liefert, was kein Scanner erzeugen kann: die Intelligenz eines menschlichen Angreifers. Drei für sich genommen geringfügige Schwächen zu verketten, um einen Zugang zu erlangen, den es nicht geben dürfte; eine Geschäftslogik zu missbrauchen, die dem Code perfekt entspricht; über die Manipulation einer Kennung auf das Objekt eines anderen Kunden zuzugreifen: Das erkennt keine Mustererkennung.

Seine Grenze ist allerdings budgetär, und sie ist struktureller Natur. Man kauft eine Anzahl Tage, also definiert man einen Perimeter. Alles außerhalb dieses Perimeters wird nicht getestet, und der Bericht wird davon oft nichts sagen, oder nur im Kleingedruckten... Er beschreibt, was dort gefunden wurde, wo gesucht wurde. Wie die Zertifizierung gilt der Test für ein Datum, eine Version und vor allem einen begrenzten Perimeter. Das Deployment des Folgemonats entwertet einen Teil davon.

Die drei Ansätze im Vergleich

Diese drei Spalten ersetzen einander nicht. Sie ergänzen einander, und zwar in dieser Reihenfolge. Sich zertifizieren zu lassen, ohne eine fortlaufende Kontrolle zu haben, heißt einen Prozess sauber zu dokumentieren, den man nicht auszuführen weiß. Einen Penetrationstest auf einem Perimeter zu beauftragen, auf dem bekannte verwundbare Abhängigkeiten herumliegen, heißt zum Expertenpreis zu entdecken, was ein Scanner über Nacht kostenlos findet. Und ihn auf einem engen Perimeter zu beauftragen, der gerade deshalb gewählt wurde, weil man ihn bereits beherrscht, heißt eine gute Nachricht zu kaufen statt einer Information: Sie wird beim Verfassen des Perimeters entschieden, nicht beim Test. Ein nützlicher Penetrationstest ist einer, dessen Perimeter nach seiner Schwierigkeit gewählt wurde und dessen Umfang zusammen mit dem Ergebnis genannt wird.

Unsere Reihenfolge lautet daher: zuerst die permanente Messung und die systematische Korrektur, weil das die Daten unserer Kunden heute tatsächlich schützt. Eine ISO-27001-Zertifizierung wird erwogen, und ein externer Penetrationstest steht auf unserer Roadmap: Sie werden bestehende Grundlagen bestätigen und ergänzen, nicht ersetzen und auch nicht vertreten.

Was die fortlaufende Kontrolle nicht ersetzt

Es wäre unredlich zu schließen, ohne zu sagen, wo das, was wir hier beschreiben, endet.

Eine Analyseplattform kennt Ihr Geschäft nicht. Sie weiß, dass eine SQL-Abfrage durch Verkettung gebaut wird. Sie weiß nicht, dass ein Nutzer eines Teams niemals die Bewertungen eines anderen Teams sehen darf. Solche Regeln sind unserem Produkt eigen, und keine Schwachstellendatenbank enthält sie. Deshalb pflegen wir intern unser eigenes Bedrohungsmodell: die Deployment-Einheiten, die Eintrittsflächen, die Vertrauensgrenzen und die Geschäftsregeln, die niemals nachgeben dürfen. Es wird wie Code gelesen und aktualisiert und dient als Karte, wenn wir suchen, wonach kein Werkzeug an unserer Stelle sucht.

Ein Compliance-Wert ist keine Garantie. Er zeigt an, dass im beobachteten Perimeter kein bekanntes Problem verbleibt. Das ist viel wert, und es sagt nichts über Schwachstellen aus, die noch nicht öffentlich sind. Niemand kann das Gegenteil versprechen, und wer es tut, ist mit Vorsicht zu genießen.

Sicherheit bleibt eine Kette. Sie umfasst unsere Unterauftragnehmer, unsere KI-Modellanbieter, den Hoster und die Art, wie Ihre eigenen Teams die Plattform nutzen. Genau deshalb gehören die Zugriffskontrolle über Rollen und Bereiche und die Pseudonymisierung personenbezogener Daten zum selben Thema wie die Schwachstellen: Sie bestimmen, was geschützt bleibt, wenn an anderer Stelle etwas nachgibt.

Das Schlusswort

Wir hätten einen kurzen Artikel schreiben können: „null Schwachstellen, dreizehn Rahmenwerke, Top 5 %". Er wäre zutreffend gewesen und hätte nichts bewiesen. Die Zahlen, die in der Sicherheit zählen, sind nicht die, die man zeigt, sondern die, die man erklären kann: woher sie kommen, was sie abdecken, was sie auslassen und was an dem Tag geschieht, an dem sie sich verschlechtern.

Die Sicherheit einer Software ist kein Zustand, sondern ein Takt. Sie wird nicht durch ein Jahresdokument belegt, sondern durch die Fähigkeit, Woche für Woche zu bearbeiten, was die Messung zutage fördert, auch wenn es unbequem ist, auch wenn es dazu zwingt, eine Maschine neu aufzusetzen oder eine Komponente zu überarbeiten, die einwandfrei funktioniert hat.

Und weil die Behauptung eines Anbieters nie so viel wert ist wie die Prüfung eines Käufers: Der Bericht steht am Fuß dieser Seite.

Selbst nachprüfen

• Den Sicherheitsauditbericht anfordern: zum Formular, oder auf das Badge im Fußbereich klicken.
• Unsere Antworten zu Daten und DSGVO: die häufig gestellten Fragen
• Uns eine konkrete Frage stellen: www.raisetalk.com/de/contact

Die in diesem Artikel genannten Zahlen entsprechen dem am 19. August 2026 festgestellten Stand. Sie verändern sich: Genau darin liegt ihr Wert. Ein Sicherheits-Dashboard, das sich seit sechs Monaten nicht bewegt hat, ist kein Zeichen für ein stabiles Produkt, sondern für eine stillstehende Messung. Die richtige Frage an einen Anbieter, uns eingeschlossen, lautet daher nicht „Ist Ihr Wert heute gut?". Sie lautet „Was geschieht bei Ihnen an dem Tag, an dem er es nicht mehr ist?".