So wählen Sie einen Anbieter für Verteidigungssoftware-Entwicklung

Die Auswahl eines Softwareentwicklungsanbieters für ein Verteidigungsprogramm unterscheidet sich wesentlich von kommerzieller Softwarebeschaffung. Die Ausfallmodi sind anders, die Sorgfaltspflichtanforderungen sind höher, und die Konsequenzen einer falschen Wahl sind schwerer rückgängig zu machen. Ein kommerzielles Softwareprojekt, das seinen Termin verpasst, verursacht geschäftliche Unannehmlichkeiten. Ein Verteidigungssoftwareprojekt, das beim Einsatz scheitert, schafft operative Lücken, die direkte Auswirkungen auf Missionsergebnisse haben können.

Dieser Artikel behandelt die wesentlichen Bewertungskriterien — keine generische Fähigkeitsbewertung, sondern die spezifischen Signale, die Anbieter, die produktionsqualitätige Verteidigungssoftware liefern können, von denen unterscheiden, die es nicht können.

ISO 27001 und Qualitätszertifizierungen als Grundlage

ISO 27001 (Informationssicherheitsmanagement) und ISO 9001 (Qualitätsmanagement) sind notwendig, aber nicht ausreichend. Ein Anbieter ohne diese Zertifizierungen sollte für Programme, die klassifizierte oder sensible Daten verwalten, von der Berücksichtigung ausgeschlossen werden — nicht weil die Zertifikate selbst Qualität garantieren, sondern weil das Fehlen formaler Managementsysteme für Sicherheit und Qualität ein zuverlässiger Indikator dafür ist, dass Sicherheit und Qualität keine organisatorischen Prioritäten sind.

Behandeln Sie ISO 27001 als Mindeststandard, nicht als Höchstleistung. Fragen Sie nach dem Zertifizierungsumfang: Deckt er die Entwicklungsumgebung ab, in der Ihr Code geschrieben wird? Die Entwickler, die an Ihrem Programm arbeiten werden? Die DevOps-Infrastruktur? Eine Zertifizierung, die nur das Firmenbüro, aber nicht das Entwicklungsteam abdeckt, hat begrenzte Relevanz. Fordern Sie die Anwendbarkeitserklärung (Statement of Applicability) — das Dokument, das auflistet, welche Kontrollen implementiert und welche ausgeschlossen sind. Eine lange Liste von Ausschlüssen mit schwachen Begründungen ist ein Warnsignal.

Bei Programmen mit NATO-klassifizierten Informationen prüfen Sie, ob der Anbieter über eine industrielle Sicherheitsfreigabe (ISC) der zuständigen nationalen Behörde verfügt. Die ISC-Anforderungen variieren je nach Land, erfordern aber typischerweise eine Einrichtungssicherheitsgenehmigung, Personalsicherheitsüberprüfung und dokumentierte Sicherheitsverfahren für den Umgang mit klassifiziertem Material.

NATO- und STANAG-Erfahrung als Signal

Verteidigungssoftware ist eine enge Domäne. Ein Anbieter mit zehn Jahren kommerzieller Unternehmenssoftwareerfahrung, aber ohne Verteidigungsbereichsarbeit, wird bei seinem ersten Verteidigungsauftrag eine steile Lernkurve durchlaufen — und diese Lernkurve wird von Ihrem Programmbudget finanziert. Frühere NATO- oder STANAG-bezogene Arbeit ist ein konkretes Signal, dass der Anbieter Koalitionsdatenaustausch, Klassifizierungshandhabung und die spezifischen Einschränkungen militärischer Netzwerkumgebungen versteht.

Fragen Sie konkret: Welche STANAG-Standards haben sie implementiert? An welche NATO-Programme haben sie geliefert? Haben sie an NATO-Übungen oder Interoperabilitätsveranstaltungen teilgenommen (wie dem Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — CWIX)? Die Antworten auf diese Fragen sind überprüfbar — CWIX-Teilnahme ist dokumentiert, und NATO-Programmerfahrung kann referenzgeprüft werden.

Erfolgsbilanz operativer Bereitstellungen

Die wichtigste Unterscheidung in Verteidigungssoftware liegt zwischen Systemen, die demonstriert wurden (in einer kontrollierten Testumgebung, vor einem Evaluierungsgremium) und Systemen, die eingesetzt wurden (bei operativen Nutzern, in einer echten Umgebung, bei echter Arbeit). Ein Anbieter, dessen Portfolio ausschließlich aus Demonstratoren und Prototypen besteht, wurde nicht durch operative Realität getestet. Ein Anbieter, dessen Systeme in tatsächlichen Operationen liefen, schon.

Verlangen Sie Referenzen aus operativen Bereitstellungen — nicht von Programmmanagern, sondern von den Operateuren oder technischen Leitern, die das System tatsächlich verwendet haben. Fragen Sie nach Zuverlässigkeit im Feld: Welche Ausfälle traten auf? Wie wurden sie behandelt? Wie war die Supportreaktionszeit? Ein Anbieter, der vage über operative Erfahrung ist oder nur Demonstrationen anführt, ist ein Anbieter, dessen Software nicht im Ernstfall eingesetzt wurde.

Im Europa nach 2022 ist ein operativer Einsatz im Ukraine-Konfliktskontext zu einem besonders hochrangigen Nachweis geworden. Das Tempo, die Intensität und der Peer-Adversary-Charakter dieses Umfelds hat Verteidigungssoftware auf Weisen belastet, die Übungen nicht replizieren können. In diesem Kontext entwickelte und verbesserte Systeme tragen eine andere Klasse operativer Glaubwürdigkeit als solche, die dies nicht haben.

Überlegungen zur Sicherheitsfreigabe des Teams

Wenn Ihr Programm klassifizierte Daten beinhaltet, muss das Entwicklungsteam für das entsprechende Niveau freigegeben sein. Dies ist keine Formalität — es schränkt direkt ein, wer am Programm arbeiten kann und wie die Entwicklung strukturiert werden kann. Ein Anbieter, der vorschlägt, ein SECRET-level-Programm mit nicht freigegebenen Offshore-Entwicklern zu besetzen, hat entweder die Klassifizierungsanforderungen nicht gelesen oder nimmt sie nicht ernst.

Fragen Sie, welche Entwickler freigegeben sind und auf welchen Niveaus. Bei Programmen mit strengen Sicherheitsanforderungen verlangen Sie individuelle Sicherheitsfreigabe-Bestätigungen (Zusammenfassung, keine vollständigen Hintergrundprüfungsdetails) für die vorgeschlagenen Teammitglieder. Wenn der Anbieter Freigaben für das Programm einholen muss, fragen Sie nach dem Zeitplan und seiner Erfahrung mit dem nationalen Sicherheitsüberprüfungsprozess. Freigabeprozesse in den meisten NATO-Ländern dauern 6–18 Monate; ein Anbieter, der diesen Prozess noch nicht begonnen hat, kann ein klassifiziertes Programm nicht termingerecht besetzen.

IP-Eigentum und Quellcode-Treuhandschaft

Verteidigungssoftwareprogramme müssen von Anfang an klare IP-Eigentümerschaft etablieren. Wenn die Software speziell für Ihr Programm entwickelt wird, benötigen Sie Eigentum oder eine unwiderrufliche Lizenz. Wenn sie auf einer kommerziellen Plattform oder einem Framework aufgebaut wird, müssen Sie die Lizenzbedingungen für operative und klassifizierte Bereitstellungen verstehen. Eine kommerzielle Softwarelizenz, die die Installation auf klassifizierten Netzwerken verbietet — was einige tun —, ist unvereinbar mit Ihrem Programm, unabhängig von den sonstigen Fähigkeiten des Anbieters.

Quellcode-Treuhandschaft ist Standardpraxis für missionskritische Verteidigungssoftware: Der Quellcode, Build-Skripte und Bereitstellungsdokumentation werden bei einem Drittanbieter-Treuhänder hinterlegt, was sicherstellt, dass Sie das System aufbauen und pflegen können, wenn der Anbieter übernommen wird, in Konkurs geht oder die Beziehung beendet. Jeder Anbieter, der sich einer Quellcode-Treuhandschaft für ein missionskritisches Programm widersetzt, ist ein Anbieter, der nicht dem langfristigen Erfolg des Programms verpflichtet ist.

Support-SLA in operativen Umgebungen

Verteidigungssoftware-Supportanforderungen unterscheiden sich von kommerziellem Enterprise-Support. Ein ERP-System, das während der Geschäftszeiten ausfällt, ist ein erhebliches Problem, das in Stunden behoben werden kann. Ein C2-System, das während einer Operation ausfällt, ist eine andere Kategorie von Problem, die eine andere Kategorie von Reaktion erfordert. Definieren Sie vor der Unterzeichnung die Support-SLA explizit: maximale Reaktionszeit (nicht Bestätigungszeit — tatsächliche Reaktion), maximale Zeit bis zur vorübergehenden Lösung, maximale Zeit bis zur vollständigen Lösung und den Eskalationspfad für operative Notfälle.

Erwägen Sie bei operativen Systemen, den Anbieter zu verpflichten, ein freigegebenes Support-Team mit 24/7-Verfügbarkeit und dokumentierten Playbooks für die wahrscheinlichsten Ausfallszenarien zu unterhalten. Die Kosten dieser Fähigkeit sind real; ein Anbieter, der sie günstig anbietet, kann sie entweder nicht aufrechterhalten oder ist bezüglich seines Kostenmodells nicht ehrlich.

Warnsignale

Unfähigkeit, spezifische operative Bereitstellungen zu nennen — nicht Programme, sondern tatsächlich eingesetzte Systeme. Unklare Eigentümerschaft des Entwicklungsteams (Body-Shopping, nicht offengelegte Unterauftragnehmer). Widerstand gegen Sicherheitsüberprüfungen ihrer Entwicklungsinfrastruktur. Eine Lücke zwischen dem Dienstalter des Vertriebsteams und dem Dienstalter des vorgeschlagenen Lieferteams. Unwilligkeit, vor der Vertragsunterzeichnung auf eine feste Sicherheitsarchitektur zu verpflichten. Dies sind konsistente Indikatoren für einen Anbieter, der besser darin ist, Verträge zu gewinnen als sie zu liefern.