NIS2, KRITIS und sichere Softwarelieferung

Warum Agenturen betroffen sein können

NIS2 adressiert wichtige und wesentliche Einrichtungen in vielen Sektoren – von Energie und Gesundheit über Verkehr bis zu digitalen Diensten. Eine kleine Software-Agentur fällt selten selbst unmittelbar darunter. Relevant wird das Thema trotzdem, und zwar über einen indirekten Weg: über Kundenanforderungen, Lieferketten, Hosting, Betrieb und den Zugriff auf produktive Systeme. Die Richtlinie verpflichtet betroffene Unternehmen ausdrücklich, auch die Sicherheit ihrer Lieferanten und Dienstleister zu berücksichtigen.

Wer Software für regulierte Kunden baut oder betreibt, wird deshalb häufiger nach Sicherheitsprozessen, Zugriffskonzepten, Incident Handling und Nachweisen gefragt. Diese Fragen kommen dann nicht von einer Behörde, sondern vom Kunden selbst – als Teil seiner eigenen Pflichten. Praktisch heißt das: Anforderungen aus NIS2 wandern über Verträge und Audits in die Lieferkette und erreichen am Ende auch kleinere Dienstleister.

Wir geben hier bewusst keine verbindliche Einschätzung ab, wer im Einzelfall direkt unter NIS2 fällt – das ist eine Frage für die konkrete Branche, Größe und Rechtsberatung. Die praktische Botschaft bleibt aber unabhängig davon dieselbe: Dokumentierte Sicherheit wird vom Wettbewerbsvorteil zur Grundvoraussetzung.

Was KI-Agenten daran ändern

KI-Agenten können schneller Code ändern, aber sie können auch schneller Fehler verteilen. Ein Agent, der in Minuten über viele Dateien hinweg arbeitet, kann genauso schnell eine unsichere Abhängigkeit einziehen, ein Secret offenlegen oder eine Konfiguration kippen. Deshalb brauchen Agenturen klare Grenzen: keine ungeprüften Secrets im Klartext, keine blinden Deployments ohne Freigabe, keine unprotokollierten Änderungen an produktiven Systemen.

Ein professioneller KI-Workflow muss nachweisen können, welche Aufgabe gestellt wurde, welche Dateien geändert wurden, welche Tests liefen und wer freigegeben hat. Genau diese Nachvollziehbarkeit ist es, die NIS2-nahe Kundenanforderungen verlangen – und die ein unkontrollierter „Agent macht einfach“-Ansatz nicht liefern kann.

Konkrete Bausteine für sichere Softwarelieferung

Sichere Lieferung ist weniger eine Frage einzelner Werkzeuge als eine Frage konsequenter Routinen. Folgende Bausteine lassen sich auch in kleinen Teams umsetzen:

• Least Privilege: Jeder Account, jeder Token und jeder Agent erhält nur die Rechte, die für die Aufgabe nötig sind – nicht mehr.
• Secrets-Management: Zugangsdaten gehören in einen Tresor oder verschlüsselte Secret-Stores, nicht in den Code und nicht in Prompts.
• Abhängigkeiten prüfen: Neue Pakete werden auf Herkunft und bekannte Schwachstellen geprüft, automatisierte Scans laufen mit.
• Review-Pflicht: Kein Merge in die Hauptcodebasis ohne menschliche Freigabe, gerade bei KI-generierten Änderungen.
• Protokollierung: Wer hat was wann geändert und freigegeben – als durchsuchbarer Verlauf, nicht als Erinnerung.
• Incident-Vorbereitung: Ein einfacher, geübter Ablauf für den Ernstfall, inklusive Meldewegen und Verantwortlichkeiten.

Keiner dieser Punkte ist neu. Neu ist, dass KI-Geschwindigkeit sie von „nice to have“ zu Pflicht macht, weil Fehler ohne Leitplanken schneller und breiter wirken.

Häufige Fehler

In der Praxis sehen wir wiederkehrende Schwachstellen, die sich mit überschaubarem Aufwand vermeiden lassen:

• Security erst kurz vor dem Audit: Prozesse werden hektisch nachgebaut, statt von Anfang an mitzulaufen.
• Geteilte Admin-Zugänge: Mehrere Personen nutzen denselben Account, sodass sich Änderungen nicht zuordnen lassen.
• KI ohne Sandbox: Agenten arbeiten direkt auf produktiven Daten und Systemen, ohne abgegrenzte Umgebung.
• Dokumentation, die niemand pflegt: Ein Sicherheitskonzept, das einmal geschrieben und dann nie wieder angefasst wurde.

Wie NADOOIT die Lücke adressiert

Launchpad und unsere KI-Entwicklerkurse positionieren KI-Arbeit als überprüfbaren Prozess: Issue, Umsetzung, Tests, Review, Nachweis und Übergabe. Jeder Schritt hinterlässt eine Spur, sodass am Ende belegbar ist, wie eine Änderung entstanden und geprüft worden ist.

Das ist nicht nur Qualitätssicherung. Es ist eine Grundlage, um gegenüber Kunden glaubwürdig über sichere Softwarelieferung zu sprechen – und um auf Lieferkettenfragen souverän statt improvisiert zu antworten. Wer diese Routinen früh etabliert, muss sie nicht unter Druck nachholen, wenn der erste regulierte Kunde nach Nachweisen fragt.

Quellen und Weiterlesen

• EU-Kommission: NIS2 Directive
• ENISA: NIS Directive 2
• BSI: Lage der IT-Sicherheit
• OWASP Top 10 for LLM Applications