Bei der Incident-Registrierung in der Softwareentwicklung geht es um zwei verschiedene Dinge, die oft vermischt werden: eine Schwachstelle oder ein Fehler in der Software, die Sie entwickeln und liefern, und ein Incident in Ihrer eigenen Entwicklungsumgebung — der Umgebung, in der Sie diese Software erstellen. Was Sie dokumentieren, wer Bescheid wissen muss und welche nächsten Schritte erforderlich sind, unterscheiden sich je nach Art. Wer diesen Unterschied nicht macht, übersieht oft den Incident, der am meisten zählt: eine Kontamination in der Build-Pipeline, die sich über den Code auf alle Kunden ausbreitet, die diesen verwenden.
Eine Schwachstelle in geliefertem Code betrifft den Kunden direkt: Er führt die Software aus, also trägt er das Risiko. Ein Incident in der Entwicklungsumgebung — ein gestohlener Zugangsschlüssel, ein kompromittiertes Build-Konto, ein Leck in der Quellcode-Repository — betrifft zunächst Sie, kann sich aber auf jeden Kunden auswirken, der mit diesem Code arbeitet. Bei beiden gilt: Ein Security-Fragebogen oder ein Auditor fragt nicht, ob jemals etwas schiefgegangen ist, sondern ob Sie nachweisen können, was Sie davon dokumentiert und gelernt haben.
Was Sie bei einem Incident im Code dokumentieren
Bei einer Schwachstelle oder einem Fehler in gelieferter Software geht es um: wann es entdeckt wurde, von wem oder was (interner Test, Kundenmelding, Scan, externer Forscher), welcher Teil der Software betroffen ist, welche mögliche Auswirkung es gibt, welche Maßnahme ergriffen wurde und an welchem Datum, und wer in Ihrer Organisation für die Verfolgung verantwortlich ist. Eine gute Dokumentation macht auch sichtbar, ob ein Fix für alle Kunden ausgerollt wurde, die die betreffende Version verwenden, oder nur für denjenigen, der es meldete. Genau das ist es, wonach ein Abnehmer in einem Fragebogen fragt: nicht ob Sie jemals eine Schwachstelle hatten, sondern ob Ihr Prozess garantiert, dass jeder, der davon betroffen ist, auch davon erfährt.
Was Sie bei einem Incident in der Entwicklungsumgebung dokumentieren
Ein Incident in Ihrer eigenen Entwicklungsumgebung — ein kompromittiertes Konto mit Zugriff auf den Quellcode, ein Build-Server, der sich unerwartet verhält, eine Abhängigkeit, die sich später als bösartig herausstellt — erfordert eine etwas andere Dokumentation. Hier geht es um: welches System oder Konto betroffen war, wer in dem Zeitraum darauf Zugriff hatte, ob Spuren dafür vorhanden sind, dass Code geändert oder eingesehen wurde, und welche Kunden möglicherweise Software verwenden, die in diesem Zeitraum entwickelt oder geliefert wurde. Dies ist die Art von Incident, die direkt mit der Zugriffskontrolle in der Entwicklungsumgebung zusammenhängt: Ohne einen aktuellen Überblick darüber, wer auf was zugreifen darf, ist diese Aufklärungsfrage bei einem Incident erheblich schwieriger zu beantworten.
Wen Sie informieren und wen nicht
Ob Sie selbst unter die Sorgfaltspflicht des Cyberbeveililigungsgesetzes fallen oder nicht, bestimmt, wen Sie über einen Incident informieren. Entitäten, die selbst als wesentlich oder wichtig eingestuft sind, haben eine Meldepflicht gegenüber ihrer Aufsichtsbehörde; was genau gemeldet werden muss und innerhalb welcher Frist, ist in der Richtlinie und dem nationalen Gesetz beschrieben und unterscheidet sich je nach Situation. Ein Softwareunternehmen, das über die Lieferkette betroffen ist — also selbst nicht meldepflichtig ist, aber an einen Kunden liefert, der dies ist — hat keine Meldepflicht gegenüber der Aufsichtsbehörde, hat aber normalerweise eine vertragliche Verpflichtung, den Kunden zu informieren. Das macht die eigene Dokumentation nicht weniger wichtig: Ein Kunde, der fragt, ob Sie jemals einen Incident hatten, möchte eine konkrete Antwort sehen, keine nachträgliche Schätzung.
Ein lebendes Register, kein Archiv
Die Verwaltung von Incident-Meldungen funktioniert am besten als ein lebendes Dokument: eine Liste, in der pro Incident Status, Nachweis und Verantwortlicher zu finden sind, anstatt eines isolierten Berichts, der nach Behebung in einer Akte verschwindet. Das entspricht dem Aufbau der umfassenderen Sorgfaltspflicht, mit zehn Maßnahmen, die jeweils einen Status und einen Verantwortlichen erfordern. Wer sehen möchte, wie sich die Incident-Verwaltung zu den neun anderen Maßnahmen verhält, findet diesen Überblick auf der Seite mit allen Themen je nach Situation.
Ob Ihre Organisation selbst der Sorgfaltspflicht unterliegt, über die Lieferkette betroffen ist oder keines von beiden, lässt sich mit ein paar Fragen feststellen über die NIS2-Überprüfung, die in wenigen Fragen eine Orientierung gibt. Wer genau wissen möchte, woher die Informationen auf secria.eu stammen und wie sie aktualisiert werden, liest das auf der Seite über die Funktionsweise. Und wer nach dem Lesen wissen möchte, was ein Abonnement zu dem hier kostenlos Verfügbaren hinzufügt, findet das übersichtlich auf der Übersicht der Leistungen.
Dieser Text ist eine allgemeine Erläuterung und keine Rechtsberatung zu Ihrer spezifischen Situation. Für eine Bewertung Ihres konkreten Incident-Prozesses oder Ihrer Meldepflicht wenden Sie sich an einen Rechtsanwalt oder an die für Ihren Sektor zuständige Aufsichtsbehörde.