Der externe Dienstleister hat die Anwendung entwickelt, die Abnahmetests bestanden — und sechs Monate später wird eine kritische Schwachstelle entdeckt. Der Dienstleister berechnet die Behebung als Change Request, der Quellcode liegt auf seinen Servern, und eine Code-Escrow-Vereinbarung gibt es nicht. A.8.30 verlangt, dass Sicherheitsanforderungen bei ausgelagerter Entwicklung vertraglich vereinbart, überwacht und in der Abnahme geprüft werden.
Die Kontrolle verbindet Lieferantenmanagement mit sicherer Softwareentwicklung: Deine Sicherheitsstandards gelten auch für externen Code.
Was verlangt die Norm?
- Sicherheitsanforderungen kommunizieren. Der externen Entwicklungspartei die Sicherheitsstandards klar mitteilen und vertraglich vereinbaren.
- Regelmäßig überprüfen. Die Arbeit des Dienstleisters periodisch auf Einhaltung der Sicherheitsstandards prüfen.
- Lizenz- und IP-Vereinbarungen. Klare Regelungen zu Urheberrecht, Quellcode-Eigentum und Nutzungsrechten.
- Audit-Rechte sichern. Das Recht, den Entwicklungsprozess und den Code prüfen zu können.
- Code-Escrow vereinbaren. Für den Fall der Insolvenz des Dienstleisters den Quellcode bei einem Treuhänder hinterlegen.
In der Praxis
Sicherheitsanforderungen in die Ausschreibung. Bereits in der Angebotsanfrage (RFP) die Sicherheitsanforderungen definieren. Anbieter, die diese Anforderungen nicht erfüllen können, scheiden frühzeitig aus.
Regelmäßige Code-Audits. Mindestens vor jeder größeren Lieferung: eigener SAST-Scan, Code Review und bei kritischen Anwendungen ein Penetrationstest. Der Dienstleister liefert den Code, du prüfst die Sicherheit.
Entwicklungsprozess des Dienstleisters bewerten. Verfügt der Dienstleister über einen sicheren Entwicklungsprozess? ISO 27001-Zertifizierung, definierte SDLC-Praktiken, geschulte Entwickler? Die Bewertung erfolgt vor Vertragsabschluss und wird periodisch wiederholt.
Abnahme mit Sicherheitskomponente. Die Abnahme des gelieferten Codes umfasst explizit die Prüfung der Sicherheitsanforderungen. Keine Abnahme ohne bestandene Sicherheitstests.
Typische Audit-Nachweise
- Verträge mit Security Annex — Sicherheitsanforderungen in allen Entwicklungsverträgen (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- Dienstleister-Bewertungen — Sicherheitsbewertung vor und während der Zusammenarbeit
- Code-Audit-Ergebnisse — Berichte der eigenen Sicherheitsprüfungen des gelieferten Codes
- Abnahmeprotokolle — Freigabe mit dokumentierter Sicherheitsprüfung
- Code-Escrow-Vereinbarung — Nachweis der Quellcode-Hinterlegung
KPI
Anteil der Outsourcing-Entwicklungsverträge mit durchgesetzten Sicherheitsanforderungen
Gemessen als Prozentsatz: Wie viele deiner aktiven Entwicklungsverträge mit externen Partnern enthalten verbindliche Sicherheitsanforderungen und werden regelmäßig überprüft? Ziel: 100%.
Ergänzende KPIs:
- Anteil der Lieferungen mit durchgeführtem Code-Audit vor Abnahme
- Anzahl der Sicherheits-Findings in ausgelagertem Code pro Quartal
BSI IT-Grundschutz
- OPS.2.3 (Nutzung von Outsourcing) — übergreifende Anforderungen an die Steuerung ausgelagerter IT-Dienstleistungen, einschließlich Sicherheitsanforderungen.
- OPS.3.2 (Anbieten von IT-Leistungen) — Anforderungen aus Anbietersicht, die bei der Bewertung des Dienstleisters relevant sind.
Verwandte Kontrollen
- A.8.25 — Sicherer Entwicklungslebenszyklus: Die Sicherheitsstandards, die auch für externe Entwicklung gelten.
- A.5.19 — Informationssicherheit in Lieferantenbeziehungen: Übergeordnete Kontrolle für alle Lieferantenbeziehungen.
- A.8.29 — Sicherheitstests: Tests als Abnahmekriterium für ausgelagerten Code.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.30 — Ausgelagerte Entwicklung
- ISO/IEC 27002:2022 Abschnitt 8.30 — Umsetzungshinweise
- BSI IT-Grundschutz, OPS.2.3 — Nutzung von Outsourcing