Drittanbieter-Apps unter Windows mit winget patchen

Der Grundlagenartikel zum Patching endet mit einer Warnung: Vieles, was Angreifer auf Windows-Endgeräten ausnutzen, ist nicht Windows. Browser, PDF-Reader, Java- und .NET-Laufzeitumgebungen, Archivwerkzeuge, VPN-Clients und Fernzugriffssoftware haben eigene Update-Mechanismen, eigene Release-Zyklen und oft überhaupt keine zentrale Verwaltung. Die Windows Update-Clientrichtlinien berühren sie nicht.

Dieser Leitfaden ist ein praktischer Ausgangspunkt für kleine und mittlere Umgebungen: herausfinden, was installiert ist, entscheiden, was am wichtigsten ist, und es mit vorhandenen Werkzeugen patchen, vor allem mit dem Windows-Paket-Manager (winget) und den Richtlinien für automatische Updates der Hersteller.

Schritt 1: inventarisieren, was installiert ist

Sie können nicht patchen, wovon Sie nichts wissen. Wenn Sie Microsoft Defender for Endpoint haben, ist dessen Softwareinventar (in Defender Vulnerability Management) die beste Quelle, weil es installierte Versionen CVEs zuordnet. Der Intune-Bericht Discovered apps und das Hardwareinventar von Configuration Manager sind gute Alternativen.

Ohne diese lesen Sie die Deinstallationsschlüssel aus, genau wie „Programme und Features“. Vermeiden Sie Get-CimInstance Win32_Product: Eine Abfrage dieser Klasse löst eine Konsistenzprüfung jedes MSI-Pakets aus und kann Reparaturen starten.

$paths = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
         'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName |
  Export-Csv "C:\Temp\apps-$env:COMPUTERNAME.csv" -NoTypeInformation

Benutzerbezogene Installationen (viele Browser, Kollaborationsclients und Entwicklerwerkzeuge) registrieren sich stattdessen unter HKCU und landen in %LOCALAPPDATA%. Sie entgehen computerweiten Inventaren und sind oft die ältesten Versionen auf dem Gerät. Prüfen Sie sie ebenfalls, oder blockieren Sie benutzerbezogene Installer mit App Control.

Auch winget kann anzeigen, was es erkennt und wofür es ein Update gibt:

winget upgrade --include-unknown

Schritt 2: nach Exposition priorisieren

Nicht jede Anwendung verdient dasselbe Tempo. Ein einfaches Drei-Stufen-Modell funktioniert:

Stufen Sie jeden Eintrag nach oben, sobald er im CISA-Katalog Known Exploited Vulnerabilities erscheint oder das Advisory des Herstellers eine aktive Ausnutzung meldet. Anwendungen der Stufe 1 verarbeiten den ganzen Tag nicht vertrauenswürdige Inhalte; genau dort findet Ausnutzung statt.

Schritt 3: Hersteller aktualisieren lassen, wo sie es gut machen

Das günstigste Patching ist das, das die Anwendung selbst erledigt. Schalten Sie für Stufe 1 den Updater des Herstellers ein und erzwingen Sie ein Neustartfenster, statt jedes Release neu zu paketieren:

• Microsoft Edge aktualisiert sich selbst über EdgeUpdate. Belassen Sie dessen Update-Richtlinien beim Standard (Updates erlaubt) und setzen Sie Notify a user that a browser restart is recommended or required (RelaunchNotification) mit einem Zeitraum für den Neustart. Details stehen im Leitfaden zur Edge-Härtung.
• Google Chrome hat entsprechende Richtlinien RelaunchNotification und RelaunchNotificationPeriod, und die Google-Update-Richtlinien steuern, ob Updates erlaubt sind. Verwenden Sie die ADMX-Vorlagen des Herstellers.
• Mozilla Firefox wird über seine Unternehmensrichtlinien (policies.json oder ADMX) verwaltet; stellen Sie sicher, dass DisableAppUpdate nicht gesetzt ist.
• .NET-Laufzeitumgebungen werden über Microsoft Update gewartet, wenn Geräte Updates für andere Microsoft-Produkte erhalten dürfen. In Intune-Update-Ringen heißt das Microsoft product updates, in der Gruppenrichtlinie ist es die Option „Install updates for other Microsoft products“ von Configure Automatic Updates.

Prüfen Sie, was der Updater des Herstellers tut, wenn der Benutzer keine Administratorrechte hat. Manche Updater installieren einen computerweiten Dienst, der für alle funktioniert; andere scheitern bei Standardbenutzern stillschweigend, und genau das sollen nach dem Entfernen lokaler Administratorrechte alle sein.

Schritt 4: Lücken mit winget füllen

Für Anwendungen ohne zuverlässigen eigenen Updater kann winget Updates aus seinem Repository erkennen und installieren. Die interaktive Nutzung ist einfach:

winget upgrade                                  # verfügbare Upgrades auflisten
winget upgrade --id 7zip.7zip --silent --accept-package-agreements --accept-source-agreements
winget pin add --id Oracle.JavaRuntimeEnvironment   # eine App ausnehmen, die auf einer Version bleiben muss

Für den Einsatz in der Flotte führen Sie es als SYSTEM aus einer geplanten Aufgabe, einer Intune-Remediation oder Ihrem RMM aus. winget ist Teil des App-Installer-Pakets und liegt nicht im PATH des SYSTEM-Kontos, daher lösen Sie die ausführbare Datei zuerst auf:

$winget = Resolve-Path "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe" |
  Sort-Object Path | Select-Object -Last 1 -ExpandProperty Path

$approved = 'Google.Chrome', 'Mozilla.Firefox', '7zip.7zip', 'Adobe.Acrobat.Reader.64-bit'
foreach ($id in $approved) {
  & $winget upgrade --id $id --exact --silent --scope machine `
    --accept-package-agreements --accept-source-agreements --disable-interactivity
}

Verwenden Sie eine explizite Liste zugelassener IDs statt winget upgrade --all. --all aktualisiert alles, was winget zufällig erkennt, einschließlich Apps, deren neue Hauptversion Sie nicht getestet haben. Das PowerShell-Modul Microsoft.WinGet.Client (Get-WinGetPackage, Update-WinGetPackage) liefert strukturierte Ausgaben, wenn Sie Objekte dem Parsen von Text vorziehen.

Größere Umgebungen steigen meist auf ein dediziertes Werkzeug um: Intune Enterprise App Management (eine Funktion der Intune Suite, seit Juli 2026 in Microsoft 365 E5 enthalten), Kataloge für Softwareupdates von Drittanbietern in Configuration Manager oder ein kommerzielles Patchprodukt. Die Schritte zur Priorisierung und Überprüfung bleiben dieselben.

Schritt 5: App Installer und winget absichern

winget ist auch ein Installationskanal; steuern Sie ihn daher mit den App-Installer-Richtlinien unter Computer Configuration > Policies > Administrative Templates > Windows Components > Desktop App Installer (Registrierung: HKLM\SOFTWARE\Policies\Microsoft\Windows\AppInstaller):

Diese Namen entsprechen der aktuellen DesktopAppInstaller.admx, und Intune bietet dieselben Einstellungen im Bereich DesktopAppInstaller des Policy CSP. Älteren Vorlagen fehlen einige davon; verwenden Sie daher die neueste. Auf Geräten, auf denen Standardbenutzer überhaupt keine Software installieren sollen, ist App Control oder AppLocker die eigentliche Schutzmaßnahme; die winget-Richtlinie verengt nur einen Weg.

Schritt 6: entfernen, was sich nicht patchen lässt

Jede entfernte Anwendung ist ein Update-Strom weniger. Sobald das Inventar steht, sortieren Sie es nach Verantwortlichem und letzter Nutzung und hinterfragen alles, dem eines von beidem fehlt:

• Nicht unterstützte Versionen: Software jenseits des Lebensendes beim Hersteller (alte Java-8-Builds ohne Supportvertrag, alte Adobe-Reader-Versionen, Python 2, verwaiste Plug-ins) erhält überhaupt keine Korrekturen mehr. Ersetzen oder deinstallieren.
• Duplikate: Drei PDF-Reader oder zwei Archivwerkzeuge auf demselben Gerät verdreifachen die Angriffsfläche ohne Nutzen. Standardisieren Sie auf eines pro Funktion.
• Fernzugriffswerkzeuge, die die IT nicht installiert hat (AnyDesk, TeamViewer und ähnliche), sind sowohl ein Patchproblem als auch eine häufige Persistenzmethode von Angreifern. Entfernen Sie sie und blockieren Sie sie per Anwendungssteuerung.
• Browsererweiterungen und Laufzeitumgebungen, die mit alten Fachanwendungen gebündelt sind. Fragen Sie den Hersteller nach einer unterstützten Version und isolieren Sie die App, falls es keine gibt.

Deinstallieren Sie mit dem stillen Deinstallationsprogramm des Herstellers oder winget uninstall --id <id> --silent und dokumentieren Sie jede Entfernung. Entfernen ist auch die Antwort für Software, die überhaupt keinen stillen Update-Pfad hat.

Überprüfung

Führen Sie das Inventar erneut aus und vergleichen Sie die Versionen mit dem aktuellen Release des Herstellers. Auf einem einzelnen Gerät:

winget upgrade --include-unknown           # sollte nichts aus Ihrer zugelassenen Liste anzeigen

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=1033,11707} -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

MSI-basierte Installationen protokollieren im Anwendungsprotokoll unter der Quelle MsiInstaller Ereignis 11707 (Installation erfolgreich abgeschlossen) und 1033 (Produkt installiert, mit Status). Die eigenen Logs von winget liegen unter %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir für das ausführende Konto (für SYSTEM im Ordner systemprofile).

Verfolgen Sie auf Flottenebene den Anteil der Geräte auf der aktuellen Version jeder Stufe-1-Anwendung und die älteste noch vorhandene Version. Die älteste Version ist die, die ein Angreifer finden wird.

Was kaputtgeht

• Updates, die einen Neustart der App erfordern. Browser laden herunter, wenden das Update aber erst beim Neustart an; ohne Neustartbenachrichtigungen laufen „aktualisierte“ Geräte wochenlang mit der alten Binärdatei.
• Sprünge bei Hauptversionen. Java, PDF-Editoren und Plug-ins für Fachanwendungen können bei Hauptversionen brechen. Fixieren Sie diese und testen Sie.
• Benutzer- und Computerinstallationen nebeneinander. Ein computerweites Update lässt eine ältere benutzerbezogene Kopie unberührt, und der Benutzer startet weiterhin diese.
• winget als SYSTEM erreicht keine Pakete aus der Microsoft-Store-Quelle und scheitert an manchen benutzerbezogenen Installern. Erkennen Sie diese und behandeln Sie sie gesondert.

Checkliste

• Softwareinventar über Computer- und benutzerbezogene Installationen
• Stufe-1-Anwendungen mit Patchzielen in Tagen identifiziert
• Automatische Updates der Hersteller aktiviert und Neustartbenachrichtigungen für Browser erzwungen
• .NET und andere Microsoft-Produkte erhalten Updates über Microsoft Update
• winget (oder ein Patchwerkzeug) aktualisiert eine zugelassene Liste als SYSTEM
• App-Installer-Richtlinien: kein Hash Override, keine lokalen Manifeste, nur zugelassene Quellen
• Software ohne Verantwortlichen und ohne Support entfernt
• Bericht zur ältesten Version pro Stufe-1-Anwendung monatlich geprüft

Das Patchen von Drittanbietersoftware schließt die größte Lücke, die Windows Update hinterlässt. Für die Microsoft-Seite des Prozesses siehe Windows Update-Richtlinien und den übrigen Bereich Patches und Updates.