CyberPulse: Wie wir das Vulnerability Management neu erfunden haben (weil der Standard-Kram nervt)
Es gibt Themen in der IT-Security, die sind so alt wie das Internet selbst, und trotzdem hat gefühlt niemand eine brauchbare Lösung dafür. Eines dieser Themen ist das leidige Vulnerability Management. Jeder predigt es, jeder kauft irgendwelche absurd teuren Enterprise-Suiten, und am Ende sitzen die Analysten doch wieder vor Excel-Tapeten, die aus CSV-Exporten generiert wurden, und weinen leise in ihren kalten Kaffee.
Warum? Weil die meisten kommerziellen Tools im Kern nur dumme CVE-Schleudern sind. Sie scannen ein Subnetz, werfen 5.000 Findings mit CVSS 9.8 über den Zaun und sagen: "Viel Spaß beim Patchen, du Lappen!" Dass 99% dieser Findings in der Praxis überhaupt nicht ausnutzbar sind, weil der entsprechende Port nach extern blockiert ist oder der Service nur lokal lauscht, interessiert die Tools nicht. Kontext ist für sie ein Fremdwort.
Und genau das ging mir massiv auf den Sack. Deshalb haben wir (also mein LLM-Agent und ich) CyberPulse gebaut. Eine komplett interne, auf unsere Bedürfnisse maßgeschneiderte Vulnerability Intelligence & Patch Management Plattform. Kein Bullshit, keine Lizenzkosten pro IP, sondern pure, technische Pragmatik, gepaart mit einer fetten Dosis Künstlicher Intelligenz.
In diesem Post nehme ich euch mit unter die Haube. Wir schauen uns die Architektur an, wie wir NVD, MSRC und Red Hat Daten korrelieren, warum EPSS der einzige Score ist, der noch zählt, und wie wir Google Gemini als "Sentinel" auf Security-RSS-Feeds losgelassen haben. Packt euch einen Kaffee (oder ein Bier), es wird extrem technisch.
1. Was zur Hölle ist CyberPulse?
CyberPulse ist im Kern ein Python-Biest. Es ist eine Desktop-Anwendung (gebaut mit PySide6), die aber gleichzeitig als Headless-Sync-Worker in einer CI-Pipeline und als zentraler Flask-basierter REST-Hub auf einem Server laufen kann.
Die Idee war simpel: Wir brauchen eine Single Source of Truth für unser Asset-Inventar und die darauf liegenden Schwachstellen. Aber nicht als dumme Tabelle, sondern intelligent angereichert. Das Tool muss:
1. Wissen, welche Software auf unseren Linux-Büchsen läuft.
2. In Echtzeit abgleichen, welche neuen CVEs für diesen Software-Stack publiziert wurden.
3. Den ganzen CVSS-Müll herausfiltern und durch echte Threat Intelligence (EPSS, CISA KEV) ersetzen.
4. Den Analysten per Knopfdruck erlauben, die Patches direkt über SSH auszurollen.
UX & Alert Fatigue (Die "Deep Space" Story)
Bevor wir in die Architektur abtauchen, noch ein Wort zur Desktop-App selbst. Warum bauen wir eine fette PySide6-GUI, wenn es auch eine Web-App getan hätte?
Weil Analysten an Alert Fatigue (Ermüdungserscheinungen durch zu viele Warnungen) leiden, wenn sie den ganzen Tag auf grelle Excel-Tabellen oder überladene Web-Dashboards starren. Wir haben CyberPulse strikt nach der "Deep Space" Aesthetic gebaut: Knallharter Dark Mode, minimaler Cognitive Load, keine blinkenden Ampeln, sondern eine extrem reduzierte visuelle Fokussierung auf das, was wirklich brennt (EPSS/KEV). Ein gutes Security-Tool muss verhindern, dass der Analyst durchdreht.
(Screenshot: Das CyberPulse Main Dashboard. Dark Mode only, versteht sich. "Deep Space" Aesthetic für minimalen Cognitive Load.)
2. Die Architektur: Keep it simple, stupid!
Wenn man sich heutzutage moderne Software-Architekturen ansieht, bekommt man oft das kalte Kotzen. Da wird für ein simples Tool direkt ein Kubernetes-Cluster mit Kafka-Streams, Redis-Cache und fünf Microservices hochgezogen, nur um ein paar Strings von A nach B zu schieben. Wir haben uns bei CyberPulse bewusst dagegen entschieden.
Tech Stack
- Backend & Core: Python 3.10+
- Frontend (GUI): PySide6 (Qt)
- Datenbank: SQLite (
vulnerabilities.db) - Server/Hub: Flask
- Remote Execution: Paramiko (SSH)
Die Datenbank: Pragmatismus siegt
Das Herzstück ist die database.py. Anstatt uns mit SQLAlchemy und Alembic-Migration-Scripts herumzuschlagen, die in kleinen Teams meist mehr Overhead als Nutzen bringen, machen wir das puristisch. Wir nutzen rohes SQLite.
Unsere Migrationsstrategie? Inline PRAGMA table_info Checks. Wenn die App startet, ruft der DatabaseManager ein _init_db() auf. Dort prüfen wir einfach, ob eine Spalte in der Tabelle existiert, und wenn nicht, jagen wir ein ALTER TABLE ... ADD COLUMN IF NOT EXISTS hinterher. Das ist idiotensicher, erfordert keine externen Migration-Tools und das Datenbank-File liegt als simple Datei im Projekt-Root.
Die Kern-Tabellen sind products, categories, findings, assets, sentinel_hits, ai_reports und patch_history. Keine Connection-Pools, sondern schlichtes sqlite3.connect() pro Request. Das reicht für unsere Lastanforderungen locker aus. Performance-Probleme? Bisher Fehlanzeige.
3. Asset Discovery & Vulnerability Correlation (Der Painpoint schlechthin)
Jetzt wird es spannend. Wie kommen die Daten ins System? Und vor allem: Warum ist das Matching von Schwachstellen auf Software-Pakete in der Praxis so ein absoluter Albtraum?
Der SyncWorker & Discovery Scanner
In scanner/worker.py sitzt unser SyncWorker. Das ist ein QObject, das auf einem dedizierten QThread läuft, damit die GUI beim Scannen nicht einfriert (Anfängerfehler Nr. 1 bei PySide-Apps).
Der Worker startet im ersten Schritt das Asset Discovery. Statt uns auf wackelige Agenten-Software zu verlassen, die auf jedem Zielsystem als Root laufen muss, machen wir das agentless:
Der DiscoveryScanner verbindet sich per SSH auf die hinterlegten Linux-Assets. Das passiert hochparallel in einem ThreadPoolExecutor mit bis zu 20 Workern. Auf der Zielmaschine führen wir native Befehle wie dpkg -l (Debian/Ubuntu) oder rpm -qa (RHEL/CentOS) aus.
Und ja, wir können auch Windows! Die Windows-Hölle bändigen wir per winrm – was ein komplett anderer Endgegner ist als ein simples dpkg, aber essenziell für ein vollständiges Inventar. Im Anschluss parsen wir den Raw-Output und bauen unser lokales SQLite-Inventar auf. Ein Cronjob stößt das jede Nacht an.
Eigener Code vs. Fremd-Code (Semgrep & Nuclei)
Wir patchen nicht nur fremde Ubuntu-Pakete. CyberPulse triggert während des Discovery-Prozesses auch aktive Scans gegen unsere eigenen Applikationen. Über Nuclei feuern wir DAST-Scans (Dynamic Application Security Testing) gegen identifizierte Web-Assets ab, und für den Quellcode parsen wir semgrep_results.json Files direkt in die SQLite-Datenbank. Damit schlagen wir die Brücke zwischen klassischem Infrastructure Vulnerability Management und Application Security (AppSec) – alles in einem einzigen Interface.
Die Provider: Bulk Fetching im Turbo-Modus
Parallel zum Asset Scan feuern wir unsere Provider ab. Wir ziehen Daten aus drei Hauptquellen:
* NVDProvider: Die NIST NVD REST API v2. Das Problem hier: Die NVD-Daten sind oft Tage oder Wochen hinterher. Wenn ein Zero-Day droppt, hört man bei NIST oft nur die Grillen zirpen.
* MSRCProvider: Für die Microsoft-Welt ziehen wir direkt den CVRF-Feed des Microsoft Security Response Centers.
* RHELProvider: Zieht die Red Hat Security Data API für Enterprise-Linux-Komponenten.
Die Findings werden flat in den RAM geladen (Corpus Pre-screening). Wir werfen für das lokale Matching einen ProcessPoolExecutor (Multi-Core Turbo) an, der die CPU-Kerne gnadenlos auslastet.
Die Normalisierungs-Hölle & Das CPE-Desaster
Die größte Herausforderung beim lokalen Matching ist die NVD Common Platform Enumeration (CPE). NVD nutzt ein absurdes Format (cpe:2.3:a:vendor:product:version:...), das absolut null mit der Realität von Linux-Paketmanagern übereinstimmt.
Beispiele gefällig?
Wenn du apt install apache2 machst, heißt das Paket apache2. Bei NVD heißt das Produkt aber http_server (Vendor: apache).
Installierst du Proxmox (pve-manager), sucht NVD nach virtual_environment.
Wir mussten ein hartcodiertes PRODUCT_ALIASES Dictionary bauen, das genau diesen Müll übersetzt. Aus gitlab-ce wird gitlab, aus nfs-kernel-server wird nfs-utils.
Und dann kommt das Version-Parsing. Debian ist hier das beste Negativbeispiel. Ein Paket heißt dort gerne mal 2:4.17.12+dfsg-0+deb12u3. Die 2: ist eine Epoch, das +deb12u3 der Distro-Patchlevel.
Wenn du diesen String 1:1 gegen die NIST CPE-Daten wirfst, kracht der Matcher sofort zusammen.
Unsere Funktion SyncWorker._normalize_version_string() nutzt exakt diese Regex:
r'^([0-9]+(\.[0-9]+)*([a-z][0-9]+)?)'
Damit rasieren wir den ganzen Debian-Epoch-Müll und die Distro-Suffixe rigoros weg. Aus 2:4.17.12+dfsg-0+deb12u3 wird ein sauberes 4.17.12. Das klingt banal, hat uns aber wochenlang Kopfschmerzen bereitet, bis wir die Heuristik dafür perfektioniert hatten.
VEX-Filter (Vulnerability Exploitability eXchange):
Um False-Positives noch weiter zu killen, checkt unsere Engine bei jedem Match: Hat Red Hat ein VEX-Statement für dieses Paket herausgegeben, in dem explizit steht not_affected (weil das vulnerable Modul im Build z.B. deaktiviert wurde)? Wenn ja, wird das Finding direkt und geräuschlos verworfen.
4. Threat Enrichment: Bye-bye CVSS, Hello EPSS & KEV
Ich habe es schon oft gesagt und ich sage es wieder: CVSS ist kaputt.
CVSS (Common Vulnerability Scoring System) bewertet die theoretische Schwere einer Lücke. Das führt dazu, dass jede zweite Lücke heutzutage ein "High" oder "Critical" ist, nur weil der theoretische Impact hoch wäre, selbst wenn die Lücke nur ausnutzbar ist, wenn der Angreifer physischen Zugang zum Gerät hat und dabei einen Handstand macht.
Wir nutzen CVSS nur noch als grobe Baseline. Die echte Priorisierung in CyberPulse passiert im ThreatEnricher (scanner/enricher.py), der zwei entscheidende Metriken an jedes Finding klatscht:
- CISA KEV (Known Exploited Vulnerabilities): Eine Liste der US-Behörde CISA mit Schwachstellen, die aktuell in freier Wildbahn aktiv ausgenutzt werden. Wenn ein Finding ein KEV-Flag hat, lassen wir alles stehen und liegen.
- EPSS (Exploit Prediction Scoring System): Ein wahrscheinlichkeitstheoretisches Modell (KI-basiert), das die Wahrscheinlichkeit (0 bis 100%) vorhersagt, dass diese Lücke in den nächsten 30 Tagen ausgenutzt wird.
Ein CVSS 9.8 mit einem EPSS von 0.01% kann warten. Ein CVSS 7.2 mit einem EPSS von 85% und einem KEV-Flag muss jetzt sofort gepatcht werden. Das ändert die Art und Weise, wie man Schwachstellen abarbeitet, fundamental. Man rennt nicht mehr blind jedem "Critical" hinterher, sondern priorisiert nach echten, empirischen Bedrohungen.
5. KI-Integration: Der Sentinel Agent & Strategic Reports
Da wir ohnehin schon Python im Stack hatten, war der Schritt zur KI-Integration extrem kurz. Wir nutzen direkt die REST-API von Google Gemini (utils/ai_providers.py), da wir den Context-Window (2 Millionen Tokens!) und die JSON-Output-Fähigkeiten lieben.
Der Sentinel Agent
Das coolste Feature in CyberPulse ist der SentinelAgent (scanner/sentinel_agent.py).
Anstatt dass wir jeden Morgen Security-Blogs lesen müssen, zieht der Sentinel-Agent im Hintergrund die RSS-Feeds der wichtigsten Outlets (BleepingComputer, The Hacker News, Heise Security, SANS ISC, CERT-Bund).
Er nimmt diese reinen Text-News und wirft sie Gemini in den Rachen. Der Prompt sagt Gemini vereinfacht: "Hier sind die Security-News der letzten 24 Stunden. Hier ist unsere Liste an Assets und eingesetzter Software. Identifiziere proaktiv, ob eine dieser News für unseren Tech-Stack relevant ist und generiere einen Alert."
Das LLM klassifiziert die Artikel und wirft uns ein sauberes JSON zurück, das direkt in der App als Benachrichtigung aufschlägt. Oft wissen wir dadurch von kritischen Lücken (wie bei Ivanti oder Palo Alto letztens), noch bevor NVD überhaupt einen CVE-Record angelegt hat.
Strategic AI Reports
Zusätzlich haben wir den AIAnalysisWorker. Wenn wir ein Reporting für das Management oder den CISO brauchen, markieren wir die kritischen Findings der Woche und lassen Gemini darüber laufen. Die KI schreibt uns einen Executive Summary Report, der nicht aus dumpfen CVE-Beschreibungen besteht, sondern den geschäftlichen Kontext und Angriffspfade (Vulnerability Chains) in plain German erklärt.
(Screenshot: Der Sentinel Agent im Einsatz. Oben die News-Feeds, unten die KI-generierten Alerts, die direkt auf unsere Assets matchen.)
6. Patch Management: Keine halben Sachen
Informationen sind schön und gut, aber irgendwann muss man das Zeug auch fixen. Standard-Tools generieren meist nur Tickets in Jira. Wir wollten einen Schritt weiter gehen.
In scanner/patcher.py lebt der RemotePatcher. Wenn ein Analyst in der GUI ein Asset auswählt, das verwundbare Pakete hat, kann er auf "Patch" klicken.
Was dann passiert, ist reine Magie:
1. Der Patcher verbindet sich via SSH (scanner/ssh.py wrapping paramiko).
2. Er erkennt dynamisch, ob die Kiste apt-get oder yum/dnf nutzt.
3. Er baut den Befehl zum exklusiven Update dieses einen spezifischen Pakets zusammen.
4. Wir handeln das sudo-Passwort komplett in-memory ab. Keine Credentials auf der Disk, kein Expect-Script-Schrott.
5. Der Patcher führt den Befehl aus, fängt stdout/stderr ab und loggt das Ergebnis revisionssicher in die patch_history Tabelle.
Natürlich haben wir einen dry_run=True Modus eingebaut. Das simuliert den Patch-Vorgang (apt-get install --dry-run ...), sodass man vorher sieht, ob der Patch einem den halben Kernel wegreißt, weil irgendwelche Dependencies durchdrehen.
7. Deployment: Headless & Hub-Offloading
Zuletzt noch zur Infrastruktur. Die Desktop-App ist super für den Analysten am Notebook, aber die Syncs und KI-Abfragen dauern ihre Zeit.
Deshalb haben wir das Konzept des Intelligence Hubs gebaut. Mit dem Skript ./scripts/deploy_nas.sh --full schieben wir CyberPulse auf unsere interne NAS (root@nas.fritz.box).
Dort installiert das Script einen systemd Service (cyberpulse-hub.service). Die App läuft dort als Flask-REST-API (python main.py --server). Ein täglicher Cronjob führt python main.py --sync aus.
Der Clou: Wenn ich die Desktop-App auf meinem Rechner starte, habe ich in den Settings das Flag enable_offloading gesetzt. Mein lokaler Client macht überhaupt keine NVD-Abfragen mehr! Der CentralProvider leitet alle Anfragen an die /findings REST-Endpunkte des NAS-Hubs weiter.
Die NAS rödelt nachts, zieht alle Daten, korreliert, jagt die Sentinel-KI drüber, und morgens öffnet der Analyst die Desktop-App, die sich in Millisekunden die fertigen Ergebnisse vom Hub-Server zieht. Perfekte Lastverteilung!
8. Data Privacy & Compliance (Der On-Premise Flex)
Ein massiver Punkt, den man leicht übersieht, wenn man sich von KI-Features blenden lässt: Datenschutz und Compliance.
Wir schießen zwar ab und zu anonymisierte News-Artikel gegen die Gemini-API, aber die eigentlichen Kronjuwelen – nämlich welches unserer internen Systeme welche kritische Lücke hat – verlassen niemals unser Haus.
Die vulnerabilities.db liegt rein lokal auf unserer NAS. Wenn du einen SaaS-Vendor nutzt, lädst du dein komplettes, verwundbares Netzwerk-Inventar in die US-Cloud eines Drittanbieters hoch. Ein einziger Breach dort, und die Hacker haben eine perfekte Roadmap in dein Netzwerk. Unser "Local-First"-Ansatz rettet uns bei ISO 27001- und DORA-Audits regelmäßig den Hintern.
9. The "Oops" Moments & Die harte Wahrheit über Kosten
Wer bis hierhin gelesen hat, denkt vielleicht, CyberPulse ist beim ersten Versuch fehlerfrei aus dem Compiler gefallen. Bullshit. Wir haben auf dem Weg massiv Lehrgeld gezahlt.
Die größten Fails?
* NVD Rate-Limiting: Am Anfang hat uns die NIST API alle 5 Minuten blockiert, weil unser SyncWorker zu aggressiv gezogen hat.
* SSH-Timeouts: Server, die in einem Zombie-State hängen, blockieren den ThreadPoolExecutor bis in die Unendlichkeit.
* LLM-Halluzinationen: In den frühen Versionen hat Gemini teilweise CVE-Ids erfunden ("CVE-2026-99999"), weil es unbedingt eine Lücke finden wollte. Wir mussten die Prompts hart an die Leine nehmen und Grounding einbauen.
Aber warum tun wir uns das an? Der ROI (Return on Investment).
Eine Enterprise-Lizenz von Tenable, Qualys oder Rapid7 für unsere Infrastruktur kostet schnell mal 100.000€ im Jahr – und liefert am Ende oft doch nur CVSS-Müll in Excel-Tabellen, der nicht zu unserem Workflow passt. CyberPulse kostet uns effektiv ein paar Cent am Tag für die Gemini REST API Aufrufe und etwas Python-Laufzeit auf der NAS. Wir sparen sechsstellige Summen und haben ein Tool, das genau das tut, was wir brauchen.
10. Zukunftsmusik & Erweiterungspotenzial: SBOMs, Container & Rollbacks
Kein System ist perfekt. Unser aktueller Discovery-Ansatz (dpkg -l und rpm -qa) hat einen großen blinden Fleck: Was passiert mit Software, die am OS-Paketmanager vorbei installiert wird?
Wenn ein Entwickler sich per pip install vulnerable-lib oder npm install -g crypto-miner etwas auf die Kiste zieht, taucht das in dpkg logischerweise nicht auf. Genauso wenig wie Standalone-Binaries, die per wget einfach nach /opt oder /usr/local/bin geworfen wurden.
Hier liegt unser erstes großes Erweiterungspotenzial für CyberPulse:
Wir wollen strikt agentless bleiben, weil wir uns keinen Ressourcen-fressenden Agenten-Zoo auf den Servern ans Bein binden wollen. Stattdessen werden wir den SSH-Discovery-Worker aufbohren:
Anstatt nur dpkg zu befragen, kann der Worker temporär eine statisch kompilierte SBOM-Binary (wie syft) nach /tmp schieben und ausführen. Damit lassen sich rekursiv Python-Venvs, Node_modules und nackte Binaries scannen, ohne einen permanenten Agenten installieren zu müssen. Die SBOM-Ergebnisse werden dann einfach über stdout zurück an den CyberPulse-Hub gepiped und dort in unser lokales Inventar gemerged. Pragmatisch, agentless, und brutal effektiv.
Der Endgegner: Vulnerability Chaining & Netzwerk-Kontext
Eine Schwachstelle isoliert zu betrachten, ist oft zu kurz gedacht. Ein CVSS 6.0 in einem obskuren Tool juckt niemanden – außer, der Service lauscht plötzlich auf 0.0.0.0 (also offen nach draußen) und auf demselben Server existiert eine scheinbar unbedeutende Local Privilege Escalation (LPE) in einem veralteten Skript. Kombiniert ein Angreifer diese beiden "Medium" Lücken, hat er plötzlich einen RCE-Angriffspfad mit vollen Root-Rechten. Das nennt man Vulnerability Chaining.
Um das zu erkennen, müssen wir CyberPulse mehr Kontext geben als nur die platte Paketliste. Unser Plan sieht vor, während des SSH-Scans den exakten Software-Stand und die aktiven Netzwerkverbindungen (z.B. durch ss -tulpen oder netstat) abzugreifen.
Wir mappen dann intern: Welcher laufende Prozess lauscht auf welchem Port? Welche konkrete Binary steckt hinter diesem Prozess? Ist diese Binary (oder eine geladene Library) verwundbar?
Diesen enorm angereicherten Kontext (Laufende Prozesse + Offene Ports + Gematchte CVEs) werfen wir dann unserem Gemini-Agenten vor. Das LLM kann so nicht nur stupide auf isolierte Lücken hinweisen, sondern aktiv Angriffspfade aufzeigen: "Achtung! Das ungepatchte Nginx-Modul auf Port 443 erlaubt Schreibzugriff auf /tmp, was wiederum ausreicht, um die LPE im internen Cronjob auszunutzen. Root-Takeover von außen in 2 Schritten!" Das ist echtes, risikobasiertes Vulnerability Management.
Container, Webhooks & The "Oh Shit" Button
Neben dem Chaining haben wir noch drei weitere Themen auf der Roadmap, die CyberPulse zur echten Enterprise-Waffe machen:
1. Container & Docker Scanning: Bisher ignorieren wir Container auf den Linux-Hosts. Zukünftig soll sich CyberPulse per SSH die laufenden Container greifen (docker ps) und direkt Trivy oder Grype im Container triggern, um die Layer zu durchleuchten.
2. Automatisierte Rollbacks (The "Oh Shit" Button): Unser RemotePatcher haut Updates live auf die Kisten. Wenn ein apt-Update den Kernel zerschießt, brennt der Baum. Wir wollen CyberPulse an die Proxmox/VMware-API anbinden: Vor dem Patch wird vollautomatisch ein VM-Snapshot gezogen. Wenn der Ping nach dem Reboot stirbt, wird der Snapshot automatisch zurückgerollt.
3. Zero-Trust Alerting: Wenn der Sentinel-Agent einen hochkritischen Exploit-Pfad oder einen 0-Day findet, soll das nicht nur still im Dashboard landen. Wir wollen Webhooks integrieren, die sofort in unseren SOC-Channel in Slack/Teams pushen.
11. Open Source? (Can I have it?)
Eigentlich hat mich noch niemand danach gefragt, aber ich sage es trotzdem schon mal proaktiv, bevor der Erste nach dem GitHub-Link sucht: Erstmal gar nicht.
Aktuell ist CyberPulse einfach viel zu tief mit unserer internen Asset-Struktur, unserem eigenen SOC-Workflow und unseren speziellen SSH-Keys verdrahtet. Es als generisches Open-Source-Projekt bereitzustellen, würde erfordern, den kompletten internen "Glue Code" wegzureißen und zu abstrahieren. Das ist ein Vollzeitjob, den ich mir momentan nicht ans Bein binde. Es bleibt also vorerst ein Internal Use Only Werkzeug, das uns einen massiven Vorteil im operativen Betrieb verschafft.
Aber hey: Sag niemals nie. Vielleicht packt mich irgendwann nochmal der Wahnsinn und ich refactore das Ding so weit, dass ich es auf die Allgemeinheit loslassen kann.
Fazit
CyberPulse ist das perfekte Beispiel dafür, was passiert, wenn man sich als Entwickler-Team nicht mehr mit aufgeblähtem Enterprise-Schrott abfinden will.
Mit ein paar tausend Zeilen Python, einer SQLite-Datenbank und geschickter KI-Integration haben wir ein Tool gebaut, das kommerziellen Suiten im sechsstelligen Bereich in Sachen Praxistauglichkeit um Längen überlegen ist.
Warum? Weil es unseren Workflow abbildet. Es zwingt uns nicht, unsere Prozesse an das Tool anzupassen, sondern das Tool passt sich an uns an. Es priorisiert nach EPSS/KEV statt nach dummen CVSS-Scores, es überwacht proaktiv Security-News mit LLMs und es patcht Server mit einem Klick.
Mehr kann man von pragmatischer Security eigentlich nicht erwarten.
Stay safe, patch your shit!
Transparency Note: Dieser Blogpost entstand mit massiver Unterstützung meines "Antigravity" Agenten (basierend auf Gemini). Das LLM hat den Quellcode von CyberPulse analysiert, die Architektur verstanden und den ersten Draft des Textes generiert. Ich habe die Struktur vorgegeben, das Framing übernommen und den Text am Ende noch mit dem nötigen Sarkasmus "Marco-Vibe" feingeschliffen. 🤖 ✍️