Check which snapshots carry a flawed package

Built for engineering leads who fear the call that starts with 'are we exposed to this one,' when the honest answer is that somebody will have to go and look.

A flaw gets published with an ID number and a severity. The question comes down from leadership within the hour. Answering it usually means logging into machines, running queries by hand, and comparing the output against the advisory. The answer arrives late and nobody is fully sure it is complete.

Package-Master ingests the issuers' own advisory feeds and matches them against the package names held in your snapshots, so you can pull a candidate list in minutes without touching a machine. Be clear about what that list is today: a starting point you confirm against the advisory, not a finished answer. Package-Master does not produce a version-aware affected-or-already-patched verdict. We publish that boundary here rather than let you assume the stronger result.

If an upstream source is unreachable, the refresh for that source fails and what you serve does not change. Your machines never see a half-updated set: a new set is visible only once it is complete. Snapshots you already made are unaffected, because a snapshot never changes once created. Package-Master depends on PostgreSQL, so run that database with the same care as any other production database; the docs cover deployment topology. If you go past your machine band, nothing shuts off. We flag it and point you at the next plan, prorated.

No measured customer results are published yet.

You can hand someone the advisory feed record, the candidate list of packages an advisory names in a given snapshot, and the record of when a later snapshot no longer carried the package. This describes the package set you publish. What each machine actually installed is separate: the optional fleet observer records that in your own instance for machines you enroll, and nothing about your fleet ever reaches us.

Does this tell me which machines are affected?

Out of the box, no: this workflow reads the package set you publish, not the install state of individual machines. If you enroll the optional fleet observer, your own instance also records what each enrolled machine reports as installed, so you can see which machines report a package an advisory names. That is still a candidate list you confirm against the advisory, and the inventory lives in your instance, never with us.

Where does the flaw data come from?

Two issuer feeds: Ubuntu Security Notices and the Debian Security Tracker. These are the same feeds Canonical and Debian publish themselves. No third-party aggregator sits in between.

How fast does a newly published flaw show up?

The feeds are refreshed on a schedule, and you can trigger a sync by hand at any time.

Does it rate severity for us?

It reports what the published advisory says. It does not invent its own severity score, and it cannot tell you the risk in your particular setup.

Can we use this without an internet connection?

Upstream sync and advisory feeds need outbound access to their sources. Stored packages remain available internally. Physical transfer into fully disconnected networks is in development. See the supported page for scope.

• Promote an upgrade without surprises See every package change, and the advisories that name those packages, before it reaches production.
• Control how updates enter your network Sync approved sources from your deployment. Serve packages internally.
• Control where your software comes from One allow-list. No machine quietly pulling from a stranger's repository.