Schwachstellenmanagement

Übersicht der abonnierten Sicherheitswarnungen (CERT-Meldungen und Hersteller-Advisories) und wie mit eingehenden Meldungen umgegangen wird.

Pflege

Jede neue Komponente im Stack (Server, Software, Library) braucht eine Advisory-Quelle in dieser Liste. Ändert sich ein Empfänger oder Verteiler, diese Seite aktualisieren.

CERT-Meldungen

Quelle Kanal Filter / Umfang Empfänger Status
CERT-Bund WID (BSI) E-Mail-Benachrichtigung (Portal-Konto) Produkte: PHP, Apache, MySQL/MariaDB, Plesk, Linux, GitLab · Risiko ab mittel security-alerts@ids-edv.de TODO
BSI Bürger-CERT Abos E-Mail-Newsletter Cybersicherheits-Newsletter und Sicherheitshinweise des BSI security-alerts@ids-edv.de Abonniert

Hersteller-Advisories

Komponente Quelle Kanal Empfänger Status
PHP php-src Security Advisories GitHub Watch (Security alerts) security-alerts@ids-edv.de TODO
PHP php.net Announcements Mailingliste php-announce@lists.php.net (Anmeldung per E-Mail an php-announce+subscribe@lists.php.net) security-alerts@ids-edv.de Abonniert
Apache httpd Apache 2.4 Vulnerabilities Mailingliste announce@httpd.apache.org security-alerts@ids-edv.de Abonniert
Plesk Plesk Security Advisories / Release Notes Plesk-Newsletter, Panel-Benachrichtigungen security-alerts@ids-edv.de TODO
MySQL Oracle Critical Patch Updates E-Mail (quartalsweise, Jan/Apr/Jul/Okt) security-alerts@ids-edv.de Abonniert
MariaDB MariaDB Security / Release Notes Mailingliste announce security-alerts@ids-edv.de Abonniert
Ubuntu Security Announcements Distribution Security Announcements (DSA / USN) Mailingliste security-alerts@ids-edv.de Abonniert
GitLab Communication Preference Center GitLab Security Communication (Patch/Security Releases) Security-Newsletter security-alerts@ids-edv.de Angefordert
IONOS IONOS Kundenbereich E-Mail an Vertragskontakt j.voegele@ids-edv.de Abonniert

Composer-Libraries

Composer-Abhängigkeiten werden nicht einzeln abonniert, sondern geprüft:

composer audit --no-dev

Updates siehe Library Updates.

Ablauf bei einer Meldung

  1. Betroffenheit prüfen: Läuft die Komponente/Version bei uns? Welche Server und Apps?
  2. Einstufen: nach Alerts Subjects
    • 🔴 Kritisch: aktiv ausgenutzt oder remote ohne Authentifizierung ausnutzbar → sofort patchen bzw. mitigieren
    • 🟡 Warnung: hohes Risiko, nicht direkt erreichbar → innerhalb weniger Tage
    • 🔵 Prüfen: mittleres/niedriges Risiko → mit dem nächsten regulären Update
    • 🟢 Info: nicht betroffen → nur dokumentieren
  3. Umsetzen: Patch, Update oder temporäre Mitigation (z. B. Modul deaktivieren, .htaccess-Sperre).
  4. Dokumentieren: Meldung, Entscheidung und Datum im zugehörigen GitLab-Issue festhalten.