Plattform
Sicherheitstests für ernsthafte KI-Softwarelieferung
Jeder Befund wird gegen die laufende Anwendung bestätigt, bevor er dich erreicht — sodass das Dashboard echtes Risiko zeigt, kein Scanner-Rauschen.
Ciao Security ist die Anwendungssicherheitsebene der Plattform: statische Analyse, Abhängigkeitsprüfungen und Zugriffskontroll-Proben, wobei Schwachstellen gegen die Live-App bestätigt werden, bevor sie markiert werden. Anders als rohe Scanner-Ausgaben, die Teams in falschen Positiven ertränken, verifiziert Ciao jeden Befund gegen die laufende Anwendung und fasst das Ergebnis in einem Safe-to-Publish-Dashboard zusammen — sodass Teams veröffentlichen, wenn die App nachweislich sicher ist.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Befunde, auf die du handeln kannst, kein Scanner-Rauschen
Anwendungssicherheits-Tooling hat ein Ehrlichkeitsproblem: Scanner produzieren Hunderte von Befunden, von denen die meisten nicht wichtig sind, und Teams lernen, den Report zu ignorieren. Gleichzeitig erhöht KI-gestützte Entwicklung den Einsatz — mehr Änderungen, mehr Angriffsfläche, mehr Gelegenheiten, dass eine Zugriffsregel sich still abschwächt.
Ciao Security schließt einen anderen Vertrag mit deiner Aufmerksamkeit: statische Analyse, Abhängigkeitsprüfungen und Zugriffskontroll-Proben laufen kontinuierlich, und jede Kandidaten-Schwachstelle wird gegen die Live-Anwendung bestätigt, bevor sie markiert wird. Was das Dashboard erreicht, ist echt.
Diese Seite behandelt die Sicherheitstests, die in jedes Ciao-Projekt eingebaut sind. Zu Ciaos eigener Position als Anbieter — SOC 2 Type II, SSO, Datenhandhabung, Zero-Retention-Modellverträge — siehe die Übersicht zu Sicherheit und Compliance.
Wie Security funktioniert
Sicherheitstests laufen kontinuierlich innerhalb des Delivery-Loops, nicht als vierteljährliches Ereignis.
1. Statische Analyse bei jeder Änderung
Code wird analysiert, während er geschrieben wird — unsichere Muster, Injection-Risiken und gefährliche Konstruktionen werden bei der Änderung abgefangen, nicht beim jährlichen Audit.
2. Abhängigkeitsprüfungen
Fremdpakete werden auf bekannte Schwachstellen geprüft, sodass der riskanteste Code in den meisten Anwendungen — der Code, den niemand im Team geschrieben hat — ebenfalls überwacht wird.
3. Zugriffskontroll-Proben
Proben versuchen, was ein Angreifer versuchen würde: Daten über Mandantengrenzen hinweg lesen, Admin-Endpunkte als normaler Nutzer aufrufen, Routen erreichen, die eigentlich Authentifizierung erfordern sollten.
4. Live-Bestätigung vor der Markierung
Kandidaten-Probleme werden gegen die laufende Anwendung bestätigt, bevor sie markiert werden, was nachweisbares Risiko von theoretischem Rauschen trennt.
5. Das Safe-to-Publish-Dashboard
Eine Ansicht beantwortet die Release-Frage: Ist diese Anwendung gerade sicher zu veröffentlichen? Grün spiegelt bestätigte Beweise wider, nicht die Abwesenheit eines Scans.
6. Korrekturen fließen zurück durch den Kreislauf
Bestätigte Befunde kommen mit entworfenen Korrekturen, die so ausgeliefert werden, wie jede Änderung ausgeliefert wird — durch Builder, Guardrails-Prüfung, wo Richtlinien es verlangen, und QA-Gates.
Warum es wichtig ist
Ein gegen die Live-App bestätigter Befund verändert das Gespräch. Es ist nicht „der Scanner sagt, dieses Muster kann riskant sein“ — es ist „diese Anfrage hat gegen deine laufende Anwendung Daten zurückgegeben, die sie nicht sollte.“ Teams beheben solche Dinge.
Und weil die Prüfungen innerhalb des Delivery-Loops laufen, hält Sicherheit mit der Entwicklung Schritt, statt sie Monate später zu auditieren. Das Safe-to-Publish-Dashboard macht die Release-Entscheidung explizit: Grün ist Beweis, kein Optimismus.
Live-Bestätigung verändert auch, wer bei Sicherheit handeln kann. Ein verifizierter Befund mit angehängten Beweisen braucht keinen Sicherheitsingenieur, um ihn zu interpretieren — die Person, die das Projekt betreibt, kann sehen, was passiert ist, und die entworfene Korrektur durch die Prüfung ausliefern. Expertise zählt weiterhin; sie hört nur auf, der Engpass für jede Korrektur zu sein.
Wer es nutzt
Das Safe-to-Publish-Dashboard bedeutet für verschiedene Leser Verschiedenes.
- Teams ohne Sicherheitsfunktion — Die meisten Teams, die interne Tools und Portale bauen, haben keinen AppSec-Ingenieur. Sie bekommen trotzdem kontinuierliche Tests, mit bereits verifizierten Befunden.
- Engineering-Führungskräfte, die an regulierte Käufer verkaufen — Sicherheitsfragebögen werden mit Beweisen aus dem laufenden Produkt beantwortet, nicht mit Bestrebungen aus einem Richtliniendokument.
- Agenturen — Jede Kundenanwendung wird an derselben Messlatte getestet, und „ist sie sicher?“ hat ein Dashboard hinter der Antwort.
- Sicherheitsteams — KI-gebaute Anwendungen sind oft ein blinder Fleck. Ciao hält sie an einem kontinuierlichen, live-verifizierten Standard, den das Team prüfen kann.
Hinweise zu Sicherheit und Governance
- ✓ Statische Analyse, Abhängigkeitsprüfungen und Zugriffskontroll-Proben laufen auf jedem Projekt.
- ✓ Schwachstellen werden gegen die Live-Anwendung bestätigt, bevor sie markiert werden.
- ✓ Der Safe-to-Publish-Status ist pro Projekt und über die gesamte Fleet in Conductor sichtbar.
- ✓ Befunde und ihre Korrekturen werden im unveränderlichen Audit-Protokoll erfasst.
- ✓ Row-Level Security im Supabase-Backend wird von Zugriffskontroll-Proben getestet.
- ✓ Proben laufen nach Änderungen an Authentifizierung und Berechtigungen erneut, sodass Regressionen früh auffallen.
- ✓ Anbieterseitige Compliance — SOC 2 Type II Berichte unter NDA, SSO, Zero-Retention-Verträge — wird auf der Security-Übersichtsseite behandelt.
Rohe Scanner-Ausgabe vs live-bestätigte Befunde
Der Unterschied ist, was du ohne Triage vertrauen kannst.
| Typischer Scanner-Report | Ciao Security | |
|---|---|---|
| Volumen | Hunderte Befunde pro Lauf | Befunde, bestätigt gegen die Live-App |
| Falsch-Positive | Deine Aufgabe zu triagieren | Unbestätigte Kandidaten gaten kein Release |
| Zugriffskontrolle | Musterabgleich im Code | Gegen die laufende Anwendung geprobt |
| Release-Entscheidung | Eine Ermessensentscheidung aus einem PDF | Das Safe-to-Publish-Dashboard |
| Korrekturpfad | Ein Ticket in einem Backlog | Eine entworfene Korrektur durch Prüfung und QA-Gates |
Häufig gestellte Fragen
Wie unterscheidet sich das von der Seite /security?
Diese Seite behandelt Ciao als Anbieter — SOC 2 Type II Berichte unter NDA, SSO via SAML und OIDC, das Audit-Protokoll, Zero-Retention-Modellverträge. Diese Seite hier behandelt, was die Plattform mit deinen Anwendungen macht: scannen, proben und Schwachstellen bestätigen, sodass jedes Release nachweislich sicher zu veröffentlichen ist.
Was beinhaltet live bestätigt konkret?
Kandidaten-Befunde werden gegen die laufende Anwendung ausgeführt. Ein mandantenübergreifender Leseversuch gibt entweder Daten zurück oder nicht; eine unauthentifizierte Anfrage erreicht entweder die Route oder nicht. Bestätigung macht aus einem Muster eine Tatsache, bevor jemand gebeten wird, danach zu handeln.
Ersetzt das einen Penetrationstest?
Das beansprucht es nicht. Kontinuierliches, live-bestätigtes Testen hebt die Alltagsmesslatte und fängt Regressionen zwischen formalen Prüfungen ab. Teams mit vertraglichen oder regulatorischen Anforderungen beauftragen typischerweise weiterhin periodische Penetrationstests — die beiden ergänzen sich.
Was passiert, wenn eine echte Schwachstelle bestätigt wird?
Sie erscheint im Dashboard mit den Beweisen, die sie bestätigt haben, zusammen mit einer entworfenen Korrektur. Die Korrektur läuft durch den normalen Kreislauf — Guardrails-Prüfung, wo Richtlinien es verlangen, QA-Gates vor der Veröffentlichung —, und das Protokoll erfasst den Befund und seine Lösung gemeinsam.
Unser Sicherheitsteam möchte das evaluieren — wo fängt es an?
Buche eine Demo und bring deinen Fragebogen mit. SOC 2 Type II Berichte sind über den Compliance-Track unter NDA verfügbar, und ernsthafte Produktionsprogramme beginnen bei 10.000 USD pro Jahr.