Dein Blog zum Thema digitales Business

Immer mehr Softwareverträge enthalten eine Klausel, die verlangt, dass der Anbieter seine Systeme nach dem „Stand der Technik“ absichert. Der Satz klingt harmlos und wird oft überlesen. Er verschiebt aber die Beweislast: Wer unterschreibt, verpflichtet sich zu einem Sicherheitsniveau, das nicht der Vertrag definiert, sondern die Fachwelt. Und der bewegt sich. Was 2022 als angemessen galt, kann heute bereits als fahrlässig gelten. Dieser Beitrag zeigt, was der Begriff konkret bedeutet und wie kleine Softwarehäuser damit umgehen, ohne sich in Formeln zu verlieren.

Ein unbestimmter Begriff mit klarer Wirkung

„Stand der Technik“ ist ein juristisch unbestimmter Rechtsbegriff. Er beschreibt das, was fachlich anerkannt, praktisch erprobt und allgemein verfügbar ist. Er liegt unterhalb des „Standes von Wissenschaft und Forschung“, der auch das theoretisch Mögliche umfasst, und oberhalb der „allgemein anerkannten Regeln der Technik“, die schon länger etabliert sind. Für den Alltag heißt das: Es geht nicht um das teuerste oder neueste Werkzeug, sondern um das, was ein sorgfältiger Anbieter im gleichen Umfeld einsetzen würde.

Der Reiz für den Kunden liegt genau darin, dass die Klausel offen bleibt. Er muss nicht jede Maßnahme einzeln aufzählen. Wenn etwas schiefgeht, prüft ein Gericht oder ein Gutachter im Nachhinein, ob das eingesetzte Niveau dem entsprach, was zum Zeitpunkt der Leistung üblich und zumutbar war. Der Anbieter trägt das Risiko der Auslegung.

Woran der Stand der Technik festgemacht wird

Der Begriff steht nicht in der Luft. In der Praxis stützen sich Gutachter auf veröffentlichte, breit akzeptierte Referenzen. Dazu gehören die BSI-Grundschutz-Kataloge, die Normenreihe ISO/IEC 27001, für die Softwarelieferkette zunehmend Rahmenwerke wie SLSA oder die Empfehlungen der ENISA. Branchenverbände geben ergänzende Handreichungen heraus, etwa die des TeleTrusT zum „Stand der Technik“, die regelmäßig aktualisiert werden.

Keine dieser Quellen ist bindend wie ein Gesetz. Zusammen bilden sie aber den Korridor, an dem gemessen wird. Wer sich an keiner dieser Referenzen orientiert und im Schadensfall nur auf das eigene Bauchgefühl verweisen kann, steht schlecht da. Wer dokumentiert, an welchem Rahmenwerk er sich ausrichtet und warum, hat eine belastbare Grundlage.

Warum das Datum entscheidend ist

Der wichtigste und am häufigsten übersehene Punkt: Der Stand der Technik ist kein fester Wert, sondern ein Zeitpunkt. Maßgeblich ist, was im Moment der Leistungserbringung anerkannt war, nicht was bei Vertragsschluss galt. Ein Deploy-Verfahren, das vor drei Jahren als sicher durchging, kann heute überholt sein, weil ein bekannter Angriffsweg dazugekommen ist oder ein besseres Verfahren allgemein verfügbar wurde.

Praktisch bedeutet das eine Bringschuld. Der Anbieter muss mitbekommen, wenn sich der Korridor verschiebt, und nachziehen. Statische Deploy-Keys ohne Ablaufdatum, ungepinnte Third-Party-Actions oder fehlende Nachweise über die Herkunft eines Artefakts waren lange Randthemen. Heute stehen sie in jedem ernsthaften Sicherheitsleitfaden. Wer sie ignoriert, verlässt den Korridor, ohne es zu merken.

Was ein Softwarehaus konkret tun kann

Die Klausel lässt sich nicht wegverhandeln, denn Kunden brauchen sie für ihre eigene Compliance. Sie lässt sich aber beherrschen. Drei Schritte helfen:

• Referenz festlegen. An welchem Rahmenwerk richtet sich das Team aus? Ein benannter Bezug, etwa BSI-Grundschutz oder ISO/IEC 27001, macht die Auslegung nachvollziehbar und ersetzt Einzelfalldiskussionen.
• Umsetzung nachweisbar machen. Nicht die Maßnahme allein zählt, sondern der Beleg, dass sie greift. Ein signierter Freigabeprozess, eine Software-Stückliste zu jedem Release, protokollierte Zugriffsrechte. Nachweise, die im Prüffall automatisch vorliegen, statt im Nachhinein rekonstruiert zu werden.
• Turnus einbauen. Einmal im Quartal prüfen, ob sich am Korridor etwas verschoben hat. Das kostet einen halben Tag und verhindert, dass die Absicherung unbemerkt veraltet.

Der Aufwand ist überschaubar, wenn die Nachweise aus der normalen Bauweise fallen und nicht zusätzlich erzeugt werden müssen. Genau das ist der Unterschied zwischen einer Pipeline, die Sicherheit nebenbei belegt, und einer, in der jeder Kundenaudit zur Sonderaktion wird.

Sie wollen wissen, ob Ihre Pipeline dem Stand der Technik standhält? Der GitSecOps QuickCheck prüft Ihre Build- und Deploy-Kette auf die Lücken, die im Kundenaudit zuerst auffallen, und zeigt konkret, wo Nachweise fehlen. Ergebnis in 3 Werktagen, Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.