{ "Typ": "Standard IT-Sicherheit", "Nummer": "R0129", "Name": "Standard DevSecOps", "Autoren": [ "Adrian A. Baumann", "Anthony Kalbermatten", "Emily Hentgen", "Fritz Weyermann", "Jan Hohenauer", "Levent Ildeniz", "Mantas Meleskevicius", "Oliver Eichenberger", "Ray Miller", "Roger Solioz", "Thomas Surachi Burkhalter" ], "Pruefende": [ "Adrian A. Baumann" ], "Gueltigkeit": { "Von": "", "Bis": null }, "SignaturCSO": "", "Geltungsbereich": { "Abschnitt": [ { "typ": "text", "inhalt": "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." } ] }, "Einleitung": { "Abschnitt": [ { "typ": "text", "inhalt": "**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." }, { "typ": "text", "inhalt": "Dieser Standard unterliegt den Definitionen des Zentraldokuments für Standards IT-Sicherheit. Ziel & Zweck, Änderungswesen etc. sind da definiert und werden hier nicht wiederholt." }, { "typ": "text", "inhalt": "Einige relevante Sicherheitsvorgaben im Zusammenhang mit DevSecOps werden in anderen Standards vorgegeben. Besonders hervorzuheben sind hier:" }, { "typ": "liste ungeordnet", "inhalt": "R0097 Anwendungsentwicklung\r\n[R0126](../R0126/) Container\r\nR0123 Sicherheitsdokumente" } ] }, "Ziel": "", "Grundlagen": "", "Changelog": [], "Anhänge": "", "Verantwortlich": "Information Security Management BIT", "Klassifizierung": null, "Glossar": {}, "Vorgaben": [ { "Nummer": "1", "Titel": "Einhaltung der Entwicklungsrichtlinien", "Thema": "Anwendungen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Die Entwicklungsrichtlinien und Guidelines müssen eingehalten werden. Siehe hierzu auch den «Best Practice Leitfaden Development»\r\n\r\nDer Quelltext soll einer Reihe formaler Prüfungen unterzogen werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "Die Entwicklungsrichtlinien und Guidelines müssen eingehalten werden. Siehe hierzu auch die Sicherheitsvorgaben zur Softwareentwicklung\r\n\r\nDer Quelltext soll einer Reihe formaler Prüfungen unterzogen werden. Dabei ist insbesondere folgendes zu beachten (nicht abschliessend):" }, { "typ": "liste ungeordnet", "inhalt": "Umgebungsvariablen (Secrets, Env) überprüfen \r\nPasswörter und andere Credentials dürfen nicht im Klartext enthalten sein" }, { "typ": "text", "inhalt": "Die Reviews sollten laufend im Rahmen der Pull Requests erfolgen, wenn Features oder Bug Fixes entwickelt werden.\r\nEine 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)." } ] }, "Referenz": [ "Security-by-Design-Prinzip", "Standards BIT" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Ein Vier-Augen-Prinzip für PRs ist in Kraft.", "Es sind keine Secrets im Code gespeichert." ], "Stichworte": [] }, { "Nummer": "2", "Titel": "Security Code Review", "Thema": "Anwendungen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Sensitive Funktionen müssen im vier-Augen-Prinzip auf Sicherheit geprüft werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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." } ] }, "Referenz": [ "Security-by-Design-Prinzip" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Security Code Reviews erfolgen durch unabhängige Reviewer und sind dokumentiert." ], "Stichworte": [] }, { "Nummer": "3", "Titel": "Security Requirements und Threat Modeling", "Thema": "Anwendungen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Security Requirements und Threat Modeling müssen für Anwendungen definiert und durchgeführt werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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.\r\n\r\nMindestens erforderlich:" }, { "typ": "liste ungeordnet", "inhalt": "Security-Anforderungen pro Feature, Release oder Komponente definieren\r\nThreat Modeling vor Major Releases oder Architekturänderungen durchführen\r\nRisiken und Gegenmassnahmen dokumentieren" } ] }, "Referenz": [ "T4 (Schwachstellen und Verwundbarkeiten)" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Die Security-Anforderungen sind definiert.", "Risiken und deren Behandlung sind dokumentiert." ], "Stichworte": [] }, { "Nummer": "4", "Titel": "Supply Chain Security", "Thema": "Anwendungen", "Kurztext": { "Abschnitt": [ { "typ": "Abschnittstyp", "inhalt": "Die Integrität von Source Code und Build-Artefakten muss sichergestellt werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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.\r\n\r\nDies kann mit folgenden Punkten umgesetzt werden:" }, { "typ": "liste ungeordnet", "inhalt": "Commits sollten digital signiert werden\r\nDependencies müssen auf fixe Versionen gepinnt werden (kein \":latest\")" } ] }, "Referenz": [ "O2.1" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Commits sind digital signiert.", "Es sind keine Abhängigkeiten mit \":latest\" getaggt.", "Alle Abhängigkeiten sind mit fixen Versionen getaggt." ], "Stichworte": [] }, { "Nummer": "1", "Titel": "Kontrolle der Sicherheitsdokumente", "Thema": "Informationen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Die Sicherheitsdokumente aller DevSecOps-Vorhaben müssen vollständig sein und regelmässig geprüft werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "Die Sicherheitsdokumente aller DevSecOps-Vorhaben müssen vollständig sein. Bei grösseren sicherheitsrelevanten Anpassungen am Schutzobjekt, oder spätestens nach fünf\r\nJahren, 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\"." } ] }, "Referenz": [ "Art. 6: Art. 6 Informationssicherheit", "Art. 27: Art. 27 Sicherheitsverfahren" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Die Sicherheitsdokumente sind vorhanden und aktuell." ], "Stichworte": [] }, { "Nummer": "2", "Titel": "Design- und Architektur-Review", "Thema": "Informationen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Design und Architektur müssen in regelmässigen Abständen geprüft und angepasst werden" } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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.\r\n\r\nNachfolgende Elemente sind zu überprüfen:" }, { "typ": "liste ungeordnet", "inhalt": "Architekturskizze\r\nSolution Design\r\nKonzeptionelle Fehler und Verwundbarkeiten\r\nDie Ergebnisse der Datenflussanalyse\r\nSchnittstellen zu anderen Komponenten\r\nZugangspunkte\r\nAbhängigkeiten\r\nRollen und Berechtigungskonzept" } ] }, "Referenz": [ "Security-by-Design-Prinzip" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Die Architektur-Dokumentation ist aktuell.", "Architektur-Reviews werden periodisch durchgeführt." ], "Stichworte": [] }, { "Nummer": "3", "Titel": "Secret Management", "Thema": "Informationen", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Secrets müssen in einem dafür geeigneten System verwaltet werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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" }, { "typ": "liste ungeordnet", "inhalt": "Passwörter\r\nPrivate Schlüssel\r\nAPI Tokens für andere Dienste" } ] }, "Referenz": [ "Need-to-Know-Prinzip", "Stand der Technik" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Zugriff auf Secrets ist rollenbasiert eingeschränkt.", "Zentrales Secret-Management-System ist im Einsatz", "Secrets sind nicht in Code oder Config abgelegt." ], "Stichworte": [] }, { "Nummer": "1", "Titel": "Anwendung SAST und DAST", "Thema": "Systeme", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Applikationen müssen regelmässig durch statische und dynamische Codeanalyse auf Schwachstellen untersucht werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "Applikationen und Infrastruktur müssen mittels SAST im Minimum auf die aktuellen OWASP Top 10 und allgemeine Good- und Best-Practices getestet werden.\r\nSchwerwiegende oder kritische Befunde sind zwingend vor einem Deployment zu beheben. Falls dies nicht möglich ist, ist eine entsprechende Ausnahmenbewilligung vom ISBO einzuholen.\r\n\r\nAlle identifizierten Schwachstellen müssen zentral verwaltet werden. Deren Behebung muss geplant werden, wenn keine entsprechende Ausnahmebewilligung vorliegt." } ] }, "Referenz": [ "T4 (Schwachstellen und Verwundbarkeiten)" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Schwachstellen werden zentral verwaltet." ], "Stichworte": [] }, { "Nummer": "2", "Titel": "Secret Scanning", "Thema": "Systeme", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Container-Images und Repositories müssen auf offengelegte Geheimnisse überprüft werden" } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "Alle Container-Images, Dateisysteme und Git-Repositories müssen auf offengelegte Geheimnisse wie Passwörter, API-Schlüssel, Token etc. gescannt werden.\r\n\r\nDas 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." } ] }, "Referenz": [ "T2: Konfiguration und Einstellung" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Container Image Secret Scanning ist aktiv.", "Repository Secret Scanning ist aktiv.", "Secret-Leaks werden dokumentiert." ], "Stichworte": [] }, { "Nummer": "3", "Titel": "Security Unit Tests durchführen", "Thema": "Systeme", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Security-Unit-Tests müssen im Rahmen der Entwicklung durch die Entwickler (bzw. die Lieferanten) erstellt und gepflegt werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "Security-Unit-Tests müssen im Rahmen der Entwicklung durch die Entwickler (bzw. die Lieferanten) erstellt und gepflegt werden. \r\n\r\nLogische Fehler in der Webanwendung können damit identifiziert und korrigiert werden.\r\n\r\nIdealerweise 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." } ] }, "Referenz": [ "T4 (Schwachstellen und Verwundbarkeiten)" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Security Unit Tests sind implementiert." ], "Stichworte": [] }, { "Nummer": "4", "Titel": "Container Image Scanning", "Thema": "Systeme", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Vor der ersten produktiven Verwendung muss ein Container Image auf Schwachstellen gescannt werden, anschliessend periodisch." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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.\r\n\r\nDer aktuelle Sicherheitsstand jedes Container Images muss zentral einsehbar sein." } ] }, "Referenz": [ "T4 (Schwachstellen und Verwundbarkeiten)" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Container Image Scanning ist automatisiert.", "Scan erfolgt vor Erstdeployment und periodisch.", "Images mit CVSS ≥ 7 werden nicht deployed oder sind genehmigt." ], "Stichworte": [] }, { "Nummer": "5", "Titel": "Automatisierte Deployments", "Thema": "Systeme", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "Es darf ausschliesslich mit automatisierten Prozessen auf produktive Systeme deployed werden." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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." } ] }, "Referenz": [ "Stand der Technik" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Deployments erfolgen ausschliesslich über Pipeline", "Manuelle Produktionsdeployments sind dokumentiert und genehmigt" ], "Stichworte": [] }, { "Nummer": "1", "Titel": "Software Composition Analysis (SCA)", "Thema": "Technik", "Kurztext": { "Abschnitt": [ { "typ": "text", "inhalt": "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." } ] }, "Langtext": { "Abschnitt": [ { "typ": "text", "inhalt": "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." }, { "typ": "liste ungeordnet", "inhalt": "Bibliotheken und vergleichbare Abhängigkeiten müssen mittels Vulnerablity Scanning auf Sicherheitslücken getestet werden.\r\nSchwerwiegende oder gar kritische Befunde sind zwingend vor einem Deployment zu beheben oder eine Ausnahmebewilligung einzuholen.\r\nAlle identifizierten Schwachstellen müssen zentral verwaltet werden und entweder deren Behebung geplant oder eine Ausnahmebewilligung eingeholt werden.\r\nDeployments 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." } ] }, "Referenz": [ "T4 (Schwachstellen und Verwundbarkeiten)" ], "Gueltigkeit": { "Von": "2026-02-11", "Bis": null }, "Checklistenfragen": [ "Dependencies werden mindestens wöchentlich gescannt." ], "Stichworte": [] } ] }