Die Entwicklungsrichtlinien und Guidelines müssen eingehalten werden. Siehe hierzu auch die Sicherheitsvorgaben zur Softwareentwicklung

Der Quelltext soll einer Reihe formaler Prüfungen unterzogen werden. Dabei ist insbesondere folgendes zu beachten (nicht abschliessend):

• Umgebungsvariablen (Secrets, Env) überprüfen
• Passwörter und andere Credentials dürfen nicht im Klartext enthalten sein

Die Reviews sollten laufend im Rahmen der Pull Requests erfolgen, wenn Features oder Bug Fixes entwickelt werden. Eine konsequente Nutzung von Pull Requests während der Entwicklung sollte mit Approval (Genehmigung) durch eine andere Person aus dem DevOps-Team erfolgen. Zusätzlich besteht ein Quality Gate (keine High/Critical-Befunde) in der Pipeline aus der statischen Code-Analyse (SonarQube).

Für sensitive Funktionen in Programmcode muss eine manuelle Prüfung auf Sicherheit erfolgen. Diese darf nicht vom Autor des Codes selbst durchgeführt werden.

Für neue Anwendungen sowie für grössere Änderungen müssen Security Requirements definiert werden. Zusätzlich muss ein Threat Modeling durchgeführt werden, um Bedrohungen systematisch zu identifizieren und Gegenmassnahmen abzuleiten.

Mindestens erforderlich:

• Security-Anforderungen pro Feature, Release oder Komponente definieren
• Threat Modeling vor Major Releases oder Architekturänderungen durchführen
• Risiken und Gegenmassnahmen dokumentieren

Die Entwicklungs-Supply-Chain muss gegen Manipulation geschützt werden. Die Nachvollziehbarkeit und Integrität von Code, Dependencies und Build-Artefakten muss gewährleistet sein.

Dies kann mit folgenden Punkten umgesetzt werden:

• Commits sollten digital signiert werden
• Dependencies müssen auf fixe Versionen gepinnt werden (kein ":latest")

Die Sicherheitsdokumente aller DevSecOps-Vorhaben müssen vollständig sein. Bei grösseren sicherheitsrelevanten Anpassungen am Schutzobjekt, oder spätestens nach fünf Jahren, müssen die Dokumente auf Aktualität geprüft und gegebenenfalls überarbeitet werden. Die Anforderungen an die Dokumente befinden sich im Zentraldokument "Standard IT-Sicherheit".

Damit die Sicherheitsmassnahmen an den aktuellen Stand der Technik angepasst werden können, müssen Design und Architektur in regelmässigen Abständen geprüft und modernisiert werden. Dabei sind insbesondere auch Sicherheitsaspekte zu berücksichtigen.

Nachfolgende Elemente sind zu überprüfen:

• Architekturskizze
• Solution Design
• Konzeptionelle Fehler und Verwundbarkeiten
• Die Ergebnisse der Datenflussanalyse
• Schnittstellen zu anderen Komponenten
• Zugangspunkte
• Abhängigkeiten
• Rollen und Berechtigungskonzept

Secrets müssen sicher verwaltet und gespeichert werden. Dazu ist eine geeignete Secret-Management-Lösung einzusetzen, z.B. HashiCorp Vault. Als Secrets gelten unter anderem

• Passwörter
• Private Schlüssel
• API Tokens für andere Dienste

Applikationen und Infrastruktur müssen mittels SAST im Minimum auf die aktuellen OWASP Top 10 und allgemeine Good- und Best-Practices getestet werden. Schwerwiegende oder kritische Befunde sind zwingend vor einem Deployment zu beheben. Falls dies nicht möglich ist, ist eine entsprechende Ausnahmenbewilligung vom ISBO einzuholen.

Alle identifizierten Schwachstellen müssen zentral verwaltet werden. Deren Behebung muss geplant werden, wenn keine entsprechende Ausnahmebewilligung vorliegt.

Alle Container-Images, Dateisysteme und Git-Repositories müssen auf offengelegte Geheimnisse wie Passwörter, API-Schlüssel, Token etc. gescannt werden.

Das Source-Code-Repository muss auf bekannte Geheimnistypen überprüft werden, um das betrügerische Verwenden von Geheimnissen zu verhindern, die aus Versehen committet wurden. Bei der Prüfung gefundene Secrets müssen unverzüglich deaktiviert (geändert oder revoziert) werden, dies ist entsprechend im Repository zu dokumentieren.

Security-Unit-Tests müssen im Rahmen der Entwicklung durch die Entwickler (bzw. die Lieferanten) erstellt und gepflegt werden.

Logische Fehler in der Webanwendung können damit identifiziert und korrigiert werden.

Idealerweise werden die Unit-Tests in den Commit-Workflow eingefügt, so dass sie vor jedem Commit durchlaufen und den Commit im Fall von "Fail"-Status abbrechen.

Container Images müssen regelmässig und automatisiert auf Schwachstellen und Fehlkonfigurationen überprüft werden. Bei der Verwendung von Container Images ist sicherzustellen, dass deren jeweilige Integrität geprüft wird, damit nur geprüfte Container Images verwendet werden. Deployments mit Produktionsdaten sind nicht erlaubt, wenn im Container Image Schwachstellen mit CVSS grösser oder gleich 7 vorhanden sind. Ausnahmen werden durch den ISBO behandelt.

Der aktuelle Sicherheitsstand jedes Container Images muss zentral einsehbar sein.

Deployments müssen als Konfigurationen/Code vorliegen (Infrastructure-as-Code) und entsprechend in einem Versionierungssystem (z.B. Bitbucket) geführt werden. Es darf ausschliesslich automatisiert auf produktive Systeme deployed werden – manuelle Eingriffe sind nur in Ausnahmefällen gestattet und müssen dokumentiert werden.

Jede verwendete Abhängigkeit muss mindestens einmal pro Woche (idealerweise häufiger) auf Schwachstellen gescannt werden. Der Scan sollte vollständig automatisiert als Teil der Pipeline ablaufen.

• Bibliotheken und vergleichbare Abhängigkeiten müssen mittels Vulnerablity Scanning auf Sicherheitslücken getestet werden.
• Schwerwiegende oder gar kritische Befunde sind zwingend vor einem Deployment zu beheben oder eine Ausnahmebewilligung einzuholen.
• Alle identifizierten Schwachstellen müssen zentral verwaltet werden und entweder deren Behebung geplant oder eine Ausnahmebewilligung eingeholt werden.
• Deployments mit Produktionsdaten sind nicht erlaubt, wenn Komponenten mit CVSS grösser oder gleich 7 (Critical) eingesetzt werden. Der Scan sollte vollständig automatisiert als Teil der Pipeline ablaufen. Bei schwerwiegenden Sicherheitsproblemen wird die Pipeline unterbrochen und schlägt fehl, bis das Problem behoben ist.