Planung und Vorcodierung
Sowohl bei der Neuentwicklung als auch bei der Wiederverwendung von Code gilt es, die Grundsätze der sicheren Codierung anzuwenden – unabhängig davon, ob der Code für interne Software oder für externe Produkte und Dienstleistungen geschrieben wird. Dies setzt im Vorfeld die Evaluierung der organisationsspezifischen Erwartungshaltung und Festlegung anerkannter Grundsätze voraus. Darüber hinaus berücksichtigen die Handlungsempfehlungen zur Planung und Vorcodierung bekannte gängige und historische Codierungspraktiken und Fehler, die zu Schwachstellen führen könnten.
Die Konfiguration von Entwicklungswerkzeugen sollte, zum Beispiel regelbasiert in integrierten Entwicklungsumgebungen (IDE), die Erstellung von sicherem Code erzwingen. Ganz entscheidend ist die Qualifikation der Entwickler und deren Vertrautheit mit sicheren Architekturen und Programmierstandards. Die Einbindung von Informationssicherheitskompetenz im Entwicklerteam versteht sich selbstredend.
Während der Codierung
Im laufenden Codierungsprozess spielen vor allem die Codierungspraktiken und strukturierte Programmiertechniken eine Rolle, unter Berücksichtigung des spezifischen Anwendungsfalls und dessen Sicherheitsbedürfnissen. Unsichere Design-Techniken – zum Beispiel fest codierte Kennwörter – sind konsequent zu verbieten. Der Code sollte ausreichend dokumentiert und überprüft werden, um sicherheitsrelevante Fehler bestmöglich zu beseitigen. Die Codeprüfung sollte sowohl während als auch nach der Entwicklung erfolgen, zum Beispiel über statische Anwendungssicherheitstests (SAST). Statische Testverfahren unterstützen den Shift Left Ansatz („Teste früh und oft“) durch Linksverschiebung im Lebenszyklus, indem früh der sichtbare Code auf Regelkonformität geprüft wird.
Damit lassen sich „tainted Code“ (verunreinigter Code), Verbindungen zu Dateien oder bestimmten Objektklassen oder aber Lücken auf Applikationsebene, die für unbemerkte Interaktion mit Fremdprogrammen missbraucht werden können, frühzeitig als ausnutzbare Schwachstellen identifizieren. Vor Inbetriebnahme der Software verlangt das Control 8.28 eine Bewertung von Angriffsflächen und der Umsetzung des Least-Privilege-Prinzips. Die durchgeführte Analyse der häufigsten Programmierfehler und Dokumentation ihrer Behebung sollten bewertet werden.
Überprüfung und Wartung
Auch nach der Inbetriebnahme der Software bleibt das Thema sicheres Coding relevant. Hierzu gehören sichere Updates sowie Kontrollen, ob bekannt gewordene Schwachstellen im eigenen Code vorhanden sind. Darüber hinaus müssen Fehler und vermutete Angriffe dokumentiert werden, um notwendige Anpassungen zeitnah vornehmen zu können. In jedem Fall muss der unbefugte Zugriff auf den Quellcode durch geeignete Tools zuverlässig ausgeschlossen werden.
Open Source Code
Im Bereich Überprüfung und Wartung listet Maßnahme 8.28 zusätzlich explizite Handlungsanweisungen für den Einsatz externer Tools und Bibliotheken – wie zum Beispiel Open Source Software – auf. Diese Code-Bestandteile sollten in Inventarlisten verwaltet, aktualisiert und gewartet werden. Dies kann unter anderem über eine Software Bill of Material (SBOM) erfolgen. Eine SBOM ist eine formale, strukturierte Aufzeichnung über die Pakete und Bibliotheken einer Software und ihre Beziehungen untereinander sowie innerhalb der Lieferkette, um insbesondere den Überblick über wiederverwendeten Code und Open-Source-Komponenten zu behalten. Die SBOM unterstützt die Wartbarkeit von Software und zielgerichtete Sicherheitsupdates.