Einsatzbereite Software in Wochen statt Jahren: Entwicklungsplattformen, auf denen sichere Software entsteht, mit Security und Nachweisführung von Anfang an.
Software Defined Defence verschiebt den Takt: Fähigkeiten entstehen nicht mehr über Jahrzehnte in Hardware-Plattformen, sondern in Software-Release-Zyklen. Wer schneller entwickelt, integriert und ausrollt, gewinnt den entscheidenden Vorteil. Voraussetzung dafür ist keine einzelne Anwendung, sondern eine industrialisierte Entwicklungsumgebung: eine Software Factory, in der Bauen, Testen, Absichern und Nachweisen automatisiert und wiederholbar ablaufen.
Genau hier setzen wir an. Wir konzipieren und betreiben Entwicklungsplattformen, die Security nicht nachgelagert prüfen, sondern in jeden Schritt der Pipeline einweben – vom ersten Commit bis in die klassifizierte Zielumgebung.
Jedes Team baut sich sonst seine eigene Toolchain, mit eigenen Lücken. Wir schaffen eine gemeinsame Plattform mit vorkonfigurierten, gehärteten Build- und Deployment-Pfaden, Self-Service für Entwicklungsteams und zentral gepflegten Golden Paths. Teams liefern schneller, weil sie Infrastruktur nutzen statt sie zu bauen, und die Organisation gewinnt eine einheitliche, prüfbare Grundlage.
Wir integrieren statische und dynamische Codeanalyse, Dependency- und Container-Scanning, Secrets-Erkennung, Signierung von Artefakten und eine durchgängige Software Bill of Materials (SBOM): Sicherheitsprüfungen laufen automatisiert bei jedem Build. Was die Gates nicht besteht, geht nicht in Produktion, ohne dass ein Mensch daran erinnern muss. Lieferkettenrisiken werden sichtbar, bevor sie im Feld stehen.
Beschleunigte Zulassungsprozesse gelingen durch die automatisierte Generierung von Prüfnachweisen direkt in der CI/CD-Pipeline statt zeitintensiver manueller Dokumentation. Eingebettet in den Secure Software Development Lifecycle (SSDLC) werden Testergebnisse, Konfigurationen und Freigaben lückenlos versioniert sowie auditierbar erfasst. Das schafft die technische Evidenzgrundlage für ein kontinuierliches Akkreditierungsmodell (Continuous ATO) und verkürzt Entwicklungs- und Zulassungszyklen deutlich.
Nicht jede Zielumgebung hat Internetzugang. Wir bauen Pipelines, die mit gespiegelten Artefakt-Registries, reproduzierbaren Builds und kontrollierten Transferwegen auch ohne durchgängige Netzverbindung funktionieren, vom Rechenzentrum bis zum Deployment am taktischen Edge. Was in der offenen Umgebung entwickelt wird, lässt sich nachvollziehbar in die geschützte überführen.
Die wenigsten Vorhaben starten auf der grünen Wiese. Wir überführen gewachsene, monolithische Systeme schrittweise in modulare, containerisierte Architekturen nach dem Gedanken offener Systemarchitekturen, in den USA als Modular Open Systems Approach (MOSA) bezeichnet, ohne den laufenden Betrieb zu unterbrechen und ohne neue Abhängigkeiten von einzelnen Herstellern zu schaffen.
Wir schauen uns Ihre Pipeline an und zeigen, welche Nachweise sich automatisieren lassen und wo die Zulassung heute Zeit kostet.
Wir konzipieren und bauen Entwicklungsplattformen für Umfelder, in denen Nachweispflichten und Verfügbarkeit Mindestanforderungen sind.
Kurze Release-Zyklen und hohe Sicherheitsanforderungen sind kein Widerspruch, wenn Prüfungen automatisiert stattfinden statt am Ende manuell. Unsere Pipelines liefern bei jedem Build den vollständigen Sicherheits- und Qualitätsnachweis mit. Das verkürzt nicht nur die Entwicklungszeit, sondern vor allem die Zeit bis zur Freigabe, also den Teil, der in Verteidigungsvorhaben typischerweise am längsten dauert.
Wir bauen auf offenen Standards und Open-Source-Technologien, die sich sowohl in souveränen Cloud-Umgebungen als auch on-premises und air-gapped betreiben lassen. Sie behalten die Kontrolle über Code, Daten und Betrieb, setzen auf austauschbare Komponenten und bleiben im Sinne modularer, offener Systemarchitekturen (MOSA) integrationsfähig gegenüber Dritten.
Unsere Entwicklungsprojekte folgen einem definierten SSDLC: Bedrohungsmodellierung im Design, automatisierte Code- und Abhängigkeitsanalyse in der Entwicklung, Sicherheitstests vor der Freigabe, Schwachstellenmanagement im Betrieb. Weil die Sicherheitsaktivitäten pro Phase festgelegt sind, ist der Prozess selbst prüfbar, nicht nur das Ergebnis. Auf Unternehmensebene unterliegen unsere Prozesse zusätzlich einem zertifizierten Informationssicherheitsmanagement: ISO/IEC 27001 (TÜV Hessen), ISO 9001 sowie TISAX mit Assessment Level 3 in der höchsten Schutzbedarfsstufe. Sicherheit ist bei uns damit nicht nur Projektpraxis, sondern extern auditierter Unternehmensstandard.
Für dmTECH haben wir eine Continuous-Delivery-Pipeline mit Jenkins, Konfigurationsmanagement über Puppet, Server-Lifecycle-Management mit Foreman und ein durchgängiges Patch-Management aufgebaut. Web-Dienste sollten auf Knopfdruck bereitstehen, um Administratorinnen und Administratoren von Routineaufgaben zu entlasten. Die DevOps-Strukturen für die Plattform haben wir federführend konzipiert und implementiert.
Für RTL Technology haben wir die bestehende Video-on-Demand-Plattform umgebaut und weiterentwickelt – ohne den Betrieb zu unterbrechen. Teil des Vorhabens war die Umstrukturierung der Entwicklung in eine große Zahl crossfunktionaler Teams mit dedizierten Themenbereichen, koordiniert über skaliertes Scrum. Der Prozess dauerte rund ein Jahr.
Für die Senderportale von ProSiebenSat.1 übernehmen wir den DevOps-Betrieb, nicht nur die Entwicklung. Wer eine Plattform selbst betreibt, baut sie anders: beobachtbar, aktualisierbar und mit belastbaren Rückfallpfaden.
Für Azena haben wir an einem Ökosystem mitgebaut, über das Anwendungen auf Kameras verschiedener Hersteller ausgeliefert werden, mit Freigabe- und Signaturprozess, damit auch Software von Dritten kontrolliert auf den Geräten laufen kann. Für die Videopipeline haben wir zunächst prototypisch nachgewiesen, dass die Anforderungen unter Android erfüllbar sind.
Eine Software Factory ist eine standardisierte, weitgehend automatisierte Umgebung, in der Software gebaut, getestet, abgesichert und ausgeliefert wird. Statt dass jedes Projekt seine eigene Werkzeugkette zusammenstellt, nutzen alle Teams dieselben gehärteten und geprüften Pfade. Der Nutzen liegt in drei Punkten: Entwicklungsteams werden schneller, weil Standardaufgaben nicht wiederholt gelöst werden. Sicherheit wird verlässlicher, weil Prüfungen nicht vergessen werden können. Und Zulassung wird planbarer, weil die notwendigen Nachweise als Nebenprodukt jedes Builds entstehen.
Ja. Der übliche Ansatz ist eine zweigeteilte Architektur: eine Entwicklungsumgebung mit kontrolliertem Außenzugang und eine gespiegelte Zielumgebung ohne Netzanbindung. Alle externen Abhängigkeiten werden in interne, geprüfte Registries übernommen; Builds sind reproduzierbar, Artefakte signiert. Der Transfer in die geschützte Umgebung erfolgt über definierte, protokollierte Datenschleusen. Für den Betrieb dort eignen sich nur Werkzeuge, die vollständig offline lauffähig sind.
Continuous ATO (cATO) bezeichnet den Ansatz, eine Betriebsfreigabe nicht einmalig für einen eingefrorenen Systemstand zu erteilen, sondern die Erfüllung der Sicherheitsanforderungen kontinuierlich nachzuweisen, über eine zugelassene Plattform und automatisierte Nachweise. Der Begriff stammt aus dem US-Verteidigungsumfeld und ist nicht eins zu eins auf deutsche Zulassungsverfahren übertragbar. Die technische Grundlage ist es aber sehr wohl: automatisierte, lückenlose und maschinenlesbare Nachweisführung beschleunigt jedes Zulassungsverfahren, unabhängig davon, nach welchem Regelwerk es läuft.
Durch drei Prinzipien. Erstens setzen wir bevorzugt auf Open-Source-Komponenten und offene Standards, deren Verhalten überprüfbar ist. Zweitens schneiden wir Architekturen modular nach dem Gedanken offener Systemarchitekturen, in den USA als Modular Open Systems Approach (MOSA) bezeichnet, sodass einzelne Bausteine austauschbar bleiben. Drittens übergeben wir Code, Infrastrukturdefinitionen und Dokumentation vollständig: Sie können die Plattform selbst betreiben oder den Betrieb an Dritte geben. Unsere Rolle ist Befähigung, nicht Bindung.
DevOps verbindet Entwicklung und Betrieb. DevSecOps ergänzt Sicherheit als gleichrangige Disziplin, die in jeder Phase mitläuft, statt am Ende als Prüfschritt aufzutauchen. Konkret heißt das: Bedrohungsmodellierung bereits im Design, automatisierte Sicherheitsprüfungen in der Pipeline, Härtung der Laufzeitumgebung und kontinuierliches Monitoring im Betrieb. Der entscheidende Unterschied ist zeitlich: Ein Sicherheitsproblem, das im Design gefunden wird, kostet einen Bruchteil dessen, was es nach der Auslieferung kostet.
Ein Secure Software Development Lifecycle (SSDLC) beschreibt, welche Sicherheitsaktivitäten in welcher Phase der Softwareentwicklung verbindlich stattfinden müssen: Bedrohungsmodellierung im Design, Code-Analyse in der Entwicklung, Penetrationstests vor der Freigabe, Schwachstellenmanagement im Betrieb. DevSecOps beschreibt, wie diese Aktivitäten organisatorisch und technisch umgesetzt werden: automatisiert, kontinuierlich und in der Verantwortung des Entwicklungsteams. Der SSDLC ist das Regelwerk, DevSecOps die Betriebsform. Für Zulassung und Nachweisführung ist der SSDLC der relevante Bezugsrahmen, weil er sich auf Prozessebene prüfen lässt.
Der Widerspruch entsteht nur, wenn Dokumentation eine eigene Phase nach der Entwicklung ist. Entstehen die Nachweise stattdessen in der Pipeline, also Testprotokolle, Software-Stücklisten, signierte Artefakte und versionierte Konfigurationsstände bei jedem Build, dann liefert jede Iteration dieselben Belege, die eine Prüfung verlangt, nur früher und vollständiger. Kurze Zyklen und lückenlose Nachvollziehbarkeit sind dann kein Gegensatz, sondern dieselbe Eigenschaft. In den USA wird dieser Ansatz unter dem Begriff Continuous Authority to Operate für Verteidigungssoftware praktiziert.
Die Bedrohungslage wartet nicht auf lange Entwicklungszyklen. Wir bringen Ihre Software in Release-Geschwindigkeit – souverän, sicher, einsatzbereit.