Standard IT-Sicherheit R0129 Standard DevSecOps Adrian A. Baumann Anthony Kalbermatten Emily Hentgen Fritz Weyermann Jan Hohenauer Levent Ildeniz Mantas Meleskevicius Oliver Eichenberger Ray Miller Roger Solioz Thomas Surachi Burkhalter Adrian A. Baumann Die Sicherheitsanforderung dient unter anderem als Grundlage zur Freigabe des CHECK-Prozesses. Sie dient darüber hinaus als Umsetzungsempfehlung für die Vorgaben der Sicherheits-Richtlinien im BIT. Die Anforderungen müssen bereits während der Planungs- und Entscheidungsprozesse berücksichtigt werden. Fehlen IT-Richtlinien zu bestimmten Technologien, gelten die Umsetzung der Best-Practices der Hersteller und die CIS-Benchmark’s des jeweiligen Produktes. Bei der Umsetzung der Sicherheitsanforderungen sind die relevanten Gesetze (insbesondere das Gesetz über die Informationssicherheit beim Bund und die dazugehörende Verordnung) einzuhalten. Die IT-Grundschutzanforderungen des Staatssekretariats für Sicherheitspolitik (SEPOS) sind zwingend. Ausnahmen sind schriftlich zu dokumentieren und durch den ISBO VE zu genehmigen. **DevSecOps** ist die Methode zur automatisierten Integration von Sicherheitstools in den DevOps-Prozess. Bei DevSecOps geht es nicht nur um die Werkzeuge, sondern auch um das erforderliche Wissen über die Verwendung dieser Werkzeuge und wie die Sicherheitsvorgaben überprüft und nachgewiesen werden können. Dies führt zu einer kulturellen Veränderung der normalen Funktionsweise von DevOps. Durch effizientere Zusammenarbeit und Schaffung einer Sicherheitskultur kann in der gesamten DevOps-Kreislaufkette die Sicherheit erhöht werden. Dieser Standard unterliegt den Definitionen des Zentraldokuments für Standards IT-Sicherheit. Ziel & Zweck, Änderungswesen etc. sind da definiert und werden hier nicht wiederholt. Einige relevante Sicherheitsvorgaben im Zusammenhang mit DevSecOps werden in anderen Standards vorgegeben. Besonders hervorzuheben sind hier: R0097 Anwendungsentwicklung [R0126](../R0126/) Container R0123 Sicherheitsdokumente Information Security Management BIT 1 Einhaltung der Entwicklungsrichtlinien Anwendungen Die Entwicklungsrichtlinien und Guidelines müssen eingehalten werden. Siehe hierzu auch den «Best Practice Leitfaden Development» Der Quelltext soll einer Reihe formaler Prüfungen unterzogen werden. 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). Security-by-Design-Prinzip Standards BIT 2026-02-11 Ein Vier-Augen-Prinzip für PRs ist in Kraft. Es sind keine Secrets im Code gespeichert. 2 Security Code Review Anwendungen Sensitive Funktionen müssen im vier-Augen-Prinzip auf Sicherheit geprüft werden. 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. Security-by-Design-Prinzip 2026-02-11 Security Code Reviews erfolgen durch unabhängige Reviewer und sind dokumentiert. 3 Security Requirements und Threat Modeling Anwendungen Security Requirements und Threat Modeling müssen für Anwendungen definiert und 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 T4 (Schwachstellen und Verwundbarkeiten) 2026-02-11 Die Security-Anforderungen sind definiert. Risiken und deren Behandlung sind dokumentiert. 4 Supply Chain Security Anwendungen Die Integrität von Source Code und Build-Artefakten muss sichergestellt werden. 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") O2.1 2026-02-11 Commits sind digital signiert. Es sind keine Abhängigkeiten mit ":latest" getaggt. Alle Abhängigkeiten sind mit fixen Versionen getaggt. 1 Kontrolle der Sicherheitsdokumente Informationen Die Sicherheitsdokumente aller DevSecOps-Vorhaben müssen vollständig sein und regelmässig geprüft werden. 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". Art. 6: Art. 6 Informationssicherheit Art. 27: Art. 27 Sicherheitsverfahren 2026-02-11 Die Sicherheitsdokumente sind vorhanden und aktuell. 2 Design- und Architektur-Review Informationen Design und Architektur müssen in regelmässigen Abständen geprüft und angepasst werden 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 Security-by-Design-Prinzip 2026-02-11 Die Architektur-Dokumentation ist aktuell. Architektur-Reviews werden periodisch durchgeführt. 3 Secret Management Informationen Secrets müssen in einem dafür geeigneten System verwaltet werden. 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 Need-to-Know-Prinzip Stand der Technik 2026-02-11 Zugriff auf Secrets ist rollenbasiert eingeschränkt. Zentrales Secret-Management-System ist im Einsatz Secrets sind nicht in Code oder Config abgelegt. 1 Anwendung SAST und DAST Systeme Applikationen müssen regelmässig durch statische und dynamische Codeanalyse auf Schwachstellen untersucht werden. 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. T4 (Schwachstellen und Verwundbarkeiten) 2026-02-11 Schwachstellen werden zentral verwaltet. 2 Secret Scanning Systeme Container-Images und Repositories müssen auf offengelegte Geheimnisse überprüft werden 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. T2: Konfiguration und Einstellung 2026-02-11 Container Image Secret Scanning ist aktiv. Repository Secret Scanning ist aktiv. Secret-Leaks werden dokumentiert. 3 Security Unit Tests durchführen Systeme Security-Unit-Tests müssen im Rahmen der Entwicklung durch die Entwickler (bzw. die Lieferanten) erstellt und gepflegt werden. 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. T4 (Schwachstellen und Verwundbarkeiten) 2026-02-11 Security Unit Tests sind implementiert. 4 Container Image Scanning Systeme Vor der ersten produktiven Verwendung muss ein Container Image auf Schwachstellen gescannt werden, anschliessend periodisch. 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. T4 (Schwachstellen und Verwundbarkeiten) 2026-02-11 Container Image Scanning ist automatisiert. Scan erfolgt vor Erstdeployment und periodisch. Images mit CVSS ≥ 7 werden nicht deployed oder sind genehmigt. 5 Automatisierte Deployments Systeme Es darf ausschliesslich mit automatisierten Prozessen auf produktive Systeme deployed werden. 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. Stand der Technik 2026-02-11 Deployments erfolgen ausschliesslich über Pipeline Manuelle Produktionsdeployments sind dokumentiert und genehmigt 1 Software Composition Analysis (SCA) Technik 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. 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. T4 (Schwachstellen und Verwundbarkeiten) 2026-02-11 Dependencies werden mindestens wöchentlich gescannt.