Kunde verlangt Schwachstellenmanagement nach BSI — Was müssen wir in Deutschland konkret aufsetzen?

Viele kleinere Teams verfallen in Panik, sobald das Wort BSI fällt und wälzen hunderte Seiten Grundschutz-Kompendien. Dem Kunden geht es meistens gar nicht um das offizielle Zertifikat, sondern um einen Nachweis für die eigene Revision, dass der Dienstleister sauber arbeitet. Wenn im Vertrag keine explizite ISO 27001- oder BSI-Zertifizierung gefordert ist, reichen Verfahrensanweisung und Scan-Berichte völlig aus – schont auch das Budget.

Macht es euch technisch einfach: Bindet Dependency-Scanner in die CI/CD und einen Schwachstellen-Scanner auf Serverebene ein. Wenn ihr gefundene CVEs per Webhook direkt ins Ticketsystem ballert, muss der Admin keine manuellen Listen pflegen. BSI-Auditoren stürzen sich erfahrungsgemäß gerne auf vergessene Shadow-Systeme – schaut also, dass wirklich alle Subdomains und Testkisten im Scope sind.

Wir standen bei einem ÖPP-Projekt vor derselben Anforderung und haben uns einen Scanner für 2.200 EUR Jahreslizenz geholt. Setup hat 3 Wochen gedauert. Unser Admin checkt montags 2 Stunden lang die BSI- und CERT-Feeds und braucht monatlich rund 6 Stunden für den Audit-Report. Damit sind wir durch die letzten beiden Kundenaudits ohne Beanstandung durchgekommen.

Das Schnellste, was ihr morgen sofort machen könnt: 1) Schreibt eure Server- und Bibliotheksliste in eine klare Tabelle. 2) Abonniert den kostenlosen CERT-Bund E-Mail-Newsletter. 3) Schreibt eine zweiseitige Sicherheitsrichtlinie mit Patch-Fristen und lasst sie firmenintern unterschreiben. Wenn der Kunde zum Audit kommt, fragt er zuerst nach genau diesem Papier.

In München hatten wir bei einer ähnlichen Ausschreibung für Gesundheitssoftware genau dieselbe Anforderung. Beim ersten Audit fragten sie uns: "Wie schnell habt ihr eine kritische Kernel-Schwachstelle vom letzten Monat geschlossen, wo ist der Nachweis?" Wir hatten den Patch in 4 Stunden live, aber weil wir kein Ticket aufgemacht und keine Stunden erfasst haben, gab's eine Rüge. Der Trick liegt wirklich darin, sauber zu dokumentieren.

Verweist euer Kunde im Lastenheft direkt auf den BSI IT-Grundschutz Baustein OPS.1.1.3 (Patch- und Änderungsmanagement)? Wenn dieses Modul gefordert ist, müsst ihr das Change Management mit dem Patch-Freigabeprozess verknüpfen.

wir haben das ähnlich durchgemacht, baut automatische Schwachstellen-Check-Bots in euer Git-Repo ein. die sollen bei jedem Build die Bibliotheken scannen aber schon ein Flussdiagramm das zeigt dass ihr keinen Code live schubst bevor die Testumgebung grün ist reicht um den Kunden zu überzeugen.

Da euer Kunde mit dem öffentlichen Sektor verbunden ist, muss die BSI-Konformität im Subunternehmervertrag garantiert werden. In der Dokumentation, die ihr erstellt, müssen eine Verantwortlichkeitsmatrix (RACI), ein Notfall-Patch-Verfahren und die Zusage jährlicher externer Audits enthalten sein. Es ist essenziell, dass diese Dokumente von der Geschäftsleitung genehmigt wurden.

Hier muss man eine Unterscheidung treffen. Die Zeit, die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Das war's, entschuldige, wenn ich zu lang war.

Wie habt ihr das Problem gelöst? Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Entschuldigung, aber das gilt nicht in jedem Fall. Die meisten Vorfälle beginnen nicht mit einer Schwachstelle, sondern mit einem geleakten Passwort.

Viel Erfolg.

Ich habe mich lange damit beschäftigt. Wer bei bsi schwachstellenmanagement hetzt, stolpert alle an derselben Stelle.

Ich würde mich freuen, wenn du das Ergebnis postest. Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

Nur als Notiz, könnte nützlich sein.

Bleibe dran.

Da verstehe ich etwas nicht ganz. Ein automatisierter Scan-Report ist kein Penetrationstest.

Viel Erfolg.

Genau so ist es. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.

Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Die Diskussion ist abgeschweift ich fasse mal zusammen. Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

Die Antwort hängt stark von der Branche ab es gibt keine allgemeine Regel. Ich hoffe, das hilft dir weiter.

Da hast du recht... Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Ein automatisierter Scan-Report ist kein Penetrationstest. Wenn ihr das Ergebnis hier postet hilft es auch anderen.