Sichere Software entsteht durch überprüfbare Entscheidungen über Architektur, Berechtigungen, Eingaben, Abhängigkeiten und Betrieb. Der BSI-Baustein CON.8 unterstützt die Organisation dieser Arbeit; die OWASP Top 10 helfen dabei, verbreitete Klassen von Anwendungssicherheitsrisiken zu erkennen. Beide ersetzen weder eine eigene Risikobewertung noch die Prüfung der tatsächlich geltenden rechtlichen Anforderungen.
Für ein Entwicklungsteam ist die entscheidende Frage, wie aus einem allgemeinen Sicherheitsziel eine überprüfbare Eigenschaft der Anwendung wird. „Nur berechtigte Personen dürfen Daten sehen“ muss beispielsweise für jede Schnittstelle, jeden Export und jeden Hintergrundauftrag gelten. Dieser Leitfaden verbindet die einschlägigen BSI-Anforderungen mit konkreten Entwicklungsentscheidungen und ordnet Datenschutz, NIS2 und den Cyber Resilience Act getrennt ein.
Was CON.8 tatsächlich abdeckt
Der BSI-Baustein CON.8 Software-Entwicklung, Edition 2023 behandelt Sicherheitsaspekte der entwickelnden beziehungsweise auftragnehmenden Seite. Die Auftraggeberperspektive wird insbesondere durch APP.7 ergänzt. CON.8 ist weder eine vollständige Entwicklungsmethode noch ein eigenständiges Gesetz. Für eine konkrete Anwendung muss feststehen, welche Sicherheitsanforderungen vereinbart sind und wie sie im Entwicklungsablauf nachgewiesen werden.
Die Basisanforderungen betreffen unter anderem Vorgehensmodell, Entwicklungsumgebung, sicheres Systemdesign, vertrauenswürdige Bibliotheken, entwicklungsbegleitende Prüfungen, Updates und Versionsverwaltung. Standardanforderungen ergänzen beispielsweise Rollen, Entwicklungsrichtlinie, Dokumentation, Schulung und Bedrohungsmodellierung. Anforderungen bei erhöhtem Schutzbedarf werden anhand der individuellen Risiken betrachtet. Die Einordnung in die BSI-Grundschutz-Methodik verhindert, dass einzelne Stichwörter als vollständige Umsetzung ausgegeben werden.
Die Verbindlichkeit der BSI-Anforderungen ist von ihrer fachlichen Bedeutung zu unterscheiden. Ein Unternehmen kann sie etwa vertraglich zusagen oder für sein Sicherheitskonzept übernehmen; einschlägige Rechtsnormen können zusätzliche Maßstäbe setzen. Daraus folgt keine allgemeine gesetzliche Pflicht für jedes Team, dasselbe Werkzeug, denselben Freigaberhythmus oder eine bestimmte kommerzielle Zertifizierung einzusetzen. Dokumentieren Sie stattdessen den gewählten Rahmen und begründen Sie relevante Abweichungen.
Sicherheitsanforderungen vor der Implementierung konkretisieren
Beginnen Sie mit den schützenswerten Daten und Funktionen. Wer darf einen Datensatz lesen, verändern, exportieren oder löschen? Welche administrative Handlung kann viele Kunden gleichzeitig betreffen? Welche Folgen haben manipulierte Eingaben oder der Ausfall eines externen Dienstes? Diese Fragen liefern Anforderungen, die Entwickler und fachliche Verantwortliche gemeinsam bewerten können.
Ein Beispiel ist eine Anwendung für mehrere Kundenunternehmen. Eine Anmeldung beantwortet zunächst nur, welcher Nutzer erkannt wurde. Zusätzlich muss für jede Operation feststehen, zu welchem Unternehmen der betroffene Datensatz gehört und welche Berechtigung dieser Nutzer dort besitzt. Dieselbe Regel muss auch gelten, wenn ein Hintergrundprozess oder eine Exportfunktion die Daten verarbeitet. Eine nur im sichtbaren Bildschirm versteckte Schaltfläche genügt nicht.
Beschreiben Sie Vertrauensgrenzen zwischen Browser, Schnittstelle, Anwendung, Datenbank und externen Diensten. Ein vom Browser übermittelter Rollenname ist kein verlässlicher Berechtigungsnachweis. Auch intern weitergereichte Daten können ursprünglich von außen stammen. Bei einer systematischen Risikoanalyse werden solche Annahmen sichtbar, sodass passende Schutzmaßnahmen früh in den Entwurf eingehen.
Halten Sie die wichtigen Architekturentscheidungen knapp fest: welches System Identitäten prüft, wo Autorisierung erfolgt und wie sensible Daten die Anwendung verlassen dürfen. Diese Dokumentation soll spätere Änderungen erleichtern. Wird beispielsweise ein neuer Importweg ergänzt, muss das Team erkennen können, welche bereits definierten Prüfungen auch dort gelten und welche Risiken neu hinzukommen.
OWASP Top 10:2025 richtig verwenden
Die aktuelle Ausgabe OWASP Top 10:2025 unterscheidet zehn Risikokategorien: fehlerhafte Zugriffskontrolle, Sicherheitsfehlkonfiguration, Fehler in der Softwarelieferkette, kryptographische Fehler, Injection, unsicheres Design, Authentisierungsfehler, Integritätsfehler bei Software oder Daten, unzureichende Sicherheitsprotokollierung und Alarmierung sowie fehlerhafte Behandlung außergewöhnlicher Bedingungen. Die Reihenfolge und Bezeichnungen dürfen nicht mit der Ausgabe 2021 vermischt werden.
Für die Praxis sind die Änderungen aufschlussreich: Die Lieferkettenkategorie erfasst auch Risiken in Erstellung und Auslieferung von Software. Die Kategorie für außergewöhnliche Bedingungen lenkt den Blick auf Fehlerzustände, Ressourcenmangel und ungewollt erlaubende Entscheidungen bei Ausfällen. Server-Side Request Forgery wird in der Ausgabe 2025 der Zugriffskontrolle zugeordnet. Die Liste ist eine Orientierung für Risiken, kein vollständiger Prüfkatalog und keine Produktzertifizierung.
Übertragen Sie die Kategorien auf die eigene Anwendung. Ein öffentliches Informationsangebot, eine Administrationsoberfläche und eine Zahlungsfunktion besitzen unterschiedliche kritische Abläufe. Die sinnvolle Frage lautet deshalb, welche konkreten Fehler in Ihrem System zu unbefugten Handlungen führen könnten. Eine pauschale Aussage „OWASP-konform“ ohne Prüfgegenstand, Version und nachvollziehbare Ergebnisse ist für diese Entscheidung wenig hilfreich.
Autorisierung auf dem Server durchsetzen
OWASP A01:2025 betont die Durchsetzung in vertrauenswürdigem serverseitigem Code. Prüfen Sie die Berechtigung zur konkreten Aktion am konkreten Objekt. Ein Nutzer, der eine Rechnung sehen darf, darf nicht automatisch die Rechnung eines anderen Kunden durch Änderung einer Kennung abrufen. Dass Kennungen schwer erratbar sind, ersetzt die Berechtigungsprüfung nicht.
Nutzen Sie gemeinsame, nachvollziehbare Mechanismen, damit dieselbe Regel nicht in zahlreichen leicht abweichenden Varianten entsteht. Berücksichtigen Sie auch Listen, Suchergebnisse, Downloads und indirekte Zugriffe. Eine korrekt geschützte Detailansicht hilft nicht, wenn eine Suchfunktion dieselben Daten ohne passende Einschränkung zurückgibt. Sonderrechte für Support und Administration sollten ausdrücklich begrenzt und überprüfbar sein.
Planen Sie den Entzug von Berechtigungen. Was geschieht mit bestehenden Sitzungen, wenn eine Person aus einem Kundenkonto entfernt wird? Wie lange bleiben ausgestellte Zugriffsnachweise verwendbar? Antworten auf diese Fragen gehören zum Sicherheitsentwurf. Die passende Lösung hängt vom Sitzungsmodell und Risiko ab; allein die erfolgreiche Anmeldung zu einem früheren Zeitpunkt begründet keine dauerhaft unveränderte Berechtigung.
Eingaben als Daten behandeln
CON.8 verlangt die Prüfung von Eingaben vor der Weiterverarbeitung und bei Client-Server-Anwendungen grundsätzlich auf dem Server. Definieren Sie zulässige Formate, Größen und fachliche Werte. Eine Bestellmenge kann technisch eine Zahl sein und fachlich dennoch unzulässig. Auch importierte Dateien, Nachrichten anderer Dienste und gespeicherte Inhalte benötigen eine zum Verarbeitungsschritt passende Behandlung.
Gegen Injection ist die Trennung von Daten und ausführbaren Befehlen entscheidend. Die OWASP-Erläuterung zu Injection empfiehlt bevorzugt sichere Schnittstellen und parametrisierte Abfragen. Bauen Sie Datenbankbefehle nicht durch das Zusammenfügen ungeprüfter Eingaben mit Befehlstext auf. Eine vorherige Formatprüfung bleibt sinnvoll, ersetzt aber diese Trennung nicht. Auch ein ORM schützt nicht automatisch jede selbst zusammengesetzte Abfrage.
Für die Ausgabe ist der jeweilige Kontext maßgeblich. Text für eine HTML-Seite, eine URL und einen anderen Interpreter benötigt unterschiedliche sichere Behandlung. Ein universeller Filter, der einige Sonderzeichen entfernt, ist dafür keine zuverlässige Grundlage. Verwenden Sie die vorgesehenen Schutzmechanismen des gewählten Frameworks und prüfen Sie besonders die Stellen, an denen diese umgangen werden.
Dateiuploads verdienen eine eigene Entscheidung: Welche Inhalte werden benötigt, wie groß dürfen sie sein, wo werden sie gespeichert und welche Verarbeitung wird ausgelöst? Vermeiden Sie, dass hochgeladene Inhalte unbeabsichtigt als Programm ausgeführt werden oder frei wählbare interne Ziele bestimmen. Beschränken Sie auch Ressourcenverbrauch und Zugriff auf die entstandenen Dateien. Die Gefahr liegt häufig in der späteren Verwendung, nicht nur im ersten Upload.
Geheimnisse, Kryptographie und sichere Einstellungen
Produktive Schlüssel und Zugangsdaten gehören nicht in öffentlich erreichbare Dateien oder ungeschützte Quellcodebestände. Legen Sie fest, wie sie bereitgestellt, verwendet und entzogen werden. Unterschiedliche Umgebungen benötigen passende getrennte Berechtigungen. Ein kompromittierter Testzugang sollte nicht zugleich einen Zugriff auf Kundendaten ermöglichen.
Ein pauschaler Wechsel aller Geheimnisse nach exakt neunzig Tagen ist keine universelle Secure-Coding-Pflicht. Entscheidend sind Art des Geheimnisses, Nutzungsdauer, Exposition, technische Möglichkeiten und gegebenenfalls verbindliche spezielle Vorgaben. Bei bekannt gewordener Kompromittierung reicht ein späterer regulärer Wechseltermin nicht. Prüfen Sie außerdem, ob bereits ausgestellte Tokens, Kopien oder abhängige Dienste einbezogen werden müssen.
Verwenden Sie bewährte kryptographische Bibliotheken und geeignete Verfahren statt selbst entworfener Verschlüsselung. Passwörter benötigen eine dafür geeignete sichere Hashspeicherung; reversibles Verschlüsseln ist hierfür kein gleichwertiger Ersatz. Für Transportverbindungen müssen neben der Protokollauswahl auch Zertifikatsprüfung, Schlüsselverwaltung und Erneuerung funktionieren. Der Beitrag zum BSI-Mindeststandard TLS erläutert den zugehörigen Maßstab und Anwendungsbereich.
Beschreiben Sie für die Übergabe an den Betrieb auch, welche Einstellungen sicherheitskritisch sind und welche Folgen ihre Änderung hat. Wenn beispielsweise eine zusätzliche Integrationsschnittstelle aktiviert wird, müssen die dazugehörigen Berechtigungen und Kommunikationswege überprüft werden. So bleibt die Sicherheitsentscheidung auch nach der ursprünglichen Installation nachvollziehbar.
Sichere Voreinstellungen betreffen auch Debug-Ausgaben, öffentlich erreichbare Verwaltungsfunktionen und unnötige Dienste. Ein Installationshandbuch heilt keine gefährliche Standardeinstellung, die bei gewöhnlicher Nutzung aktiv bleibt. Überlegen Sie bei jeder Komfortoption, ob Nutzer ihre Tragweite erkennen können und ob die Freigabe zu den vorgesehenen Aufgaben passt.
Abhängigkeiten und Entwicklungsumgebung schützen
Bibliotheken sparen Entwicklungsarbeit, übertragen aber auch Abhängigkeiten in das eigene Produkt. CON.8 verlangt vertrauenswürdige Quellen und Integritätsprüfungen. Erfassen Sie Versionen und Zuständigkeiten, prüfen Sie relevante Sicherheitsmeldungen und bewerten Sie, ob eine gemeldete Schwachstelle in Ihrer Verwendung erreichbar ist. Eine hohe technische Bewertung allein erklärt noch nicht den konkreten Angriffsweg; ein ungeklärter Befund sollte dennoch nicht folgenlos verschwinden.
Die Schutzbetrachtung endet nicht beim Quellcode. Ein manipulierter Build-Prozess kann ein anderes Programm ausliefern als das zuvor geprüfte. Begrenzen Sie daher Änderungsrechte an Repositories, Build-Konfigurationen und Artefakten. Halten Sie nachvollziehbar fest, welche Version mit welchen wesentlichen Abhängigkeiten erstellt und freigegeben wurde. Änderungen an der Auslieferungskette verdienen dieselbe Aufmerksamkeit wie Änderungen an der Anwendung.
Eine Software Bill of Materials unterstützt das Komponenteninventar. Sie ist kein Beweis für Fehlerfreiheit und enthält nicht automatisch eine belastbare Aussage zur Ausnutzbarkeit jeder Schwachstelle. Für Entwickler ist ihr Nutzen besonders groß, wenn sie mit den tatsächlich ausgelieferten Versionen verbunden ist. Eine veraltete Stückliste zu einem ähnlichen Build kann bei einer Sicherheitsmeldung zu falschen Entscheidungen führen.
Beim Cyber Resilience Act ist die Rolle als Hersteller eines erfassten Produkts zu prüfen. Die grundsätzlich ab Dezember 2027 geltenden Anforderungen umfassen unter anderem eine maschinenlesbare SBOM mit mindestens den obersten Abhängigkeiten. Daraus folgt keine allgemeine SBOM-Pflicht für sämtliche KRITIS-Unternehmen schon seit 2025. Artikel 14 mit seinen Hersteller-Meldepflichten gilt dagegen bereits seit dem 11. September 2026; Produktpflege und Meldeorganisation sind deshalb zeitlich getrennt zu planen.
Fehlerzustände und Sicherheitsprotokolle gestalten
Legen Sie fest, wie die Anwendung bei fehlenden Abhängigkeiten, Zeitüberschreitungen oder erschöpften Ressourcen reagiert. Fällt die Berechtigungsprüfung aus, darf daraus nicht unbeabsichtigt eine allgemeine Freigabe entstehen. Bei mehrstufigen Vorgängen müssen unvollständige Zustände erkannt und kontrolliert behandelt werden. Ein erneuter Aufruf darf beispielsweise nicht ohne Prüfung dieselbe fachliche Transaktion mehrfach ausführen.
Nutzermeldungen sollten verständlich sein, ohne interne Schlüssel, vollständige Abfragen oder vertrauliche Daten preiszugeben. Für die technische Analyse kann gleichzeitig eine geschützte, eindeutig zuordenbare Fehlerinformation erforderlich sein. Trennen Sie deshalb das, was Betroffene zur Fortsetzung ihrer Arbeit benötigen, von detaillierten Diagnoseinformationen für berechtigte Mitarbeitende.
Sicherheitsprotokolle sollen eine konkrete Auswertung ermöglichen. Dokumentieren Sie relevante Ereignisse und die notwendigen Zuordnungsmerkmale; vermeiden Sie unnötige Inhalte, insbesondere Passwörter und vollständige sensible Nutzdaten. Ein absolutes Verbot personenbezogener Informationen in Logs wäre jedoch ebenso unpassend wie unbegrenztes Mitschreiben. Zweck, Rechtsgrundlage, Zugriffsschutz und Speicherdauer müssen zur tatsächlichen Nutzung passen.
Bestimmen Sie, welche Ereignisse eine Reaktion auslösen und wer sie übernimmt. Tausende Warnungen ohne Bewertung schützen ein System nicht verlässlich. Sinnvolle Begrenzungen, zusammengefasste Wiederholungen und überprüfte Alarmwege helfen dabei, relevante Vorgänge zu erkennen. Die Aufzeichnung sollte dabei gegen unberechtigte Veränderung und einen unkontrollierten Zugriff geschützt sein.
Datenschutz in Funktionen und Prüfungen übersetzen
Artikel 25 DSGVO verpflichtet den Verantwortlichen zu geeigneten Maßnahmen für Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Für das Entwicklungsteam wird daraus beispielsweise die Anforderung, unnötige Pflichtfelder zu vermeiden, Zugriffsmöglichkeiten zu begrenzen und zweckbezogene Löschfunktionen vorzusehen. Diese Entscheidungen lassen sich nicht vollständig an die spätere Administration abgeben.
Die allgemeinen Überlegungen zur datenschutzgerechten Technikgestaltung betreffen das gesamte Produktkonzept. Der gesonderte Beitrag zu Artikel 25 und datenschutzfreundlichen Voreinstellungen vertieft die rechtlichen Anforderungen. Sichere Software kann personenbezogene Daten technisch gut schützen und sie trotzdem für einen unzulässigen Zweck verarbeiten. Sicherheitsmaßnahmen ersetzen daher weder Rechtsgrundlage noch Zweckbegrenzung.
Für Entwicklungsumgebungen sind synthetische oder wirksam anonymisierte Beispieldaten oft eine geeignete praktische Wahl. Pseudonymisierte Daten bleiben personenbezogen, wenn eine Zuordnung weiterhin möglich ist. Werden echte Daten benötigt, sind Erforderlichkeit, Rechtsgrundlage, Zugriff und Schutz auch dort zu prüfen. Ein bloßes Etikett „Testdatenbank“ hebt die Anforderungen nicht auf.
Der risikogerechte Schutz nach Artikel 32 DSGVO umfasst auch regelmäßige Bewertung der Wirksamkeit und Wiederherstellbarkeit. Für erfasste Einrichtungen enthält das aktuelle BSIG zudem Anforderungen an sichere Entwicklung, Beschaffung und Wartung. Ob diese zusätzlichen Organisationspflichten greifen, ist anhand der NIS2-Einordnung in Deutschland zu prüfen. Eine erfolgreiche Codeprüfung ist weder eine vollständige Datenschutzprüfung noch ein Nachweis sämtlicher Unternehmenspflichten.
Überprüfung, Freigabe und spätere Korrekturen
Leiten Sie die Überprüfung aus den Sicherheitsanforderungen ab. Neben erlaubten Vorgängen sind unerlaubte Zugriffe, ungültige Eingaben, Grenzwerte und Ausfälle relevant. Statische Analyse, Komponentenprüfung und manuelle Durchsicht beantworten dabei unterschiedliche Fragen. Kein einzelnes Werkzeug kann zuverlässig bestätigen, dass sämtliche fachlichen Berechtigungsregeln richtig umgesetzt wurden.
Bei kritischen Änderungen ist eine unabhängige Durchsicht häufig eine sinnvolle Maßnahme. Legen Sie fest, welche Stellen besondere Aufmerksamkeit benötigen, etwa Autorisierung, Schlüsselverwendung und die Auslieferungskette. Ein Penetrationstest nach eingeordneten BSI-Empfehlungen kann die Überprüfung ergänzen. Sein Umfang und seine Grenzen müssen jedoch zum geprüften Stand passen; ein früherer Test deckt spätere Änderungen nicht automatisch ab.
Definieren Sie vor der Freigabe den Umgang mit offenen Befunden. Wer bewertet das Risiko, welche Ersatzmaßnahme besteht und bis wann erfolgt eine neue Entscheidung? Halten Sie auch fest, welcher tatsächliche Softwarestand freigegeben wird und wie eine problematische Auslieferung zurückgenommen werden kann. Ein formales Häkchen ohne diese Verbindung liefert wenig Unterstützung bei einer späteren Störung.
Wird eine Schwachstelle bekannt, müssen technische Behebung und mögliche Datenschutzvorfallprüfung parallel betrachtet werden. Eine Schwachstelle ist nicht automatisch eine Verletzung personenbezogener Daten. Liegt eine solche Verletzung vor, gilt die Behördenmeldung unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, sofern ein Risiko nicht unwahrscheinlich ist; Verzögerungen sind zu begründen. Alle Datenschutzverletzungen sind zu dokumentieren, auch ohne Meldung. Die unverzügliche Information Betroffener bei wahrscheinlich hohem Risiko ist zusätzlich nach Artikel 34 einschließlich seiner Ausnahmen zu beurteilen.
Sicheres Entwickeln wird damit zu einem überprüfbaren Ablauf: Anforderungen beschreiben das erlaubte Verhalten, Architektur und Code setzen es um, geeignete Prüfungen suchen nach Abweichungen und der Betrieb ermöglicht spätere Korrekturen. Entscheidend ist, dass diese Schritte am tatsächlich ausgelieferten Produkt zusammenpassen und bei relevanten Änderungen erneut bewertet werden.