Software update monitoring checklist: a two-week audit plan

Audit recording template

Day 1: define the audit boundary

To audit software update monitoring, inventory the installations, map their official sources, log incoming notices, and reconcile them against those sources at the end of each week. This proposed two-week checklist produces a record of missed notices, duplicate work, and unresolved ownership. Choose the sites, repositories, and team browsers included. Assign a coordinator and backup, set the start and end timestamps in UTC, and reserve a short daily review plus reviews on days seven and fourteen. Define eligible events by product, channel, and event type, including whether prereleases qualify. Set delivery deadlines before collecting alerts, based on polling intervals and team availability. These written boundaries make counts interpretable without implying complete vulnerability coverage.

Days 1–2: build an owned inventory

Create one row per component and deployment context. Record product name, package or repository identifier, installed version, release channel, site or environment, owner, and where the version was verified. Include WordPress core, installed plugins and themes, application dependencies, and Firefox ESR where the team uses it. Keep inactive installed WordPress components visible: the official Updates screen documents updates for active and inactive plugins and themes. Mark unknown versions explicitly and assign a discovery task. Count unresolved inventory rows separately rather than treating them as monitored assets.

Days 2–3: map sources to specific questions

Attach an official release source and, where available, a security advisory source to each inventory row. GitHub documents that releases are based on tags and that their dates can differ; a tag alone should not be assumed to represent a published release notification. Record the repository and chosen event type. For WordPress, pair the site Updates screen with relevant maintainer release or security notices. For Firefox ESR, select advisories for the installed branch. Use CISA KEV as an additional exploitation-priority signal, not a replacement for vendor advisories or evidence that an unlisted issue is safe.

Day 3: establish last-checked and error records

For every source, record its URL, delivery method, planned check interval, last attempted check, last successful retrieval and review, outcome, and next check time. Separate a successful empty check from a timeout, authentication failure, rate limit, or parsing error. Preserve the error message and assign recovery to an owner; a failed attempt must not advance the last-successful timestamp. Use UTC throughout. Agree when an overdue check triggers manual inspection, including weekend ownership. A source returning content is not sufficient evidence that its product filters and alert delivery are working.

Days 4–6: capture events and deduplicate carefully

Keep a raw receipt log before grouping notifications. Record source URL, source event identifier, product, branch, version, advisory identifier or CVE when supplied, publication timestamp, receipt timestamp, and linked action ticket. Group repeated receipts for the same product, branch, and release or advisory into one canonical event while retaining their source links. Do not merge solely on a shared CVE: different affected products or branches can require separate work. Treat a material advisory revision or newly added KEV status as a new decision signal linked to the existing record, rather than silently suppressing it.

Day 7: reconcile the first week independently

Open the selected official sources directly and enumerate eligible events published within the audit window so far, independently of the alert inbox. Save event URLs, timestamps, inclusion decisions, and the reconciliation time. Match this reference list against raw receipts and canonical events. Define a missed alert as an eligible reference event without a receipt by its preassigned delivery deadline. Events whose deadlines have not passed remain pending. Record whether each gap arose from absent source mapping, failed retrieval, filtering, delivery, or an unresolved cause. This reference list only describes the sources and interval actually inspected.

Days 8–10: measure workload and repair gaps

Count missed alerts divided by eligible reference events whose delivery deadlines have passed; report both counts with the fraction. Calculate duplicate burden as redundant receipts divided by all receipts, using the grouping rule agreed earlier. Log active minutes spent checking sources, triaging, reconciling, and repairing monitoring separately from patch implementation. Calculate receipt delay from publication to first receipt only where both timestamps are available. Report missing timestamps and zero denominators as unavailable, not zero. Repair the highest-impact mapping or delivery gap, recording the change date so later comparisons acknowledge the changed setup.

Days 11–13: follow alerts through a decision

For each canonical event, record affected, unaffected, or needs investigation, with version evidence and an owner. Route actionable items to a ticket with priority rationale, next action, and review deadline. Mozilla advisories distinguish affected products and fixed releases; read the relevant ESR advisory rather than transferring conclusions from another branch. When KEV matches an installed component, revisit urgency alongside vendor instructions and exposure. Close a monitoring item only with a documented disposition; receipt does not demonstrate installation. Keep deferred work linked to its next review date and verify handoff to the backup owner.

A worked calculation with hypothetical counts

Suppose direct-source reconciliation finds ten eligible events whose delivery deadlines have passed. Eight arrived on time, one arrived late, and one has no receipt: the missed-deadline fraction is two out of ten, or 20 percent. Keep the late receipt linked so that later delivery does not erase the missed deadline. If twelve raw receipts represent nine distinct events under the agreed grouping rule, three receipts are redundant and duplicate burden is three out of twelve, or 25 percent. These are invented arithmetic examples, not measured results. A source with no eligible events has no missed-alert fraction for that interval; it has not demonstrated perfect delivery.

Day 14 and weekly thereafter: review the evidence

Repeat direct-source reconciliation through the closing timestamp, leaving events with outstanding delivery deadlines pending for follow-up. Summarize inventory rows with mapped sources, overdue or failed checks, eligible reference events, misses, duplicate receipts, and active minutes. Retain unresolved classifications and exclusions alongside the counts. Choose specific follow-ups, such as assigning an unowned plugin or repairing one stale source, and repeat this review weekly. A quiet fortnight may contain no eligible events and cannot demonstrate reliable coverage. These records support operational decisions; they do not certify security, compliance, or complete vulnerability detection.

Primary sources and methodology

This is a proposed audit procedure informed by the primary sources below, reviewed on 2026-11-03. It reports no completed experiment or fourteen-day results. It is not a benchmark, scanner, or validated coverage assessment. Measures depend on the chosen inventory, inspected sources, event definitions, and recorded timestamps.

• GitHub Docs: About releases
• WordPress documentation: Dashboard Updates screen
• Mozilla Foundation Security Advisories
• CISA: Known Exploited Vulnerabilities Catalog