Plugins aktuell halten und auf Schwachstellen achten
Beobachten Sie die Pakete, die Sie verwenden, wählen Sie, wie Sie informiert werden, überlassen Sie das Beobachten Ihrer composer.lock und reagieren Sie auf Sicherheitsmeldungen, bevor Schwachstellen Ihre Websites erreichen.
Über diese Anleitung
- Schwierigkeit
- Einsteiger
- Zeitaufwand
- 15 Minuten
- Lesezeit
- 4 Min. Lesezeit
Voraussetzungen
- Ein MeteorGPL-Konto
- Ein Projekt, das Pakete von MeteorGPL installiert, und seine
composer.lock
In dieser Anleitung
Ein Plugin zu installieren ist der einfache Teil. Zu wissen, wann es ein Update braucht, und vor allem ein Sicherheitsupdate, ist die Arbeit, die nie aufhört. MeteorGPL hat dafür vier Werkzeuge: das Beobachten von Paketen, Benachrichtigungen, das Abhängigkeits-Dashboard und Sicherheitsmeldungen zu Schwachstellen. Diese Anleitung richtet sie in dieser Reihenfolge ein und zeigt dann, wie Sie aktualisieren.
Schritt 1 — Die Pakete beobachten, die Sie verwenden
Jede Paketseite hat ein Beobachten-Menü, wie auf GitHub:
| Auswahl | Sie werden informiert über |
|---|---|
| Alle Aktivitäten | Neue Versionen, Sicherheitshinweise und Rückzüge |
| Releases | Neue Versionen (und Rückzüge) |
| Sicherheitswarnungen | Sicherheitshinweise (und Rückzüge) |
| Benutzerdefiniert | Die Ereignisse, die Sie auswählen |
| Ignorieren | Nichts zu diesem Paket |
Wenn Sie ein Paket mit Stern markieren, beobachten Sie es auch auf Releases; das können Sie in Ihren Benachrichtigungseinstellungen ausschalten. Einstellungen → Beobachtet listet jedes Paket auf, das Sie beobachten.
Schritt 2 — Wählen, wie Sie informiert werden
Unter Einstellungen → Benachrichtigungen wählen Sie für jede Art von Ereignis, ob es Sie in der App, als Push-Benachrichtigung oder per E-Mail erreicht. Ab Werk gilt:
- Neue Versionen erreichen Sie in der App und per E-Mail.
- Sicherheitshinweise erreichen Sie in der App, per Push und per E-Mail.
- Rückzüge erreichen Sie in der App und per E-Mail.
Eine wöchentliche Zusammenfassung dessen, was sich in Ihren mit Stern markierten Paketen geändert hat, gibt es ebenfalls; sie bleibt ausgeschaltet, bis Sie sie einschalten. Push-Benachrichtigungen werden pro Browser eingeschaltet, auf derselben Seite.
Schritt 3 — Die Lock-Datei beobachten lassen
Paket für Paket zu beobachten funktioniert bei einigen wenigen Plugins. Für eine ganze Website lassen Sie die Lock-Datei für sie sprechen: Erstellen Sie ein Projekt unter Einstellungen → Projekte und laden Sie die composer.lock der Website hoch, von Hand oder aus Ihrer Pipeline (siehe Composer-Tokens in CI).
Die Projektseite zeigt jedes Paket aus dem Repository als:
- aktuell,
- veraltet, mit den Changelog-Einträgen, die Ihnen fehlen,
- zurückgezogen oder
- per Takedown entfernt.
Bei Ihren persönlichen Projekten können die Pakete aus der Lock-Datei automatisch auf neue Versionen beobachtet werden: Aktivieren Sie auf der Projektseite Neue Versionen dieser Pakete beobachten. Laden Sie die Lock-Datei nach jedem Deployment erneut hoch, und das Dashboard folgt dem, was tatsächlich läuft.
Schritt 4 — Auf Sicherheitsmeldungen zu Schwachstellen reagieren
Veröffentlichte Schwachstellen in WordPress-Plugins und -Themes aus dem Schwachstellen-Feed von Wordfence Intelligence werden mit dem Katalog abgeglichen. Jeder Treffer erscheint:
- auf der Seite Sicherheitshinweise, die auch einen Atom-Feed hat;
- im Abschnitt Bekannte Schwachstellen des Tabs Sicherheit des betroffenen Pakets, mit den betroffenen Versionen und, sofern es sie gibt, der Version, die die Schwachstelle behebt, samt der
composer require-Zeile, um sie zu installieren; - als Sicherheitsbenachrichtigung für die Personen, die das Paket beobachten oder eine betroffene Version einsetzen.
Sicherheitsmeldungen, die in den letzten 30 Tagen veröffentlicht wurden, alarmieren Beobachter und bekannte Installationen sofort. Ältere alarmieren Sie, sobald Sie später eine betroffene Version herunterladen oder eine Lock-Datei mit einer betroffenen Version hochladen, sodass eine vergessene Website trotzdem markiert wird, wenn ihre Lock-Datei das nächste Mal eintrifft.
Bevor eine Version veröffentlicht wird, wird sie bereinigt, mit dem eigenen Lizenzcode des Anbieters verglichen, mit ClamAV und Musterregeln gescannt und gelintet; eine Version, die durchfällt, wird nicht veröffentlicht, und der Tab Sicherheit zeigt die Prüfungen. Wird später ein Problem gefunden, wird die Version zurückgezogen, Beobachter werden informiert, und Webhooks werden ausgelöst.
Schritt 5 — Aktualisieren
Lassen Sie auflisten, was neuere Versionen hat, und aktualisieren Sie dann ein Paket oder alle innerhalb Ihrer Versionsbeschränkungen:
composer outdated "meteorgpl-plugin/*"
composer update meteorgpl-plugin/elementor-pro
Testen Sie die Website, committen Sie die neue composer.lock und deployen Sie mit composer install. Jede veröffentlichte Version bleibt verfügbar; verhält sich ein Update also falsch, ist der Weg zurück ein einziger Befehl:
composer require meteorgpl-plugin/elementor-pro:3.20.0
Schritt 6 — Mit Webhooks und Feeds automatisieren
Webhooks (Einstellungen → Webhooks) senden einen POST, wenn ein Paket Ihrer Wahl eine neue Version erhält, ein Sicherheitshinweis herausgeht oder ein Paket zurückgezogen wird: signiertes JSON oder eine fertige Nachricht für Slack oder Discord. Prüfen Sie JSON-Zustellungen anhand des Headers X-MeteorGPL-Signature, des HMAC-SHA256 des Bodys mit dem Secret Ihres Webhooks. Ein JSON-Webhook kann einen Workflow starten, zum Beispiel einen, der composer update ausführt und einen Pull Request öffnet.
Atom-Feeds brauchen kein Konto: Jedes Paket hat einen für seine Releases (auf seiner Seite), jeder Anbieter hat einen, und https://meteorgpl.ddev.site/releases.atom enthält jede neue Version im Repository.
