Sichere Programmierung, im Code.
ISO 27001:2022 A.8.28 (sichere Programmierung) betrifft die Anwendung von Prinzipien der sicheren Programmierung, damit Software nicht mit den Schwachstellen ausgeliefert wird, auf die Angreifer angewiesen sind: Injektionen, unsichere Verarbeitung von Eingaben und Ausgaben, unsichere Standardwerte. Von allen Annex-A-Kontrollen ist sie diejenige, die am direktesten im Code verankert ist, was den Pull Request zum natürlichen Ort macht, um sie zu prüfen.
The shapes the same control failure takes.
A.8.28 wird geschwächt, wenn eine Änderung ein bekanntes, unsicheres Muster einführt oder eine Abwehr dagegen entfernt. Die wiederkehrenden Muster:
Eine Abfrage wird durch Stringverkettung erstellt
Benutzereingaben werden direkt in einen SQL-, Shell- oder Abfragestring interpoliert, anstatt als Parameter übergeben zu werden, wodurch ein Injektionspfad geöffnet wird.
Ausgaben werden unmaskiert ausgegeben
Benutzerkontrollierte Daten werden in HTML, eine Vorlage oder eine Antwort geschrieben, ohne maskiert zu werden, wodurch ein Cross-Site-Scripting-Pfad geöffnet wird.
Ein Sicherheits-Lint oder eine Prüfung wird deaktiviert
Eine Regel für die statische Analyse oder ein Sicherheits-Linter wird stummgeschaltet (z. B. durch eine Inline-Ignorierung oder eine deaktivierte Regel), um eine Änderung durchzulassen, anstatt das Problem zu beheben, das es gemeldet hat.
Nicht vertrauenswürdige Eingaben werden deserialisiert
Daten von außerhalb der Vertrauensgrenze werden in Objekte deserialisiert oder ausgewertet, ein klassisches Muster für Remote-Code-Ausführung.
Validierung wird entfernt
Eingabevalidierung oder -bereinigung, die einen Pfad geschützt hat, wird bei einer Überarbeitung entfernt, sodass fehlerhafte oder feindselige Eingaben nun die dahinterliegende Logik erreichen.
Eine Abfrage, die aus Benutzereingaben zusammengesetzt wird.
Es wird eine Suchfunktion hinzugefügt. Der schnellste Weg, nach dem Suchbegriff des Benutzers zu filtern, besteht darin, ihn direkt in den SQL-String einzufügen. Das funktioniert bei normalen Eingaben, ist aber eine SQL-Injektion: Ein manipulierter Begriff kann Daten lesen oder ändern, auf die er keinen Zugriff haben sollte.
- const rows = await db.query("SELECT * FROM items WHERE name = $1", [term])+ const rows = await db.query(`SELECT * FROM items WHERE name = '${term}'`)return rowsDie Interpolation des Suchbegriffs in den SQL-String ist ein SQL-Injektionspfad: Ein manipulierter Begriff bricht aus dem String aus und wird als Abfragelogik ausgeführt. A.8.28 (sichere Programmierung) erwartet genau, dass diese Art von Schwachstellen vermieden wird. Kehren Sie zu einer parametrisierten Abfrage zurück, die die Eingabe als Daten und nicht als Code behandelt.
Sichere Programmierung wird auf Prozessebene und im Code geprüft.
Ein Prüfer sucht nach Beweisen, dass sichere Programmierung Teil Ihres Prozesses ist: Code-Review, statische Analyse, Abhängigkeitsscans und dass die Ergebnisse bearbeitet werden. Eine Änderung, die einen Injektionspfad einführt oder eine Sicherheitsprüfung deaktiviert, ist das konkrete Versagen hinter diesem Prozess, und es ist im Diff sichtbar. Wenn es im Review erkannt wird, ist das sowohl die Korrektur als auch der Beweis, dass der Prozess funktioniert.
Ein Review, kein vollständiges SAST-Tool.
heygrc markiert Änderungen, die A.8.28 betreffen, und verweist auf die Kontrolle, sodass die Korrektur im Pull Request erfolgt. Es ist kein Ersatz für Ihre statische Analyse oder Ihre Sicherheitstests, sondern die frameworkbewusste Ebene, die eine Schwachstelle bei der sicheren Programmierung mit der Kontrolle verknüpft, die sie verletzt.