BSI TR-03185 - Technische Richtlinie TR-03185: Sicherer Software-Lebenszyklus
BSI-Richtlinie zu sicheren Prozessen in der Software-Entwicklung
Lesezeit: 5 Min.
Was bedeutet BSI TR-03185?
Die BSI TR-03185 ist eine Technische Richtlinie des BSI, die sichere Entwicklungsprozesse für Software beschreibt: Teil 1 für proprietäre Software, Teil 2 für Open-Source-Software.
Die BSI TR-03185 „Sicherer Software-Lebenszyklus" ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik, die Anforderungen an sichere Entwicklungsprozesse formuliert.
Sie besteht aus zwei Teilen: Teil 1 (Version 1.0, 06.08.2024) richtet sich an die Entwicklung proprietärer Software und unterscheidet die Perspektiven Software-Anwender (Einsatz von Entwicklungswerkzeugen) und Software-Produzent (Erstellung der Software selbst). Teil 2 (Version 1.1.0, 18.08.2025, „Secure Software Lifecycle for Open Source Software") überträgt den Ansatz auf Open-Source-Projekte, da sich Rollen und Entwicklungsprozesse dort grundlegend unterscheiden. Anders als die produktbezogene TR-03183 adressiert die TR-03185 den Entwicklungsprozess selbst: Projektmanagement, Bedrohungsmodellierung, Entwurf, Code Management, Test und Freigabe, Schwachstellenmanagement und Außerbetriebnahme.
Die zwei Teile der TR-03185 im Überblick
Teil 1 (Version 1.0, 06.08.2024) gliedert die Anforderungen nach zwei Perspektiven des Herstellers: als Software-Anwender (Kapitel 3.1, Kürzel USER.*) betrachtet er den Einsatz von Werkzeugen zur Software-Entwicklung, etwa Projektmanagement, Beschaffung, Installation und Patch-Management dieser Werkzeuge. Als Software-Produzent (Kapitel 3.2, Kürzel PROD.*) betrachtet er die Erstellung der eigenen Software: Projektmanagement, Dokumentation, Entwicklung inklusive Bedrohungsmodellierung und Entwurf, Test und Freigabe, Auslieferung, Schwachstellenmanagement und Außerbetriebnahme. Die Anforderungen nutzen die Modalverben MUSS/SOLLTE/KANN nach RFC 2119 und DIN 820-2:2020 und stützen sich auf BSI IT-Grundschutz-Kompendium 2023, NESAS FS.16 Version 2.3, DIN EN IEC 62443-4-1:2018-10 und NIST SP 800-218. Teil 1 gilt ausdrücklich nicht für Open-Source-Software. Teil 2 (Version 1.1.0, 18.08.2025, nur englischsprachig) listet stattdessen 15 schlankere Anforderungen in sechs Kategorien: Governance (GV), Legal (LE), Quality (QA), Build and Release (BR), Vulnerability Management (VM) und Decommissioning (DE), bewusst minimal gehalten, um Maintainer nicht zusätzlich zu belasten.
Verhältnis zum Cyber Resilience Act
Die TR-03185 überschneidet sich mit mehreren CRA-Pflichten aus Anhang I, ohne eine direkte Umsetzungsanleitung wie die TR-03183 zu sein. Die sicheren Entwurfsprinzipien und die verpflichtende Bedrohungsmodellierung in der Entwurfsphase (PROD.DEV.C.1) entsprechen der Security-by-Design-Pflicht aus Anhang I Teil I Nr. 1. Die Anforderungen an Schwachstellenmanagement (PROD.FIX.A.1 bis A.11) decken einen Teil der Prozesspflichten aus Anhang I Teil II Nr. 2 bis 8 ab, etwa Meldestelle, Untersuchungsverfahren und dokumentierte Update-Zeitfenster. Die Sorgfaltspflicht bei Drittkomponenten (Art. 13) findet sich in den Anforderungen zu vertrauenswürdigen Quellen und Integritätsprüfung (PROD.DEV.G.1 bis G.7) wieder. Teil 2 macht diesen Bezug explizit: Seine Anforderungstabellen führen eine Spalte „Induced by", die auf konkrete CRA-Fundstellen verweist, etwa VM.01 auf Anhang I Teil I Nr. 2 c sowie Anhang I Teil II Nr. 5 bis 7. Teil 1 nennt den CRA nur einleitend als Motivation, ohne einzelne Anforderungen CRA-Artikeln zuzuordnen. Nicht abgedeckt sind die formalen CRA-Pflichten: CE-Kennzeichnung, Konformitätsbewertungsverfahren, benannte Stellen sowie die 24- und 72-Stunden-Meldefristen an ENISA und CSIRT.
TR-03185 und TR-03183: zwei verschiedene Richtlinien
Beide Richtlinien ergänzen sich, ersetzen sich aber nicht. Die TR-03183 beschreibt, was ein fertiges Produkt an Artefakten mitbringen muss: SBOM in einem definierten Format, CSAF-Sicherheitsmitteilungen, eine security.txt, wahlweise den Konformitätsweg über ein ISMS nach Modul H. Die TR-03185 beschreibt dagegen, wie der Entwicklungsprozess organisiert sein muss, damit ein solches Produkt überhaupt entsteht: sichere Entwurfsprinzipien, Bedrohungsmodellierung, Code-Versionierung, Build-Reproduzierbarkeit, entwicklungsbegleitende Tests. Die TR-03185 verweist an mehreren Stellen selbst auf benachbarte Richtlinien: Bei der Inventarisierung von Komponenten (PROD.DEV.L.2) auf die BSI TR-03183 für das SBOM-Format, beim Schwachstellenmanagement auf die BSI TR-03191 für das CSAF-Format von Sicherheitsmitteilungen.
Was Hersteller konkret umsetzen müssen
Bedrohungsmodellierung in der Entwurfsphase durchführen und regelmäßig aktualisieren (PROD.DEV.C.1 bis C.4). Verbindliche Codiernormen dokumentieren und einhalten, insbesondere zu Eingabevalidierung und Fehlerbehandlung (PROD.DEV.A.4). Quellcode über eine Versionsverwaltung mit geregeltem Zugriff verwalten, eingebunden in ein Datensicherungskonzept (PROD.DEV.H.1). Reproduzierbare Builds mit einem automatisierten Build-Tool erzeugen, dessen Eingabedaten ausschließlich aus dem Versionskontrollsystem stammen (PROD.DEV.I.3 und I.4). Entwicklungs-, Build- und Testumgebung voneinander getrennt betreiben (USER.PM.C.9) und private Schlüssel für die Codesignatur besonders schützen (USER.PM.C.6). Eine Meldestelle für sicherheitsbezogene Probleme einrichten und Meldungen in einem festgelegten Verfahren verfolgen (PROD.FIX.A.3). Zeitfenster für die Bereitstellung von Sicherheitsupdates dokumentieren und einhalten (PROD.FIX.A.1).
Warum Open Source einen eigenen Teil bekommt
Teil 1 setzt Rollen voraus, die in Open-Source-Projekten oft fehlen: einen Auftraggeber, eine Freigabeinstanz, klar getrennte Zuständigkeiten für fachliche Betreuung und Test. Viele OSS-Projekte werden dagegen von wenigen Freiwilligen mit begrenzter Zeit getragen. Teil 2 übernimmt deshalb CRA-Rollenbegriffe wie Manufacturer, Steward, Maintainer, Contributor, Upstream und Downstream und benennt ausdrücklich keine für die Umsetzung verantwortliche Partei. Stattdessen nennt er drei Umsetzungswege in Präferenzreihenfolge: Hersteller oder Steward wirken direkt in der Upstream-Entwicklung mit, Maintainer setzen die Anforderungen selbst um, oder Hersteller pflegen einen abgesicherten Downstream-Fork. Als Motivation nennt die Richtlinie ausdrücklich Vorfälle wie die Backdoor in xz-utils und die Heartbleed-Schwachstelle in OpenSSL, die zeigten, wie knapp Ressourcen in vielen OSS-Projekten sind. Zertifizierungen nach Teil 2 bietet das BSI nach eigener Angabe derzeit nicht an.
Praxis-Tool
Prüfe, welche Prozessanforderungen aus Anhang I Teil II für dein Produkt gelten
Zum CRA-Klartext →Auch bekannt als
TR-03185 · TR 03185 · TR03185 · BSI TR 03185 · Technische Richtlinie 03185 · Sicherer Software-Lebenszyklus · Secure Software Lifecycle · TR-03185-2 · Secure Software Lifecycle for Open Source Software · Secure OSS Lifecycle · SDLC
Teil des Themenbereichs: Compliance & Regulierung
- TARA - Threat Analysis and Risk Assessment
- NIS-2 - Network and Information Security Directive 2
- IT-Notfallmanagement - IT Incident Response
- CRA - Cyber Resilience Act
- IEC 62443 - Industrial Automation and Control Systems Security
- Risikoregister - Risk Register
- SoA - Statement of Applicability
- Risikomatrix - Risk Matrix
- Annex A - Annex A (ISO/IEC 27001:2022)
- BSI TR-03183 - Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products
- EN 40000 - Horizontale Normenreihe EN 40000-1-x zum Cyber Resilience Act
- Harmonisierte Norm - Harmonisierte europäische Norm mit Konformitätsvermutung
- CE-Kennzeichnung - CE-Kennzeichnung nach dem Cyber Resilience Act
- Konformitätsbewertung - Konformitätsbewertungsverfahren nach Art. 32 des Cyber Resilience Act
- Benannte Stelle - Notifizierte Konformitätsbewertungsstelle
- ISO 42001 - ISO/IEC 42001:2023 - AI Management System
- Fördermittel IT-Sicherheit - öffentliche Zuschüsse, Kredite und Beratungsförderung für IT-Sicherheitsmaßnahmen
Verwandte Begriffe
- BSI TR-03183 - Technische Richtlinie TR-03183: Cyber Resilience Requirements for Manufacturers and Products
- CRA - Cyber Resilience Act
- SBOM - Software Bill of Materials
- CSAF - Common Security Advisory Framework
- CVD - Coordinated Vulnerability Disclosure
- security.txt - security.txt nach RFC 9116
- PSIRT - Product Security Incident Response Team
- IEC 62443 - Industrial Automation and Control Systems Security
- VEX - Vulnerability Exploitability eXchange
- CVE - Common Vulnerabilities and Exposures
- CWE - Common Weakness Enumeration
- Annex A - Annex A (ISO/IEC 27001:2022)
- EN 40000 - Horizontale Normenreihe EN 40000-1-x zum Cyber Resilience Act
- Konformitätsbewertung - Konformitätsbewertungsverfahren nach Art. 32 des Cyber Resilience Act
Quellen
- BSI: Technische Richtlinie TR-03185
- BSI TR-03185 Teil 1 (PDF, Version 1.0)
- BSI TR-03185-2, Secure Software Lifecycle for Open Source Software (PDF, Version 1.1.0)
- Verordnung (EU) 2024/2847 (Cyber Resilience Act)
Zuletzt aktualisiert: 2026-08-18
Häufige Fragen zu BSI TR-03185
Was ist die BSI TR-03185?
Die BSI TR-03185 „Sicherer Software-Lebenszyklus" ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik, die Anforderungen an sichere Software-Entwicklungsprozesse beschreibt. Sie besteht aus zwei Teilen: Teil 1 für proprietäre Software, Teil 2 für Open-Source-Software.
Aus welchen Teilen besteht die TR-03185?
Aus zwei Teilen. Teil 1 (Version 1.0, 06.08.2024) behandelt die Entwicklung proprietärer Software aus den Perspektiven Software-Anwender und Software-Produzent. Teil 2 (Version 1.1.0, 18.08.2025, englischsprachig) überträgt den Ansatz auf Open-Source-Software mit 15 schlankeren Anforderungen in sechs Kategorien.
Ist die BSI TR-03185 verpflichtend?
Formal ist sie eine Technische Richtlinie und kein Gesetz. Für Hersteller, die Prozesspflichten aus dem Cyber Resilience Act nachweisen müssen, ist sie praktisch dennoch relevant, da sie eine konkrete Auslegung sicherer Entwicklungsprozesse liefert und zunehmend in Ausschreibungen und Lieferverträgen referenziert wird.
Welche Überschneidungen gibt es zur BSI TR-03185 zum Cyber Resilience Act?
Die TR-03185 deckt einen Teil der CRA-Prozesspflichten ab: Security by Design und Bedrohungsmodellierung (Anhang I Teil I Nr. 1), Schwachstellenmanagement und Meldeverfahren (Anhang I Teil II Nr. 2 bis 8) sowie Sorgfaltspflichten bei Drittkomponenten (Art. 13). Nicht abgedeckt sind CE-Kennzeichnung, Konformitätsbewertung, benannte Stellen und die 24-/72-Stunden-Meldefristen an ENISA und CSIRT.
Was ist der Unterschied zwischen TR-03185 und TR-03183?
Die TR-03183 regelt, welche Artefakte ein fertiges Produkt mitbringen muss, etwa SBOM, CSAF-Mitteilungen und security.txt. Die TR-03185 regelt den Entwicklungsprozess dahinter, etwa Bedrohungsmodellierung, Code Management und Testverfahren. Beide Richtlinien ergänzen sich und verweisen aufeinander, ersetzen sich aber nicht.
Was regelt TR-03185-2?
Teil 2 überträgt die Anforderungen der TR-03185 auf Open-Source-Software. Er listet 15 Anforderungen in sechs Kategorien: Governance, Legal, Quality, Build and Release, Vulnerability Management und Decommissioning. Er benennt keine für die Umsetzung verantwortliche Partei, sondern nennt drei mögliche Umsetzungswege über Upstream-Mitarbeit, Maintainer oder einen Downstream-Fork.