Warum Software-Sicherheit scheitert und wie wir widerstandsfähigere Systeme bauen

Ein offengelegtes Passwort, eine verwundbare Softwarekomponente oder eine API mit zu weitreichenden Rechten kann ein alltägliches System zum Sicherheitsrisiko machen. Solche Probleme lassen sich schwerer beheben, wenn Sicherheit nur am Ende geprüft wird, statt Teil der Entwicklungsarbeit zu sein.

Wir berücksichtigen Sicherheit beim Entwurf, im Code und bei der Bereitstellung. Hier sind fünf häufige Fehler, auf die wir achten – und wie wir ihnen begegnen.

„Sicherheit ist keine letzte Hürde. Sie entsteht durch Entscheidungen während des gesamten Lebenszyklus eines Systems.“

— Brian Timmermans

Fünf Sicherheitsfehler und wie wir sie angehen

1. Erst kurz vor der Veröffentlichung an Sicherheit denken

Wenn die Software kurz vor der Veröffentlichung steht, ist ihr grundlegender Entwurf bereits festgelegt. Änderungen am Umgang mit sensiblen Daten oder an Zugriffsrechten können dann viel Zeit und Aufwand erfordern.

Beim Entwurf besprechen wir, welche Daten sensibel sind, wer sie nutzt, welche Systeme verbunden sind und wo Fehler auftreten könnten. Wenn sich die Software ändert, überprüfen wir diese Entscheidungen erneut. Sicherheitsprüfungen gehören in Entwicklung und Veröffentlichung – nicht nur in eine abschließende Kontrolle.

2. Mehr Zugriffsrechte vergeben als nötig

Ein Konto mit umfassenden Administratorrechten kann mehr Bereiche eines Systems gefährden, als für eine Aufgabe nötig ist. Ein privates Netzwerk oder VPN allein beweist nicht, dass jedem Nutzenden oder verbundenen Dienst vertraut werden sollte.

Wir prüfen Identität und Berechtigungen dort, wo Systeme miteinander verbunden sind. Jede Person und jeder Dienst erhält nur die für die Aufgabe nötigen Rechte. Auch Maßnahmen wie Verschlüsselung und Mehr-Faktor-Authentifizierung richten wir nach System und Risiken aus.

3. Abhängigkeiten aus dem Blick verlieren

Die meisten Anwendungen nutzen Softwarekomponenten, die von anderen Personen und Organisationen gepflegt werden. Hat eine Komponente eine bekannte Schwachstelle oder ändert sie sich unerwartet, kann das die gesamte Anwendung betreffen.

Wir behalten Abhängigkeiten und ihre Risiken im Blick, legen Versionen bei Bedarf fest und führen regelmäßig Sicherheitsprüfungen durch. Wir bewerten die Ergebnisse und entscheiden, was geändert werden muss. Ein Scan nützt nur, wenn wir den Befunden nachgehen.

4. Zugangsdaten im Code oder in Build-Systemen hinterlegen

Passwörter, Verbindungsdaten und API-Schlüssel können offengelegt werden, wenn sie im Quellcode stehen. Build- und Veröffentlichungssysteme benötigen außerdem Zugriff auf wichtige Umgebungen. Auch ihre Zugangsdaten und Berechtigungen müssen geschützt werden.

Wir halten Zugangsdaten aus dem Quellcode heraus, begrenzen den Zugriff darauf und ersetzen sie, wenn sie offengelegt wurden. Wo es die Plattform ermöglicht, verwenden wir kurzlebige Zugangsdaten mit genau den Rechten, die eine Aufgabe benötigt. Außerdem beschränken wir, welche Änderungen Software veröffentlichen dürfen.

5. Annehmen, ein privates Netzwerk reiche aus

Netzwerke helfen, Systeme voneinander zu trennen. Sie ersetzen aber nicht die Prüfung einzelner Anfragen. Wird ein Gerät oder Dienst kompromittiert, sollten andere Systembereiche nicht automatisch erreichbar sein.

Wir prüfen Identität und Berechtigungen an Systemgrenzen und begrenzen, wie weit ein Zugriff reicht. Wenn System und Betriebsumgebung es erfordern, trennen wir zusätzlich Netzwerkbereiche.

So bauen wir Sicherheit in die Entwicklung ein

Wir wählen Hosting- und Identitätsdienste passend zu den Anforderungen des Kunden und seiner bestehenden Systeme aus. Mit Terraform definieren wir Infrastruktur, damit Umgebungen überprüft und reproduziert werden können. Playwright unterstützt uns bei Tests von Browserabläufen. SonarQube und Qodo helfen bei Codequalität und Codeprüfung. Mit OWASP Dependency-Track behalten wir Risiken von Softwarekomponenten im Blick, mit Trivy führen wir regelmäßig Sicherheitsprüfungen durch und OpenTelemetry verbindet Anwendungssignale mit Monitoring und Protokollierung.

Unser Ansatz orientiert sich an den Prinzipien der ISO/IEC 27001; wir sind nicht nach dieser Norm zertifiziert. EU-Datenresidenz ist der Standard für Kundenlösungen. Welche Maßnahmen wir einsetzen, hängt vom System, den verarbeiteten Daten und den Risiken ab. Mehr dazu erfahren Sie auf unserer Seite Sicherheit & Vertrauen.