Wir entwickeln nicht selbst. Brauchen wir Code-Sicherheit trotzdem?
Die häufigste Rückfrage aus dem Mittelstand, ehrlich beantwortet: Wer nur Software nutzt, die andere betreiben, hat nichts zu scannen. Wer eingekaufte Anwendungen selbst hostet, hat Abhängigkeiten und Konfigurationen, die altern. Und wer Skripte, Integrationen und kleine Werkzeuge im Repository liegen hat, entwickelt längst, ohne es so zu nennen.
Die Frage ist berechtigt
Sie kommt in fast jedem Erstgespräch: Wir sind ein Maschinenbauer, eine Spedition, eine Kanzlei. Wir kaufen Software, wir schreiben keine. Wozu Code-Sicherheit? Die Frage verdient eine genaue Antwort, keine Verkaufsantwort. Auf unserer Seite zur Code-Sicherheit steht sie in Kurzform. Hier folgt sie in drei Stufen, weil die Wahrheit davon abhängt, was im Unternehmen tatsächlich läuft, nicht davon, ob es sich als Softwarehaus versteht.
Stufe eins: Alles läuft bei Dritten
Wenn jede Anwendung im Unternehmen ein Dienst ist, den ein Anbieter betreibt, also Buchhaltung, Mail, CRM und Dateiablage aus der Cloud, ohne dass irgendwo ein eigener Server oder ein eigenes Repository existiert, dann ist die Antwort schlicht: Nein. Es gibt keinen Code, den wir anbinden könnten, und wir werden keinen erfinden. Die Sicherheit dieser Dienste liegt beim Anbieter, und die Risiken für das Unternehmen liegen woanders: bei Zugangsdaten, die im Umlauf sind, bei Konten, die nach einem Leak weitergenutzt werden.
Für diesen Fall ist unser Darknet-Monitoring der passende Einstieg, und wir sagen das im Gespräch, bevor ein Angebot geschrieben wird. Eine Code-Analyse für ein Unternehmen ohne Code wäre Umsatz ohne Nutzen.
Stufe zwei: Gekaufte Software auf eigenen Servern
Der häufigste Fall im Mittelstand ist ein anderer. Das ERP läuft auf dem eigenen Server. Das Warenwirtschaftssystem wurde vor sechs Jahren eingeführt und seitdem zweimal angepasst. Der Webshop ist ein Standardprodukt mit ein paar Erweiterungen. Niemand im Haus hat davon eine Zeile geschrieben, und trotzdem besteht jedes dieser Systeme aus Bestandteilen, die altern: Open-Source-Bibliotheken, für die Lücken bekannt werden, und Konfigurationen mit Voreinstellungen, die niemand mehr prüft.
Genau das ist der Teil des Scans, der ohne eigene Entwicklung funktioniert. Die Tiefenprüfung gleicht alle Abhängigkeiten gegen bekannte Schwachstellen ab und prüft die Konfiguration auf unsichere Voreinstellungen. Ob die Anwendung gekauft oder geschrieben wurde, spielt für die Bibliothek darin keine Rolle. Und nach § 30 BSIG zählt auch der Betrieb eingekaufter Systeme als Wartung, für die Schwachstellen zu managen sind; welche Belege dafür entstehen, steht im Beitrag zum Nachweis im Alltag.
Stufe drei: Der Code, den niemand Code nennt
In fast jedem Unternehmen, das nach eigener Aussage nicht entwickelt, liegt irgendwo ein Repository. Darin: das Skript, das nachts die Exporte in die Buchhaltung schiebt. Die Integration zwischen Shop und Lager, die ein ehemaliger Kollege gebaut hat. Das interne Werkzeug, mit dem der Vertrieb Angebote erzeugt. Ein paar Automatisierungen, ein Konnektor, eine Erweiterung für das ERP. Das ist Entwicklung, auch wenn es nie so genannt wurde.
Und diese Stücke haben eine Eigenschaft, die sie gefährlicher macht als das ERP selbst: Sie wurden selten unter Sicherheitsgesichtspunkten geschrieben. Erfahrungsgemäß liegen genau dort die hartkodierten Zugangsdaten, weil das Skript ja nur intern läuft, und die ungeprüften Eingaben, weil es ja nur der Kollege bedient. Der Sofort-Scan findet beides, sobald es in einem Repository liegt, das angebunden ist. Warum ein einmal eingechecktes Secret rotiert werden muss, steht im Beitrag über hartkodierte Secrets.
Wie man die eigene Stufe findet
Die Frage an sich selbst ist nicht, ob man Entwickler beschäftigt. Sie lautet: Gibt es im Unternehmen einen Server, auf dem eine Anwendung läuft, die wir selbst installiert haben? Und gibt es irgendwo ein Repository, einen Ordner mit Skripten oder ein Werkzeug, das jemand für uns gebaut hat? Zwei Mal Nein bedeutet Stufe eins. Ein Ja bedeutet, dass die kostenlose Code-Analyse etwas zu prüfen hat: Anbindung, Bestandsscan, priorisierter Befund, auf Wunsch in der eigenen Umgebung, ohne Verpflichtung. Der Befund sagt dann ehrlich, ob es sich gelohnt hat.
Häufig gestellte Fragen
Wir nutzen nur Cloud-Dienste. Was sollen wir scannen?
Nichts. Ohne eigenes Repository und ohne selbst betriebene Anwendung gibt es keinen Code anzubinden. Für Euch ist das Darknet-Monitoring der richtige Einstieg, weil das Risiko bei Zugangsdaten liegt, nicht im Code.
Unser ERP hat der Hersteller geliefert. Warum sollten wir es scannen?
Weil der Hersteller die Bibliotheken darin nicht auf Eurem Server aktualisiert und die Konfiguration nicht für Euch prüft. Genau diese beiden Dinge altern, und genau diese beiden Dinge prüft die Tiefenprüfung, ohne dass jemand eine Zeile schreibt.
Unsere Skripte sind nur intern. Ist das nicht harmlos?
Intern ist das Argument, mit dem Zugangsdaten in Skripte gelangen. Ein Angreifer, der einmal im Netz ist, liest interne Skripte zuerst, weil dort die Schlüssel zu allem anderen liegen. Wenn die Skripte in einem Repository liegen, findet der Scan sie.