Ein Auftraggeber, der unter die NIS2-Sorgfaltspflicht fällt, muss nachweisen können, dass er die Risiken in seiner eigenen Lieferkette kennt. Software, die Sie für diesen Auftraggeber entwickeln, ist Teil dieser Lieferkette. In der Praxis übersetzt sich dies in Vertragsanforderungen, die auf zwei Dinge gleichzeitig abzielen: das Produkt, das Sie liefern, und die Art und Weise, wie Sie dieses Produkt entwickeln. Beides kehrt in der Vertragstext zurück, oft als Anlage zum Einkaufsvertrag.
Der Kern ist einfach zu merken: Der Auftraggeber fragt nicht nur, ob die Software funktioniert, sondern auch, ob Sie nachweisen können, wie sie sicher bleibt, wer darauf zugreifen kann und was passiert, wenn etwas schiefgeht. Dies ist eine Verschiebung gegenüber früher, als Funktionalität und Lieferfrist oft die einzigen Gesprächspunkte waren.
Anforderungen an das Produkt, das Sie liefern
Die häufigste Vertragsanforderung betrifft die Zusammensetzung der Software selbst. Auftraggeber fordern zunehmend einen Überblick über die verwendeten Bibliotheken und Open-Source-Komponenten an, eine sogenannte Softwarekomponentenliste. Der Grund dafür ist, dass eine Anfälligkeit in einer zugrunde liegenden Komponente genauso ein Risiko darstellt wie ein Fehler in Ihrem eigenen Code, und dass ein Auftraggeber diese Risiken durchschauen möchte, ohne selbst den Quellcode zu lesen.
Darüber hinaus kommen Anforderungen hinzu, wie Anfälligkeiten in der Software erkannt und behoben werden und innerhalb welcher Frist. Dies kann automatisierte Scans auf bekannte Schwachstellen, ein festes Patchverfahren oder die Frage umfassen, wer eine Anfälligkeit melden darf und wo diese dann hingeht. Bei vorhandener Software wird manchmal auch nach der Unterstützungsdauer gefragt: Wie lange wird eine Version mit Sicherheitsupdates unterstützt.
Anforderungen an Ihren eigenen Entwicklungsprozess
Ein zweiter Cluster von Anforderungen richtet sich nicht auf das Produkt, sondern auf den Prozess, mit dem es hergestellt wird: den Entwicklungsprozess. Denken Sie an die Frage, wer Zugriff auf den Quellcode und die Umgebung hat, in der entwickelt und getestet wird, wie Änderungen kontrolliert werden, bevor sie live gehen, und ob eine Trennung zwischen einer Test-, einer Akzeptanz- und einer Produktionsumgebung besteht. Auch die Verwendung von Mehrfaktor-Authentifizierung für Entwickler, die Zugriff auf Quellcode oder Build-Systeme haben, kehrt in Verträgen zurück, ebenso wie die Frage, wer die Schlüssel und Anmeldedaten verwaltet, die mit der Bereitstellung von Software verbunden sind.
Einige Auftraggeber fragen auch nach der Herkunft der Software, die Sie selbst zum Entwickeln einsetzen: den Compiler, die Build-Tools, die Pakete, die während des Buildprozesses abgerufen werden. Dies entspricht einem breiteren Bewusstsein, dass ein Angriff nicht nur über das Endprodukt erfolgen kann, sondern auch über die Fabrik, in der es hergestellt wird.
Warum diese Anforderungen genau so formuliert sind
Die Sorgfaltspflicht, die all dem zugrunde liegt, verpflichtet ein betroffenes Unternehmen, Risiken in seiner eigenen Lieferkette zu beurteilen und zu bewältigen. Wie dies genau ausgearbeitet wird, unterscheidet sich je nach Land im nationalen Gesetz, das auf der Europäischen Richtlinie basiert, und je nach dem Sektor, in dem der Auftraggeber tätig ist. Was in einem Vertrag eine zwingende Anforderung ist, steht in einem anderen Vertrag noch als unverbindliche Frage. Wenn Sie wissen möchten, wie diese Verpflichtung im Kern aufgebaut ist, lesen Sie dies in der Erläuterung pro Verpflichtung in unserer Wissensdatenbank.
Wichtig zu merken: Der Auftraggeber stellt diese Anforderungen, weil er selbst unter Aufsicht steht, nicht weil Softwareunternehmen als solche unter die Richtlinie fallen. Ob und wie streng dies in Ihrem Fall umgesetzt wird, hängt vom Sektor und der Größe dieses spezifischen Auftraggebers ab. Für Ihre Situation ist der Text des nationalen Gesetzes oder der Rat eines Juristen der geeignete Ausgangspunkt, nicht eine allgemeine Schätzung.
Was dies für Ihre Vorbereitung bedeutet
Die meisten dieser Anforderungen lassen sich mit etwas Vorarbeit gut beantworten, und die Antwort, die Sie einmal formulieren, können Sie bei jedem nächsten Auftraggeber erneut verwenden. Eine Liste der verwendeten Komponenten, eine kurze Beschreibung Ihrer Zugriffskontrolle und ein standardisiertes Patch-Verfahren sind keine Dokumente, die Sie für jeden Vertrag neu erstellen müssen.
Wenn Sie zunächst sehen möchten, ob und wie dies Ihr Unternehmen betrifft, dann gibt die Überprüfung, die in einigen Fragen Ihre Position in der Lieferkette bestimmt, eine erste Orientierung, ohne dass Sie dafür ein Konto benötigen. Für die Fragen, die Auftraggeber konkret stellen, und die Art, wie wir Ihnen dabei helfen, lesen Sie mehr auf der Seite mit häufig gestellten Fragen oder sehen Sie sich an, wie wir die Informationen auf der Plattform begründen..
Die kostenlose Wissensdatenbank und die Überprüfung geben Ihnen einen ersten Überblick ohne Verpflichtungen. Wenn Sie dann die Vertragsanforderungen tatsächlich in ein laufendes Dossier mit Nachweisen und vorgefertigten Antworten auf Fragelisten umsetzen möchten, ist dies der Moment, um zu prüfen, was ein Abonnement zusätzlich bietet.