CVE-Monitoring für SaaS und AI-gebaute Software, mit menschlicher Priorisierung
Automatische Scanner und Software Composition Analysis (SCA) melden jede bekannte Schwachstelle, aber nicht, welche davon das Produkt wirklich betrifft. Ich bewerte eingehende CVE-Alerts nach Schweregrad, Exploitability und Update-Pfad und mache klar, was produktionskritisch ist und was warten kann.
- Digest oder kritische Alerts
- Menschliche Priorisierung
- Repo + CVE + Infrastruktur
- Deutscher Ansprechpartner
Direkter Ansprechpartner
Timo Wevelsiep
Softwareentwickler, Cloud-Architekt, Gründer & Geschäftsführer
Ich prüfe Code, Security und Infrastruktur und mache sichtbar, was vor Launch, Kundeneinsatz oder Due Diligence technisch riskant ist.
Ich habe produktive Software-, Infrastruktur- und Cloud-Systeme für Kunden weltweit begleitet, darunter Europa, VAE, Asien, Australien und Amerika: von automatisierten Standortplattformen über Cloud-Migrationen bis zu Remote-Access-Systemen für Industrieanlagen.
Für Fragen wie:
- Ist dieser Release produktionsreif?
- Welche CVEs sind wirklich kritisch?
- Sind Auth, Datenzugriff und Tenant-Isolation sauber?
Warum automatische Scanner allein nicht reichen
Automatische Scanner sind ein guter Anfang, aber sie melden Schwachstellen, sie priorisieren sie nicht. Wer Dependabot Alerts einordnen will, braucht mehr als eine Liste. Genau dort entsteht das Problem:
Was ich bei jedem CVE bewerte
Ich nehme jeden Alert und lege die Faktoren daneben, die über die echte Dringlichkeit entscheiden. Daraus entsteht eine Priorisierung statt einer Liste:
| Faktor | Frage | Warum das zählt |
|---|---|---|
| Schweregrad (CVSS) | Wie schwer wäre der Schaden im Worst Case? | Erste grobe Einordnung, aber selten allein entscheidend |
| Exploitability (EPSS) | Wie wahrscheinlich wird die Lücke real ausgenutzt? | Trennt theoretisches Risiko von akuter Bedrohung |
| Betroffene Laufzeit | Ist der verwundbare Pfad in der App erreichbar? | Viele CVEs betreffen Code, der nie aufgerufen wird |
| Transitive Dependencies | Steckt die Lücke direkt im Paket oder tief im Baum? | Bestimmt, ob das Team selbst updaten kann oder warten muss |
| Update-Pfad | Gibt es eine sichere Version, und wie weit ist der Sprung? | Entscheidet, wie schnell ein Fix überhaupt möglich ist |
| Breaking-Change-Risiko | Bricht das Update die App? | Verhindert, dass der Fix mehr kaputt macht als die Lücke |
Kritische Alerts vs. monatlicher Digest
Nicht jeder CVE braucht einen Anruf, und nicht jede Schwachstelle darf einen Monat liegen bleiben. Deshalb trenne ich klar zwischen dem, was sofort eine Reaktion verlangt, und dem, was im ruhigen Rhythmus erledigt wird.
Kritische Alerts gehen zeitnah raus: eine aktiv ausgenutzte Lücke in einer erreichbaren Laufzeit kommt als Hinweis mit Kontext, betroffenem Pfad und einer konkreten Empfehlung, nicht als rohe Scanner-Meldung. So ist sofort klar, ob heute Handlungsbedarf besteht oder nicht.
Alles andere bündele ich im monatlichen Digest: niedrige und mittlere Funde, Pakete mit verfügbarem, aber unkritischem Update, und Hinweise auf Dependencies, die mittelfristig abgelöst werden sollten. Ein Report statt dutzender Einzelmeldungen, mit klarer Reihenfolge, was zuerst dran ist.
Verbindung zu Infrastructure Watch und Repo-Review
CVE-Monitoring ist kein isolierter Kanal, sondern Teil einer durchgehenden technischen Aufsicht. Eine Schwachstelle in einem Paket bewerte ich immer im Kontext der jeweiligen Infrastruktur und des Codes, nicht nur als Eintrag in einer Datenbank.
Über das Repo-Review weiß ich, welche Teile des Codes die verwundbare Funktion tatsächlich nutzen. Über Infrastructure Watch weiß ich, ob der betroffene Endpunkt öffentlich erreichbar ist, ob Rate Limiting greift und wie das Deployment aussieht. Erst dieser Kontext macht aus einem CVSS-Score eine belastbare Priorität. So geht reine Software Composition Analysis (SCA) in eine echte Priorisierung über.
Das ist der Unterschied zu reinem Dependency-Scanning: Statt einer Lücke isoliert eine Zahl zuzuweisen, ordne ich sie in das konkrete Setup ein, von der betroffenen Zeile bis zum offenen Port.
Beispiel: 17 Alerts, aber nur 2 produktionskritisch
Ein typischer Monat in einer AI-gebauten SaaS-App zeigt, warum die Zahl der Alerts wenig aussagt. Aus 17 Meldungen blieben nach der Bewertung zwei, die wirklich zählten:
- 9 Alerts betrafen Dev-Dependencies, die nie in Produktion laufen, kein Handlungsbedarf
- 4 Alerts lagen in transitiven Paketen, deren verwundbare Funktion der Code nie aufruft
- 2 Alerts hatten zwar hohen CVSS, aber EPSS nahe null und keinen bekannten Exploit
- 1 kritischer Alert: aktiv ausgenutzte Lücke in einer öffentlich erreichbaren Route, sofort gemeldet
- 1 wichtiger Alert: sicheres Update verfügbar, aber mit Breaking Change, im Digest mit Migrationshinweis
In welchem Paket steckt das CVE-Monitoring
CVE-Monitoring ist fester Bestandteil der laufenden Aufsicht. Die Tiefe richtet sich nach dem Paket, die Preise sind fest und transparent.
| Oversight 990 €/Mon | Guard 1.950 €/Mon | Launch 3.900 €/Mon | |
|---|---|---|---|
| CVE-Monitoring | Monatlicher Digest mit Priorisierung | Kritische Alerts zeitnah plus Digest | Kritische Alerts plus priorisierte Release-Bewertung |
| Reaktion | Gebündelt im monatlichen Report | Direkter Hinweis bei akuten Lücken | Begleitung vor jedem größeren Release |
| Kontext | Schweregrad und Update-Pfad | Plus Exploitability und betroffene Laufzeit | Plus Breaking-Change-Bewertung im Release-Plan |
| Sparring | Async, im Report-Rhythmus | Direkter Kanal für Rückfragen | Enger Austausch rund um Releases |
| Passt für | Apps mit ruhigem Änderungstempo | Produkte mit echten Nutzern | Teams kurz vor oder nach dem Launch |
So läuft CVE-Monitoring mit Veriploy ab
- 01
Dependency-Basis erfassen
Zuerst wird erfasst, welche Package Manager, Frameworks, Docker Images, GitHub Actions, Runtime-Umgebungen und kritischen Abhängigkeiten im Projekt genutzt werden.
- 02
Alert-Quellen einrichten oder prüfen
Dependabot, GitHub Security Alerts, npm-, pnpm- oder yarn-audit, Docker-Image-Scans oder andere vorhandene Quellen werden geprüft und in den Review-Prozess eingebunden.
- 03
CVEs einordnen
Nicht jede CVE ist für das Produkt gleich kritisch. Ich bewerte betroffene Komponente, Einsatzkontext, Exploitability, Update-Pfad und Breaking-Change-Risiko.
- 04
Digest und kritische Hinweise
Je nach Paket gibt es einen monatlichen Digest, kritische Hinweise per Mail oder priorisierte Rückmeldung bei Release- und Security-Fragen.
- 05
Entscheidung statt Alarmflut
Ziel ist nicht, möglichst viele Alerts zu sammeln, sondern klar zu entscheiden: sofort patchen, vor dem nächsten Release beheben, beobachten oder akzeptieren.
Viele Projekte starten mit einem Baseline-Review. Wird das Produkt danach weiter mit AI entwickelt, kann ich es laufend begleiten.
Was ich für den Review brauche
- Read-only-Zugriff auf das Repository
- Überblick über Package Manager, Stack und kritische Abhängigkeiten
- Infos zu Hosting, Deployment und Runtime-Umgebungen
- Zugang zu vorhandenen Alert-Quellen wie Dependabot oder Audit-Reports
- gewünschter Rhythmus für Digest und kritische Hinweise
- offene Fragen oder konkrete Sorgen zu bestimmten Paketen
Was der Review liefert
- verständliche Risikoampel je CVE
- Top-Risiken auf einen Blick
- priorisierte Findings nach echtem Risiko
- konkrete Handlungsempfehlungen pro Paket
- Einordnung: sofort patchen, vor dem nächsten Release beheben, beobachten oder akzeptieren
- passender Rhythmus aus monatlichem Digest und kritischen Hinweisen
So sieht ein Befund aus
CVE in der HTTP-Parser-Bibliothek, aktiv ausgenutzt (EPSS hoch), verwundbarer Pfad über eine öffentliche Route erreichbar. Empfehlung: sicheres Patch-Release sofort einspielen, danach Regressionstest auf der Route.
Roher Scanner-Alert oder priorisiertes Monitoring?
| Nur Scanner-Alert | Veriploy CVE-Monitoring | |
|---|---|---|
| Ergebnis | Liste aller bekannten Schwachstellen | Priorisierte Reihenfolge nach echtem Risiko |
| Exploitability | CVSS-Score ohne Kontext | CVSS plus EPSS und bekannte Exploits |
| Betroffene Laufzeit | Nicht berücksichtigt | Prüfung, ob der Pfad im jeweiligen Code erreichbar ist |
| Update-Pfad | Versionssprung ohne Bewertung | Sicheres Update plus Breaking-Change-Risiko |
| Reaktion | Alle Alerts gleich laut | Kritisch sofort, Rest gebündelt im Digest |
Häufige Fragen
Ersetzt das die bestehenden Scanner und Dependabot Alerts?
Nein, es baut darauf auf. Vorhandene Scanner dürfen weiter laufen und Schwachstellen melden. Ich nehme diese Alerts, bewerte sie nach Exploitability, betroffener Laufzeit und Update-Pfad und mache aus einer Liste eine Priorisierung. Die bestehenden Tools bleiben im Einsatz, ergänzt um eine menschliche Einordnung darüber.
Wie schnell kommt ein Hinweis bei einem kritischen CVE?
Bei akut ausgenutzten Lücken in einer erreichbaren Laufzeit kommt in Guard und Launch zeitnah ein Hinweis mit Kontext und konkreter Empfehlung. In Oversight laufen alle Funde im monatlichen Digest zusammen, weil dieses Paket auf ein ruhiges Änderungstempo ausgelegt ist.
Patcht ihr die CVEs auch selbst?
Im Abo nicht. Ich bewerte, priorisiere und erkläre den sicheren Update-Pfad samt Breaking-Change-Risiko. Die Umsetzung läuft über das interne Team oder separat über Wevelsiep Advisory bzw. WZ-IT. So bleibt das Monitoring unabhängig von der Umsetzung.
Was ist mit transitiven Dependencies?
Die schaue ich mir gezielt an. Viele Alerts liegen tief im Dependency-Baum in Paketen, die nicht direkt installiert wurden. Ich prüfe, ob die verwundbare Funktion über den eigenen Code überhaupt erreichbar ist und ob das Team selbst updaten kann oder auf ein Upstream-Release warten muss.
Wie hängt das mit Infrastructure Watch und Repo-Review zusammen?
Ein CVE bewerte ich nie isoliert. Über das Repo-Review weiß ich, welche Codepfade die verwundbare Funktion nutzen, über Infrastructure Watch, ob der betroffene Endpunkt öffentlich erreichbar ist. Erst dieser Kontext macht aus einem Score eine belastbare Priorität.
Was kostet das CVE-Monitoring?
Es ist Teil der laufenden Aufsicht. Oversight liefert den monatlichen Digest für 990 € pro Monat, Guard ergänzt zeitnahe kritische Alerts für 1.950 €, Launch fügt die priorisierte Release-Bewertung für 3.900 € pro Monat hinzu. Alle Preise netto zzgl. USt. Laufende Pakete starten mit 3 Monaten Mindestlaufzeit, danach monatlich kündbar, sofern nicht anders vereinbart.
- Infrastruktur-Audit für AI-gebaute Software, Deployment, Backups, Monitoring und Secrets prüfen lassen
- Repo Review Abo, regelmäßiger Senior-Blick auf Code, CVEs und Architektur
- Vibe Coding Security Audit, und laufende Kontrolle, wenn der Code weiterwächst
- AI Code Audit in Deutschland, Repo, Security, CVEs und Infrastruktur prüfen lassen
Erkennst du diese Risiken in der eigenen App?
Der AI-App Risiko-Self-Check ordnet Produktstatus, Stack, Auth, Datenzugriff, Infrastruktur, CVEs und deinen technischen Kenntnisstand ein und zeigt, ob ein Review sinnvoll ist.
CVE-Alerts einordnen lassen, statt sie nur zu zählen.
Starte mit Oversight für den Digest, oder Guard für zeitnahe kritische Alerts im passenden Paket.
Repo-Fit prüfen
Kurz das Projekt beschreiben.
Direkter Kontakt zu mir, kein anonymes Ticket-System. Ich melde mich mit einer ersten Einschätzung und dem passenden Einstieg.
Timo Wevelsiep
Softwareentwickler, Cloud-Architekt, Gründer & Geschäftsführer