Wüssten Sie heute, ob Ihre Website eine verwundbare Abhängigkeit nutzt?
Warum npm audit allein keine Lieferkettenstrategie ist – und wie Lockfiles, Dependency Review und ein schlankes SBOM-Inventar die Reaktionszeit verkürzen.
Eine neue Sicherheitslücke wird veröffentlicht. Ihr Kunde fragt: Sind wir betroffen?
Wie lange brauchen Sie für eine belastbare Antwort? Fünf Minuten, einen halben Tag – oder erst einmal den Entwickler, der das Projekt vor zwei Jahren aufgesetzt hat?
Moderne Websites bestehen nicht nur aus dem Code, den Ihr Team selbst geschrieben hat. Frameworks, Build-Tools, CMS-Erweiterungen, SDKs, Container-Basisimages und transitive Pakete bilden eine Lieferkette. Wenn niemand weiß, was tatsächlich produktiv eingesetzt wird, wird aus einer einfachen Sicherheitsfrage schnell eine Inventur unter Zeitdruck.
Der Mythos: „Wir haben doch npm audit“
npm audit ist nützlich. Es gleicht Abhängigkeiten mit bekannten Schwachstellen ab und kann konkrete Hinweise liefern. Aber ein Audit-Befehl beantwortet nicht automatisch die wichtigsten Betriebsfragen:
- Welche Version ist wirklich produktiv deployt?
- Ist das betroffene Paket nur im Entwicklungsprozess oder im ausgelieferten Produkt enthalten?
- Gibt es mehrere Anwendungen mit unterschiedlichen Lockfiles?
- Läuft zusätzlich ein verwundbares Systempaket im Container?
- Wer bewertet, ob ein Fund tatsächlich ausnutzbar ist?
- Wie wird dokumentiert, warum ein Update verschoben wurde?
Ein Scanner ist ein Signalgeber. Er ersetzt weder ein Inventar noch einen Entscheidungsprozess.
Lockfile vorhanden – Problem gelöst?
Ein gepflegtes Lockfile ist wichtig, weil es reproduzierbare Versionen dokumentiert. Trotzdem entstehen blinde Flecken:
- Das Lockfile wurde geändert, aber die Produktion läuft noch mit einem alten Build.
- Mehrere Paketmanager oder Workspaces werden nicht vollständig erfasst.
- Container- und Betriebssystempakete fehlen.
- Dynamisch geladene Skripte, Plugins oder CDN-Ressourcen stehen nicht darin.
- Ein Update entfernt eine Schwachstelle, führt aber unbemerkt eine neue transitive Abhängigkeit ein.
Die entscheidende Einheit ist daher nicht nur das Repository, sondern das konkrete ausgelieferte Artefakt.
Was ein schlankes Dependency-Inventar leisten sollte
Sie brauchen nicht sofort ein schweres Enterprise-Programm. Für viele Website- und SaaS-Teams reicht ein kleiner, automatisierter Prozess:
- Lockfiles verbindlich versionieren. Builds ohne erwartetes Lockfile sollten scheitern.
- Änderungen an Abhängigkeiten im Pull Request sichtbar machen. GitHubs Dependency Review kann neu eingeführte oder geänderte Abhängigkeiten und bekannte Schwachstellen im Änderungsprozess anzeigen.
- Beim Release ein maschinenlesbares Inventar erzeugen. Ein Software Bill of Materials, kurz SBOM, erfasst Komponenten und Beziehungen in einem standardisierten Format. CISA beschreibt SBOMs als Baustein für Transparenz in der Software-Lieferkette.
- Artefakt und Inventar verbinden. Speichern Sie Release-ID, Commit, Image-Digest und SBOM gemeinsam.
- Funde priorisieren. Schweregrad allein reicht nicht. Berücksichtigen Sie Erreichbarkeit, öffentliche Exposition, verfügbare Exploits und vorhandene Schutzmaßnahmen.
- Ausnahmen mit Ablaufdatum dokumentieren. „Später aktualisieren“ ist kein Plan, wenn niemand zuständig ist.
Schnelltest: Wie incident-ready ist Ihr Projekt?
Beantworten Sie diese Fragen für Ihre wichtigste Website oder Anwendung:
- Können Sie die produktive Version einem Commit und Build zuordnen?
- Wissen Sie, welches Lockfile für diesen Build verwendet wurde?
- Werden neue Abhängigkeiten im Review sichtbar geprüft?
- Erfassen Sie direkte und transitive Pakete?
- Werden Container- und Systemkomponenten ebenfalls berücksichtigt?
- Können Sie nach einem CVE-Namen oder Paket suchen und betroffene Deployments finden?
- Gibt es eine verantwortliche Person und eine Reaktionsfrist?
- Wird nach dem Update geprüft, ob die Schwachstelle im ausgelieferten Artefakt wirklich verschwunden ist?
Wenn mehrere Antworten „nein“ lauten, fehlt Ihnen nicht zwingend ein weiteres Security-Tool. Wahrscheinlich fehlt zuerst die Verbindung zwischen Quellcode, Build, Deployment und Verantwortlichkeit.
Was Website-Pflichtencheck prüfen würde
Ein technischer Lieferketten-Check betrachtet nicht nur die Anzahl roter Warnungen. Wir prüfen unter anderem Lockfile-Disziplin, Update-Prozesse, Dependency Review, Build-Reproduzierbarkeit, Container-Basisimages, Release-Zuordnung, Scanner-Konfiguration, Ausnahmeprozesse und die Frage, ob ein Fund bis zum produktiven System verfolgt werden kann.
Das ist besonders relevant nach einem Agenturwechsel, bei älteren Projekten, nach einer Framework-Migration oder wenn mehrere Websites dieselben internen Pakete und Images verwenden.
Die entscheidende Frage ist nicht, ob Ihre Software Abhängigkeiten hat. Sie lautet, ob Sie diese im Ernstfall schnell genug finden und bewerten können. Wenn die Antwort heute noch von Erinnerung und Handarbeit abhängt, lohnt sich ein strukturierter Website- und Lieferkettencheck, bevor die nächste kritische Meldung den Zeitplan bestimmt.