Softwareentwicklung: So bauen Sie Sicherheit in den Code ein

Sichere Softwareentwicklung beginnt nicht beim Penetrationstest kurz vor Go-live. Sie beginnt deutlich früher: bei den Anforderungen, der Architektur, den Entwicklungsgrundsätzen und der Frage, wie Sie Sicherheit in den normalen Entwicklungsprozess einbauen. Genau darum geht es bei ISO 27001 A.8.26 bis A.8.29: Sicherheitsanforderungen müssen früh geklärt werden, sichere Architektur- und Entwicklungsgrundsätze müssen feststehen, sichere Codierung muss angewandt werden, und Sicherheitsprüfungen müssen in den Entwicklungslebenszyklus integriert sein. Das Secure Software Development Framework (SSDF) von NIST beschreibt genau diese Grundidee: sichere Entwicklungspraktiken sollen in den gesamten Software Development Lifecycle (SDLC) integriert werden, um Schwachstellen in ausgelieferter Software zu reduzieren.

Die kurze Antwort

Wenn Sie sichere Softwareentwicklung ernst meinen, brauchen Sie vier Dinge:

• klare Sicherheitsanforderungen vor dem ersten Ticket;
• nachvollziehbare Architektur- und Entwicklungsgrundsätze;
• tech-stack-spezifische Secure-Coding-Regeln;
• Sicherheitsprüfungen, die nicht am Ende angeflanscht, sondern in den normalen Entwicklungsfluss eingebaut sind.

Genau diese Logik steckt auch in etablierten Praxisrahmen: Der SSDF beschreibt sichere Entwicklung als festen Bestandteil des SDLC, OWASP ASVS liefert einen Katalog konkreter Sicherheitsanforderungen für moderne Webanwendungen, und der OWASP Secure Coding Guide ist ausdrücklich dafür gedacht, Coding-Praktiken in den Entwicklungslebenszyklus zu integrieren.

ISO 27001 A.8.26 bis A.8.29 in normaler Sprache

Wenn man die vier Anforderungen in normale Projektsprache übersetzt, kommt ungefähr das hier heraus:

A.8.26: Bevor ihr baut, müsst ihr wissen, was die Anwendung in puncto Sicherheit können und aushalten muss.

A.8.27: Ihr braucht feste Leitplanken für sichere Architektur und Entwicklung.

A.8.28: Entwickler sollen nicht "nach Bauchgefühl sicher coden", sondern nach klaren Regeln.

A.8.29: Sicherheit muss geprüft werden - und zwar nicht nur am Ende, sondern entlang des Entwicklungsprozesses.

Das ist keine unnötige Bürokratie. Das ist schlicht die Voraussetzung dafür, dass Sicherheit nicht zufällig entsteht.

Sicherheitsanforderungen gehören in die Storys, nicht in die Nacharbeit

Der erste Fehler passiert oft ganz am Anfang: Es gibt gute fachliche Anforderungen, aber die Sicherheitsanforderungen bleiben diffus. Dann heißt es später: "Ach stimmt, Login-Schutz, Logging, Rechtekonzept, Session Handling und sichere Passwortrichtlinien brauchen wir ja auch noch." Genau das macht Projekte zäh.

Sinnvoll ist deshalb, Sicherheitsanforderungen von Anfang an wie normale Produktanforderungen zu behandeln. Für Webanwendungen bietet sich dafür zum Beispiel ASVS als strukturierte Grundlage an. Dort sind Anforderungen nicht als abstrakte Theorie beschrieben, sondern als konkrete Maßnahmen für Design, Entwicklung und Prüfung moderner Anwendungen.

Praktisch heißt das zum Beispiel:

• Welche Rollen und Berechtigungen braucht die Anwendung?
• Welche Daten sind besonders schützenswert?
• Welche sicherheitsrelevanten Ereignisse müssen geloggt werden?
• Welche Authentisierung ist nötig?
• Welche Eingaben müssen validiert werden?
• Welche Schnittstellen dürfen was?

Wenn diese Fragen erst kurz vor Abnahme auftauchen, ist das Projekt meistens schon unnötig teuer geworden.

Sichere Architektur entsteht nicht im Code-Review

Viele Sicherheitsprobleme sind keine reinen Programmierfehler, sondern Architekturfehler. Schlechte Mandantentrennung, unklare Vertrauensgrenzen, überprivilegierte Services, zu breite APIs oder fehlende Segmentierung lösen Sie nicht mit einem einzelnen Code-Review.

Hier bietet es sich daher an, für die eigene Entwicklung ein paar verbindliche Architekturgrundsätze festzulegen. Das können zum Beispiel sein:

• keine direkte Datenbankfreigabe aus Frontends;
• Admin-Funktionen sauber getrennt von Normalbenutzerfunktionen;
• klare Trust Boundaries zwischen Diensten;
• Secrets niemals im Code oder in Repos;
• standardisierte Authentisierung und Autorisierung statt Eigenbau;
• sichere Standardbibliotheken und Frameworks bevorzugen,

Der NIST SSDF und die OWASP Secure Coding Practices setzen genau auf diese frühe Verankerung: sichere Entwicklung beginnt vor der Implementierung und wird nicht erst durch spätere Prüfungen "geheilt".

Secure Coding darf nicht nur "allgemein vernünftig" heißen

A.8.28 ist in der Praxis nur dann brauchbar, wenn Entwickler wissen, welche Regeln konkret für ihren Stack gelten. „Bitte sicher programmieren“ ist keine Arbeitsanweisung.

Sinnvoll ist deshalb, für den tatsächlich verwendeten Tech-Stack maßgeschneiderte Secure-Coding-Guidelines zu definieren. Also nicht nur allgemein, sondern etwa für:

• Java/Spring;
• .NET;
• Node.js;
• Python;
• PHP;
• React, Angular oder mobile Clients;
• Terraform, Helm oder Infrastructure-as-Code.

OWASP stellt mit dem Secure Coding Practices Guide bewusst eine technologieagnostische Basis bereit, die in konkrete Coding-Anforderungen übersetzt werden kann. Genau daraus lässt sich intern ein stack-spezifischer Standard ableiten.

Praktisch heißt das zum Beispiel:

• keine SQL-Queries per String Concatenation;
• konsequente Output-Encoding-Regeln;
• sichere Session- und Token-Behandlung;
• keine selbstgebauten Crypto-Lösungen;
• Input-Validierung serverseitig;
• Secrets nur aus sicheren Secret Stores;
• sichere Fehlerbehandlung ohne Informationsleckage.

Je klarer diese Regeln sind, desto weniger hängt sichere Entwicklung am Talent einzelner Entwickler.

Code-Review bleibt Pflicht - aber bitte nicht nur auf Stil und Lesbarkeit

Viele Teams reviewen Code bereits. Das ist gut. Aber oft wird dabei vor allem auf Stil, Wartbarkeit und Fachlogik geschaut. Sicherheitsseitig reicht das nicht.

Es empfiehlt sich daher, Security-Aspekte fest in Pull-Request-Reviews einzubauen. Der OWASP Secure Code Review Cheat Sheet beschreibt genau das sehr praxisnah und ordnet Sicherheits-Code-Reviews ausdrücklich in den normalen Entwicklungsfluss ein - bei Pull Requests, Commits und täglicher Entwicklung.

Sinnvolle Review-Fragen sind zum Beispiel:

• Kann ein Benutzer hier mehr, als er soll?
• Werden Eingaben sauber validiert?
• Ist das Logging sicherheitsrelevant und brauchbar?
• Entstehen neue Angriffsflächen durch Fehlermeldungen?
• Werden Secrets oder sensible Daten sauber behandelt?
• Ist die Änderung mandantenfähig und berechtigungsfest?

Sicherheitsprüfungen gehören in die Build-Pipeline

A.8.29 wird in vielen Teams erst dann ernst genommen, wenn kurz vor Release noch ein Sicherheitstest organisiert werden muss. Das ist zu spät. Sicherheitsprüfungen wirken am besten, wenn sie in den normalen Entwicklungsablauf eingebaut sind.

Hier bietet es sich daher an, mehrere Ebenen zu kombinieren:

• statische Code-Analyse;
• Dependency-Scanning beziehungsweise SCA;
• Secrets-Scanning;
• Container- oder IaC-Scanning, wenn relevant;
• DAST oder API-Tests für laufende Systeme;
• gezielte manuelle Security-Reviews an heiklen Stellen.

Der SSDF empfiehlt, Sicherheitsprüfungen und andere Verifikationsmaßnahmen fest in den Entwicklungsprozess einzubetten, statt sie als Einmalaktion am Ende zu behandeln.

Praktisch ist es oft sehr wirksam, das direkt in die CI/CD-Pipeline zu ziehen:

• Pull Request triggert SAST;
• Build prüft Dependencies und bekannte Schwachstellen;
• Secrets-Scanner blockiert versehentliche Schlüssel im Repo;
• bei kritischen Findings schlägt die Pipeline fehl;
• Security-relevante Findings werden nicht nur erzeugt, sondern einem Team oder Owner zugeordnet.

So wird Sicherheit nicht zur Sonderwelt neben der Entwicklung, sondern Teil des normalen Lieferprozesses.

KI kann helfen - aber sie ersetzt keine sichere Entwicklung

KI-gestützte Code-Analyse kann heute sinnvoll sein, etwa als zusätzliche Ebene bei Review, Mustererkennung oder Erklärbarkeit von Findings. Sie kann Teams beschleunigen. Sie sollte aber nicht die einzige Sicherheitsprüfung sein. Der saubere Weg bleibt: klare Anforderungen, sichere Architektur, definierte Coding-Regeln und mehrere Prüfmechanismen. KI ist dann ein Beschleuniger, nicht das Sicherheitsfundament.

Inhouse-Entwicklung ist kein Freifahrtschein

Gerade interne Entwicklung wird oft zu locker behandelt. Dann heißt es: "Wir kennen unsere Leute, wir bauen das selbst, das passt schon." Das ist nicht  zu empfehlen.

Inhouse-Entwicklung braucht dieselbe Disziplin wie jede andere professionelle Softwareentwicklung. Vielleicht sogar mehr, weil man sich intern leichter etwas schönredet. Sichere Entwicklung lebt davon, dass Regeln festgelegt, dokumentiert, aufrechterhalten und angewandt werden. Genau das ist der eigentliche Kern der Anforderungen aus ISO 27001 A.8.27 bis A.8.29.

Der häufigste Denkfehler

Der häufigste Denkfehler lautet: "Wir machen erst mal die Features fertig und prüfen Sicherheit später." Das ist fast immer teurer als der umgekehrte Weg. Dazu kommt: Am Ende, wenn die Zeit knapp wird, wird es doch nicht gemacht.

Wenn Sicherheitsanforderungen fehlen, Architektur unsauber ist und Tests erst am Ende auftauchen, rächt sich das mit Nacharbeiten, Reibung und Diskussionen kurz vor Abnahme. Sichere Softwareentwicklung ist deshalb nicht langsamere Entwicklung, sondern meist die reifere und planbarere Entwicklung. Der SSDF ist genau auf diese Integration in den normalen Entwicklungsprozess ausgelegt.

Ein pragmatischer Start für Entwicklungsteams

Wenn das Thema sauber, aber ohne Overhead angegangen werden soll, reicht für den Start oft schon diese Linie:

1. Sicherheitsanforderungen in die normale Anforderungsarbeit aufnehmen

Nicht separat irgendwo im Wiki, sondern direkt in Epics, Stories, Akzeptanzkriterien und Architekturentscheidungen. ASVS eignet sich gut als Quelle für konkrete Anforderungen.

2. Für den verwenden Tech-Stack verbindliche Secure-Coding-Guidelines erstellen

Keine generische Folienwelt, sondern klare Regeln für die tatsächlich verwendeten Technologien. Die OWASP Secure Coding Practices sind dafür eine gute Basis.

3. Security-relevante Architekturprinzipien festziehen

Zum Beispiel Authentisierung, Autorisierung, Secrets, Logging, Datenfluss, Verschlüsselung bei Speicherung und Übertragung, Mandantentrennung und Fehlerbehandlung. Das schafft Leitplanken, bevor Code entsteht.

4. Sicherheitsprüfungen in den normalen Delivery-Prozess ziehen

Static Application Secutiy Testing (SAST), Dependency-Checks, Secrets-Scanning und gezielte manuelle Reviews gehören nicht an den Rand, sondern in die Pipeline und in den Pull-Request-Prozess.

5. Findings nicht nur erzeugen, sondern verantworten lassen

Ein Scan ohne Owner bringt wenig. Jeder kritische Fund braucht einen Verantwortlichen, Priorität und eine nachvollziehbare Entscheidung.

Was will der Auditor sehen?

Ein Auditor will in diesem Thema nicht hören: "Unsere Entwickler sind erfahren, die machen das schon vernünftig." Er will erkennen, dass sichere Softwareentwicklung geregelt ist. Also: Sicherheitsanforderungen werden früh festgelegt, Architekturgrundsätze existieren, Secure-Coding-Regeln sind definiert, und Sicherheitsprüfungen sind in den Entwicklungslebenszyklus eingebaut. Genau das ist die praktische Auditlogik hinter A.8.26 bis A.8.29. Die etablierten Praxisrahmen stützen diese Sicht sehr klar.

FAQ

Interesse geweckt?

Wenn Sie im Rahmen einer ISO 27001-Zertifizierung sichere Softwareentwicklung so aufsetzen wollen, dass sie im Alltag funktioniert und nicht nur auf dem Papier gut aussieht, dann lassen Sie uns sprechen oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!