Make a list, check it twice: keeping your PC's software up to date with an AI assistant

1Why a list

You can't update what you've forgotten you have. A PC that's a few years old usually carries dozens of programs nobody thinks about: a PDF library a script uses, a command-line tool installed for one project, a database left running in the background. Windows Update doesn't touch most of them, and many never tell you a new version exists.

With a list, the job becomes mechanical: for each line, what's installed, what's current, and is anything known to be wrong with what's installed? That's exactly the kind of repetitive, look-it-up work an AI assistant is good at. By the end you have:

• An inventory of every program and tool, with where its updates and security notices are published.
• A dated report each month: updates available, advisories that affect you, known vulnerabilities, anything that changed unexpectedly.
• A clear split of work: the updates the assistant applies itself, and the ones that need you at the keyboard.
• A watch list of risks you've chosen to live with, so they're revisited rather than forgotten.

2Make the list

Keep it as a JSON file the assistant can read and update, and have it produce a plain readable version for you. Each entry records enough to check the program without guessing:

[
  { "name": "gh", "version": "v2.40.0", "source": "https://github.com/cli/cli",
    "launcher": "D:\\Tools\\bin\\gh.cmd", "sha256": "…" },
  { "name": "wrangler", "version": "4.20.0", "check": "npm", "package": "wrangler" },
  { "name": "pypdf", "version": "4.3.1", "check": "pypi", "package": "pypdf" },
  { "name": "duckdb", "version": "v1.5.2", "source": "https://github.com/duckdb/duckdb",
    "hold": "extensions not ready for 2.x" },
  { "name": "ffmpeg", "version": "7.1", "check": "manual",
    "update_source": "https://ffmpeg.org/download.html" }
]

Two parts: what the assistant installed, and everything else

Tools the assistant installs get full entries automatically (the PC clean-up guide has a script that writes them). Programs that were already on the PC, such as office suites, drivers, a UPS agent or virtualization software, go in a second section. Nobody needs to manage those through the list; they're there so they get checked. Start the list from a snapshot of Settings > Apps, then have the assistant fill in where each program publishes updates.

3Where to check

No single source covers everything. These are free, need no account for normal use, and between them cover most of what's on a typical PC:

The assistant's real value here is the long tail. Looking up five programs by hand is fine; looking up sixty every month is the kind of chore people quietly stop doing. An assistant does it in minutes and doesn't get bored.

4Check it

Check-Updates.ps1 reads the list and, for each entry, finds the latest version, lists GitHub security advisories and flags any fixed in a version newer than yours, asks OSV.dev about the exact npm or PyPI version you have, and checks the program's fingerprint. It writes a dated report and changes nothing.

.\Check-Updates.ps1 -ToolsRoot D:\Tools

On a test list with deliberately old versions, the summary line and part of the report looked like this:

4 update(s), 37 advisory(ies) affecting installed versions,
63 known vulnerability(ies), 1 integrity warning(s), 1 to check by hand

## Security advisories affecting installed versions (GitHub)
| Tool | Count | Worst | Update to at least |
| gh   | 16    | high  | 2.102.0            |
| jq   | 20    | high  | 1.8.2              |

## Known vulnerabilities in installed versions (OSV)
| Tool     | Count | Update to at least |
| pypdf    | 61    | 6.21.2             |
| wrangler | 2     | 4.59.1             |

## Integrity
- gh: program file CHANGED but the inventory version did not.

Findings are grouped per tool, with the version that fixes all of them, because the useful question is "what do I update to", not "how many entries are there". A PDF library several major versions behind can easily have sixty known problems, and every one is fixed by the same update.

Then let the assistant go further

The script covers what has a clean data source. Ask the assistant to cover the rest in the same session:

• Run osv-scanner over each Python environment and project lockfile.
• Run trivy image over each container you run, and note which findings have a fix available.
• Search NVD for the last 90 days of entries naming each program without its own advisory page, and read each hit to decide if it really applies.
• Look up runtime support dates, and flag anything past end of life.
• Check the "by hand" items: daily-build tools, suites with their own updaters, drivers.

5Read the results

A long report isn't a crisis. Most findings sort themselves once you ask three questions: does it affect the version I have, does it affect the way I use it, and is there a fix? Have the assistant answer them for each finding, in a sentence, before anything gets labelled urgent.

6Who updates what

Agree this split once, write it into the assistant's instructions, and every month runs the same way:

The second column tends to be a short list: three or four installers once a month. Having them downloaded, verified and lined up in a folder with a one-line instruction each turns it into ten minutes.

7Apply updates safely

1. Read what changed. The assistant skims the release notes for breaking changes, and says so before updating. A major version jump gets its own decision.
2. Verify the download: the SHA-256 against the publisher's published value, and the code signature where there is one. A mismatch means stop, not retry.
3. One at a time. Update, then check it works: run --version, open a sample file, or confirm the service answers. Then move to the next.
4. Pin versions rather than using "latest". In compose files, change the tag deliberately; the old image stays available if you need to go back.
5. Record it: the new version in the list, a dated line in the history log, and anything odd in the notes.

Holding back on purpose

Sometimes the newest version isn't the right one yet: a database whose extensions haven't caught up with a major release, or a tool your other software still expects at the old version. Mark it hold with the reason. The report then lists it under "held back" instead of nagging. Holds should be revisited monthly too. A hold that hides a security fix is a decision, so make it out loud.

8Check it twice

The second check is the one people skip. After applying updates, run the whole check again, before you finish for the day:

It catches the quiet failures: an update that installed to a different folder than the one you run, a launcher still pointing at the old version, a container that pulled the new image but didn't restart, a program file locked by a running process so the old copy stayed. The second pass should be clean apart from the things you chose to hold or watch.

9Spot tampering

Version checks tell you what's old. They don't tell you if a program has been changed. The script records each tool's SHA-256 fingerprint the first time it runs, and from then on:

• If the version in the list changed and the file changed, that's an update, and it records the new fingerprint.
• If the file changed but the version didn't, it raises a warning and keeps the old fingerprint, so the warning repeats until someone explains it.
• If the file is missing, it says so.

The usual explanation is harmless: a tool updated itself, or someone updated it without recording it. But it's exactly what malware replacing a trusted program looks like, so it's worth one question every time. It matters most for tools you wrote yourself, which have no publisher to compare against.

10What the checks reveal

Checking for updates means asking someone about your software. Keep it to the minimum:

• The script sends only project and package names, and version numbers, to GitHub, npm, PyPI and OSV.dev. No file contents, paths, or machine details.
• That list still describes your setup, so don't paste the report into public places, and redact paths before sharing it for help.
• Scanners download their databases; that's how they work. Turn off their usage reporting and version pings: TRIVY_DISABLE_TELEMETRY=true and TRIVY_SKIP_VERSION_CHECK=true for Trivy, and "telemetry": { "disable": true } in winget settings.
• A GitHub token raises the rate limit from 60 calls an hour. If you use one, give it no scopes; reading public releases needs none.
• NVD and OSV need no account. Without a key, NVD allows about five requests every 30 seconds; just go slowly.

11Lessons and pitfalls

• Version tags are messy. v2.4.1, jq-1.8.1, tool@2.4.1, gs10051 for 10.05.1, an extra -0 on the end. The script pulls out the numbers, and a per-entry version_regex handles the odd ones. Without that, every month reports a phantom update.
• Use "latest release", not "newest tag". Tags include betas and release candidates that you don't want to be told about.
• Some tools have no versions to compare. Daily builds and suites that ship as one bundle with their own updater are listed "by hand" with a link, and checked by looking.
• NVD keyword searches are noisy. A search for a library's name finds every product that mentions it. Read each hit's affected-versions list before believing it. Many products, especially smaller ones, have no entries at all, which doesn't mean they're safe.
• The same flaw has several names. OSV lists one flaw under its GitHub, Python and CVE ids. Count them once, or a report looks twice as bad as it is.
• "Fixed in" can list several versions for different release lines, such as 3.114.17, 4.59.1. Updating to the highest clears them all; staying on an older line means using its fix.
• A clean report isn't a guarantee. It means none of these sources knew of a problem on the day you checked. Keep the monthly cadence anyway.
• Watch-list items drift. A program kept despite a known risk needs a date to look at it again, or it's kept forever by default.
• Windows PowerShell 5.1 can mis-read UTF-8 replies from web APIs, turning dashes into garbled characters. Read the raw bytes and decode them as UTF-8, as the script does.
• Docker apps may not start after a restart if Docker Desktop doesn't start at sign-in, so a post-update check that the service answers is worth doing.

12The monthly routine

1. Snapshot installed programs and compare with last month. Add anything new to the list, and mark anything removed.
2. Run the update check; then have the assistant run the package, container and NVD checks.
3. Triage: each finding gets a verdict and a sentence on why.
4. The assistant applies its updates, verified, one at a time, and downloads the installers you'll need.
5. You run the admin installers, and restart if needed.
6. Run the whole check again. Anything still showing is either held, watched, or a problem.
7. Update the list, the history log and the security to-do list. Revisit the watch list and holds.

Set a reminder for the same day each month. Many vendors publish their security fixes on a fixed day: Microsoft on the second Tuesday, for example. Checking a few days after that catches the biggest batch.

13The script

Free to use under the MIT license, for Windows PowerShell 5.1 and PowerShell 7. It reads the inventory.json written by Install-PortableTool.ps1, or one you keep by hand in the same format. Read it before running it; it's short and commented.

Make it yours with an AI assistant

Paste the script, or this whole page, into an AI assistant along with a snapshot of your installed programs. Ask it to build your first list, fill in where each program publishes updates and advisories, and add checks for anything the script doesn't cover. Then ask it to run the check every month, explain each finding in plain words, and tell you which updates it can do and which ones need you.

If Windows blocks a downloaded script, check it first, then run Unblock-File .\Check-Updates.ps1, or start PowerShell with -ExecutionPolicy Bypass for that one run.