Schweizer Unternehmen müssen jetzt einen Secure SDLC (Secure Software Development Lifecycle) etablieren, der den NCSC-IKT-Minimalstandard mit den Anforderungen aus DSG und ISG verbindet. Sicherheit ist kein Projektabschluss-Thema, sondern gehört in jede Phase: von den Anforderungen bis zum Betrieb. Wer das jetzt nicht verankert, riskiert Bussgelder, Meldepflichten gegenüber dem EDÖB und unkontrollierbare Sicherheitslücken.
Erste Schritte, die Sie sofort angehen können:
- Schutzbedarfsanalyse (Schuban) durchführen: Vor jedem Informatikvorhaben Pflicht; das Ergebnis entscheidet, ob ein ISDS-Konzept nötig ist.
- Versionsverwaltung und Backups sicherstellen: Repositories mit Zugriffskontrollen schützen, Backups ins Datensicherungskonzept einbinden.
- Bedrohungsmodellierung einplanen: Schon in der Designphase Angriffsvektoren identifizieren und dokumentieren.
- Secrets-Management einführen: Keine Zugangsdaten im Code; Tools wie HashiCorp Vault oder Cloud-KMS-Dienste verwenden.
- Meldepflicht kennen: Bei Verletzungen der Datensicherheit mit hohem Risiko besteht nach Art. 24 DSG Meldepflicht gegenüber dem EDÖB.
Outwork begleitet Schweizer Unternehmen durch genau diesen Prozess, von der ersten Schuban bis zum laufenden Betrieb.
Inhaltsverzeichnis
- Was ist ein Secure SDLC und wie passt er zur Schweizer Rechtslage?
- Welche Sicherheitskontrollen gehören in jede SDLC-Phase?
- Wer trägt die Verantwortung für Governance, ISMS und Nachweisführung?
- Wie wählen Sie den richtigen Schweizer Entwicklungspartner aus?
- Wichtige Erkenntnisse
- Warum Outwork Secure SDLC in der Schweiz anders angeht
- Outwork unterstützt Sie beim Aufbau eines sicheren Entwicklungsprozesses
- Wichtige Schweizer Quellen und Behördentexte
Was ist ein Secure SDLC und wie passt er zur Schweizer Rechtslage?
Ein Secure SDLC integriert Sicherheitsanforderungen in jeden Schritt der Softwareentwicklung: Requirements, Design, Implementierung, Test, Deployment und Betrieb. Das Gegenteil davon ist Security als Nachgedanke, und das ist teuer. Werden Sicherheitsfunktionen erst spät eingebaut, steigen Aufwand und Fehlerrisiko erheblich.
Die Prinzipien dahinter sind Privacy by Design und Security by Default: Datenschutz und Sicherheit sind von Anfang an in die Architektur eingebaut, nicht nachträglich aufgesetzt. Dazu kommen Least Privilege (jeder Prozess erhält nur die minimal nötigen Rechte) und Defense in Depth (mehrere unabhängige Schutzschichten).
Rechtliche Pflicht in der Schweiz: Vor jedem Informatikvorhaben ist eine Schutzbedarfsanalyse (Schuban) durchzuführen. Ergibt die Schuban erhöhten Schutzbedarf, ist ein ISDS-Konzept mit Risikoanalyse, Notfallkonzept und Prüfprozessen Pflicht. Das revidierte DSG, in Kraft seit 1. September 2023, verlangt angemessene technische und organisatorische Massnahmen (Art. 8) und Meldung von Datenpannen mit hohem Risiko an den EDÖB (Art. 24). Das Bundesamt für Justiz betont die Harmonisierung mit EU-Standards als zentrales Ziel der Revision.
Der NCSC-IKT-Minimalstandard strukturiert Sicherheitsmassnahmen in fünf Schutzziele: Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen. Diese fünf Bereiche bilden das Rückgrat eines systematischen Informationssicherheits-Managementsystems (ISMS) und lassen sich direkt auf SDLC-Phasen abbilden. ISG und ISV setzen den rechtlichen Rahmen für Bundesstellen und kritische Infrastrukturen; für privatwirtschaftliche Unternehmen sind DSG und branchenspezifische Anforderungen massgebend.
Welche Sicherheitskontrollen gehören in jede SDLC-Phase?
Die fünf NCSC-Schutzziele sind kein abstraktes Rahmenwerk. Sie lassen sich direkt in operative Kontrollen übersetzen.
Identifizieren
- Schutzbedarfsanalyse (Schuban) für jedes Vorhaben, dokumentiert und versioniert.
- Asset- und Abhängigkeitsinventar: alle Bibliotheken, APIs und Drittsysteme erfassen.
- Bedrohungsmodellierung (Threat Modelling) in der Designphase, mit dokumentierten Angriffsvektoren und Restrisiken.
Schützen
- Secrets-Management: Zugangsdaten, API-Keys und Zertifikate niemals im Quellcode; stattdessen HashiCorp Vault, AWS KMS oder Azure Key Vault einsetzen.
- Sichere Authentifizierung: Multi-Faktor-Authentifizierung (MFA) für alle privilegierten Zugänge, OAuth 2.0 / OpenID Connect für Anwendungen.
- Software Composition Analysis (SCA) in der CI-Pipeline, um bekannte Schwachstellen in Abhängigkeiten frühzeitig zu erkennen.
- Build-Pipeline-Härtung: Least-Privilege-Prinzip für CI/CD-Dienste, keine hartcodierten Credentials in Pipeline-Konfigurationen.
Profi-Tipp: Die Integrität der Entwicklungsumgebung ist ein oft unterschätzter Angriffsvektor. Prüfsummen von Build-Artefakten kryptographisch verifizieren und die Prüftools selbst schützen, sonst kann ein kompromittiertes Tool unbemerkt Schadcode einschleusen.
Erkennen
- Zentralisierte Log-Aggregation (z. B. mit dem ELK-Stack oder Grafana Loki) mit Alert-Regeln für verdächtige Aktivitäten.
- Integritätsprüfungen der Build-Artefakte nach jedem Release-Build.
- SCA-Alerts für neu gemeldete CVEs in genutzten Bibliotheken, automatisiert über Tools wie Dependabot oder Snyk.
Reagieren
- Incident-Response-Playbooks, die Eskalationswege, Kommunikationspflichten und technische Sofortmassnahmen beschreiben.
- Meldeprozess an den EDÖB nach Art. 24 DSG: Bei Datenpannen mit hohem Risiko muss die Meldung so rasch wie möglich erfolgen.
- Regelmässige Tabletop-Übungen, um Reaktionszeiten und Zuständigkeiten zu testen.
Wiederherstellen
- Backup-Strategie mit definierten Recovery-Time-Objectives (RTO) und Recovery-Point-Objectives (RPO).
- Regelmässige Recovery-Tests, nicht nur Backups erstellen, sondern auch die Wiederherstellung üben.
- Release-Rollback-Prozesse dokumentieren und in der CI/CD-Pipeline automatisieren.
Wer trägt die Verantwortung für Governance, ISMS und Nachweisführung?
Klare Verantwortlichkeiten sind kein bürokratischer Luxus. Sie sind die Voraussetzung dafür, dass Audits bestanden und Compliance-Nachweise geliefert werden können.
- ISDS-Konzept: — Das zentrale Dokument bei erhöhtem Schutzbedarf. Es enthält Systembeschreibung, Risikoanalyse, Notfallkonzept und Prüfprozesse. Es ist bei wesentlichen Änderungen zu aktualisieren und alle fünf Jahre vollständig neu zu bearbeiten.
Projekte, die Meldekanäle oder Hinweisgeberfunktionen einbauen müssen, können auf spezialisierte Compliance-Lösungen wie Ashio zurückgreifen, um anonyme Meldewege datenschutzkonform umzusetzen.
Wie wählen Sie den richtigen Schweizer Entwicklungspartner aus?
Die Wahl des Entwicklungspartners ist eine Sicherheitsentscheidung, keine reine Einkaufsentscheidung. Ein Partner ohne nachweisbare Secure-SDLC-Praxis überträgt sein Risiko direkt auf Ihr Unternehmen.
- Schweizer Compliance-Erfahrung bestätigen: — Kennt der Partner DSG, ISG/ISV und NCSC-Vorgaben aus eigener Projekterfahrung? Kann er ISDS-Vorlagen liefern?
- Langfristige Begleitung sicherstellen: Sichere Softwareentwicklung endet nicht mit dem Go-live. Betrieb, Monitoring und kontinuierliche Verbesserung gehören dazu.
Wichtige Erkenntnisse
Ein Secure SDLC, der auf dem NCSC-IKT-Minimalstandard aufbaut und DSG sowie ISG einbindet, ist für Schweizer Unternehmen die einzige Grundlage für nachweisbare IT-Sicherheit in der Softwareentwicklung.
| Thema | Details |
|---|---|
| Schuban als Pflichtschritt | Vor jedem Informatikvorhaben durchführen; Ergebnis entscheidet über ISDS-Pflicht. |
| Versionsverwaltung und Backups | Müssen laut BSI CON.8 ins Datensicherungskonzept eingebunden sein. |
| Meldepflicht nach DSG Art. 24 | Datenpannen mit hohem Risiko sind so rasch wie möglich dem EDÖB zu melden. |
| Governance und ISBO | Informationssicherheitsverantwortlicher muss benannt und ISDS-Konzept vor Go-live unterzeichnet sein. |
| Outwork als Partner | Begleitet Schweizer Unternehmen von der Schuban bis zum laufenden Betrieb mit nachweisbaren Secure-SDLC-Prozessen. |
Warum Outwork Secure SDLC in der Schweiz anders angeht
Die meisten Diskussionen über Datensicherheit in der Softwareentwicklung enden bei Checklisten. Was fehlt, ist die Verbindung zwischen technischer Umsetzung und dem, was Schweizer Entscheider tatsächlich nachweisen müssen: ein ISDS-Konzept mit Unterschriften, eine dokumentierte Schuban, Test-Evidence vor dem Go-live.
Outwork arbeitet mit über 1.200 aktiven Kunden und begleitet Projekte über den gesamten Lebenszyklus, von der strategischen Beratung bis zum laufenden Betrieb. Der Unterschied liegt nicht im Werkzeugkasten, sondern im Ansatz: Sicherheitsanforderungen werden in der Requirements-Phase verankert, nicht als letzter Schritt vor dem Launch eingebaut. DevSecOps-Praxis, CI/CD-Härtung und DSG/ISG-konforme Dokumentation sind dabei kein Add-on, sondern Teil des Standardprozesses.
Was Entscheider unterschätzen: Die organisatorische Genehmigung und die schriftliche Bestätigung durch ISBO und Projektleitung sind bei erhöhtem Schutzbedarf genauso regulatorisch verpflichtend wie die technische Umsetzung. Wer das nicht von Anfang an plant, steht kurz vor dem Go-live vor einem Compliance-Problem, nicht einem technischen.
Outwork unterstützt Sie beim Aufbau eines sicheren Entwicklungsprozesses
Schweizer Unternehmen, die sichere Software entwickeln und gleichzeitig DSG- und ISG-Anforderungen erfüllen müssen, brauchen einen Partner, der beides versteht: die technische Umsetzung und den regulatorischen Rahmen.
Outwork liefert maßgeschneiderte Softwareentwicklung mit eingebettetem Secure SDLC: von der Schuban und ISDS-Vorlage über DevSecOps-Implementierung und CI/CD-Härtung bis zum Audit-Support. Typische Engagements beginnen mit einem Sicherheits-Assessment, das den aktuellen Stand bewertet und eine priorisierte Roadmap liefert. Danach folgen Umsetzung und laufender Betrieb, inklusive Patch-Management und Monitoring. Alle Leistungen sind auf Schweizer Compliance-Anforderungen ausgerichtet. Nehmen Sie jetzt Kontakt auf und klären Sie in einem ersten Gespräch, wo Ihr grösster Handlungsbedarf liegt.
Wichtige Schweizer Quellen und Behördentexte
- NCSC IKT-Minimalstandard (Si001): Primäre Referenz für die fünf Schutzziele und Minimalanforderungen an Security-by-Design, Least Privilege und Integritätsprüfung.
- NCSC Sicherheitsverfahren (Schuban / ISDS): Beschreibt die Pflicht zur Schutzbedarfsanalyse vor jedem Informatikvorhaben und die Kriterien für ein ISDS-Konzept.
- P042 ISDS-Konzept-Vorlage: Definiert Pflichtinhalte (Systembeschreibung, Risikoanalyse, Notfallkonzept, Prüfungen) und Signaturanforderungen vor Betriebsaufnahme.
- BSI CON.8 Softwareentwicklung: Vorgaben zu Versionsverwaltung, Datensicherungskonzept und sicherem Softwareentwurf; auch für Schweizer Projekte als Praxisreferenz geeignet.
- Revidiertes DSG (Fedlex): Volltext des Datenschutzgesetzes mit Art. 8 (Datensicherheit) und Art. 24 (Meldepflicht bei Datenpannen).
- Bundesamt für Justiz: Neues Datenschutzrecht: Erläuterungen zur DSG-Revision, Inkraftsetzung per 1. September 2023 und Harmonisierung mit EU-Standards.
