explained

Auditing background updaters with winget and nothing else

List installed apps, detect auto-updaters by behavior, and decide containment per package — using the package manager Microsoft ships.

ProofTune Project··5 min read
Explained illustration Explained

Get the inventory

terminal / powershell
winget list | Out-File "$env:USERPROFILE\Desktop\installed.txt"
# then the reverse view — who updates themselves outside the store pipeline:
Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
              'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run' -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty Property

The audit questions per entry

  • Does the app document its update channel? Vendor pdf page > silent ejector-seat exe > “update service” nobody admits on the website.
  • Does the updater need a Run entry? Any app that keeps itself current without launching every sign-in is showing you the better design already (per-user scheduled task, muted, or store pipeline).
  • What survives an app uninstall? Run autoclean via Autoruns before the app reaches your host; entries left afterward are by definition beacons after divorce.

Composite this with your startup export: the union is your sign-in attack-surface list, current and dated. Vendor updaters that document their values in public knowledge bases migrate from “suspicious” to “managed” the day an audit command prints the named key.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.