Leistung
Application-Security-Engineering
Eine Entscheidung beim Bauen, keine Phase vor dem Launch.
Für Teams, die Sicherheit als Eigenschaft der Software brauchen statt als Bericht darüber. Wir arbeiten an den Teilen, deren Nachrüstung teuer ist — Autorisierung, Session-Handling, Secrets-Verwaltung, Abhängigkeitsrisiken — und belegen sie mit Tests, die das System zu brechen versuchen.
Die Entscheidung
Wann das die richtige Wahl ist.
Sicherheit, die zwei Wochen vor dem Launch als Scan ankommt, findet das Billige und verfehlt das Teure. Fehlende Header und veraltete Bibliotheken sind real, aber oberflächlich. Fehlerhafte Zugriffskontrolle — ein Nutzer, der über eine geänderte Kennung an den Datensatz eines anderen Mandanten kommt — ist die häufigste schwere Schwachstelle in Business-Software, und kein Scanner findet sie zuverlässig, weil sie exakt wie eine legitime Anfrage aussieht.
Diese Klasse von Schwachstelle ist ein Architekturproblem. Wird Autorisierung durch Ausblenden von Menüpunkten durchgesetzt oder durch eine Prüfung, an die manche Routen denken und andere nicht, lautet die Frage nicht, ob es ein Loch gibt, sondern wo. Ein konsistentes Modell nachträglich in eine fertige Anwendung zu bringen gehört zu den teuersten Änderungen überhaupt.
Deshalb machen wir es zu einer Entscheidung beim Bauen: jede Anfrage serverseitig gegen den handelnden Nutzer autorisiert, Tests, die absichtlich die Daten eines anderen Mandanten anfordern und die Ablehnung prüfen, und Secrets, die nie im Repository waren.
Was Sie bekommen
Was die Arbeit umfasst.
Autorisierung als Standard
Jeder Endpunkt serverseitig gegen den handelnden Nutzer autorisiert, mit Ablehnung als Standard statt als Ausnahme.
Tests, die angreifen
Automatisierte Tests, die Datensätze eines anderen Mandanten anfordern, Rollen ausweiten und abgelaufene Token erneut senden und jeweils die Ablehnung prüfen. Sie laufen bei jedem Commit.
Session- und Token-Handling
Ablauf, Erneuerung und Widerruf sauber entworfen, damit eine abgelaufene Sitzung sauber endet statt ewig zu wiederholen.
Secrets-Management
Zugangsdaten außerhalb von Repository und Konfigurationsdateien, ohne Redeploy rotierbar, mit dokumentiertem Rotationsverfahren.
Abhängigkeiten und Lieferkette
Automatisierte Abhängigkeitsprüfung mit einer Regel dafür, was ein Release blockiert, dazu Lockfiles und reproduzierbare Builds.
Transport und Header
TLS-Konfiguration, HSTS, CSP und der Rest am Origin gesetzt und verifiziert, samt der Protokolleinstellungen, die Clients leise lahmlegen.
Stack
Womit wir es bauen.
Je Projekt gewählt. Nichts davon wird standardmäßig gesetzt, und das Team, das es pflegen wird, wiegt so schwer wie das Problem.
Prüfung
Bedrohungsmodellierung auf Daten und Rollen, bevor das Design feststeht.
Testing
Autorisierungstests in der CI, Abhängigkeits-Scans bei jedem Build und regelmäßige manuelle Prüfung der wichtigen Pfade.
Infrastruktur
Dienstkonten mit minimalen Rechten, Netzgrenzen und Backups mit tatsächlich geprobter Wiederherstellung.
Monitoring
Alarmierung bei Authentifizierungsfehlern, verweigerter Autorisierung und Fehlerraten, denn schon ein Versuch ist ein Signal.
Reaktion
Ein schriftliches Vorgehen für den Tag, an dem etwas schiefgeht — vorher vereinbart.
Vergleich
Ein Scan vor dem Launch oder Sicherheit als Entscheidung beim Bauen.
Scanner lohnen sich und finden echte Dinge. Sie finden nur nicht die Klasse von Schwachstelle, die Unternehmen wirklich Geld kostet.
| Aspekt | Scan vor dem Launch | Von Anfang an eingebaut |
|---|---|---|
| Fehlerhafte Zugriffskontrolle | Wird weitgehend übersehen — die Anfrage nach dem Datensatz eines anderen Mandanten sieht aus wie eine legitime | Tests, die absichtlich die Daten eines anderen Mandanten anfordern und die Ablehnung prüfen, bei jedem Commit |
| Veraltete Abhängigkeiten | Wird gefunden, und das ist wirklich nützlich | Werden früher gefunden, mit einer Regel dafür, was ein Release blockiert |
| Fehlende Header und TLS-Einstellungen | Wird gefunden | Am Origin gesetzt und verifiziert, samt der Protokolleinstellungen, die Clients leise lahmlegen |
| Secrets im Repository | Werden gefunden, wenn sie bereits in der Historie stehen | Landen nie im Repository und sind ohne Redeploy austauschbar |
| Wann Probleme auftauchen | Zwei Wochen vor dem Launch, wenn die Architektur feststeht | Solange das Design noch günstig zu ändern ist |
| Kosten der Behebung | Ein nach dem Launch überarbeitetes Rechtemodell kostet Wochen plus Migration | Tage am Anfang, danach fast nichts |
Wie es abläuft
Vom ersten Gespräch bis live.
Richtwerte für Arbeit dieser Art. Der Pilot ist nicht optional — nichts wird umgestellt, bevor die Nutzer sagen, dass es trägt.
- 3-5 Tage
Bedrohungsmodell
Die Daten, die Rollen und was ein Angreifer tatsächlich wollte — bevor das Design feststeht.
- 2-3 Wochen
Grundlagen
Serverseitige Autorisierung an jedem Endpunkt, Session- und Token-Handling, Secrets außerhalb des Repositorys mit dokumentierter Rotation.
- 1-2 Wochen
Angreifende Tests
Automatisierte Tests, die Mandantengrenzen überschreiten, Rollen ausweiten und abgelaufene Token erneut senden, in der CI verdrahtet, damit eine Regression den Build brechen lässt.
- fortlaufend
Laufend
Abhängigkeitsrichtlinie, Alarmierung bei verweigerter Autorisierung und ein schriftliches Reaktionsverfahren, vereinbart bevor es gebraucht wird.
Nach dem Launch
Was sich ändert.
- Die häufigste schwere Schwachstelle in Business-Software ist durch Tests abgedeckt statt durch Hoffnung.
- Eine abgelaufene Sitzung endet sauber, statt eine tote Anfrage zu wiederholen, bis etwas nachgibt.
- Eine geleakte Zugangsdatei wird zur Rotation, nicht zu Redeploy und Vorfall.
- Ein Penetrationstest kommt kurz zurück, weil die teuren Funde wegkonstruiert wurden.
Bewusst qualitativ beschrieben. Wir veröffentlichen keine Prozentangaben, die wir nicht einem namentlich genannten Kunden mit dessen Zustimmung zuordnen können.
Fragen
Häufige Fragen.
Ist das ein Penetrationstest?
Nein. Ein Penetrationstest ist eine Momentaufnahme durch eine unabhängige Partei, und den sollten Sie gesondert beauftragen — wir helfen gern beim Zuschnitt. Dies hier ist die Ingenieursarbeit, die diesen Test kurz zurückkommen lässt, und sie geht weiter, wenn der Bericht abgelegt ist.
Wir haben bereits einen Scanner. Reicht das nicht?
Scanner lohnen sich und finden echte Dinge, aber sie finden überwiegend bekannte verwundbare Abhängigkeiten und fehlende Header. Fehlerhafte Zugriffskontrolle — die häufigste schwere Schwachstelle in Business-Software — sieht aus wie eine gültige Anfrage und braucht Tests, die gegen Ihr eigenes Rechtemodell geschrieben sind.
Können Sie eine bestehende Anwendung von uns prüfen?
Ja. Die Prüfung einer bestehenden Codebasis dauert meist ein bis zwei Wochen und liefert eine priorisierte Liste mit Begründung, keinen rohen Scanner-Export. Die Behebung können wir übernehmen oder Ihrem Team übergeben.
Bremst das die Entwicklung aus?
Am Anfang geringfügig und erheblich weniger als späteres Nachrüsten. Autorisierungstests und Abhängigkeitsrichtlinie kosten anfangs Tage; ein nach dem Launch überarbeitetes Rechtemodell kostet Wochen und eine Migration.
Wir sind ein kleines Team. Ist das verhältnismäßig?
Die Autorisierungsarbeit schon, denn sie ist anfangs günstig und später sehr teuer, und sie ist die Schwachstelle, die am ehesten die Daten eines Kunden einem anderen offenlegt. Vollständige Bedrohungsmodellierung und laufendes Monitoring können warten, bis es etwas zu überwachen gibt.
Übernehmen Sie Compliance-Zertifizierungen?
Wir leisten die Ingenieursarbeit, die ein Audit einfach macht — Zugriffskontrolle, Audit-Trails, Verschlüsselung, Aufbewahrung, dokumentierte Verfahren — aber wir sind keine Auditoren und stellen keine Zertifikate aus. Wo ein bestimmtes Rahmenwerk gilt, holen Sie den Auditor früh dazu, und wir bauen nach dem, was er tatsächlich verlangt.