Patch Management

1\ endpoint agent logic data collection & caching agent the agent's primary role is to efficiently gather patch information from the host os and report only the necessary changes to the backend using a local sqlite database for caching is crucial for minimizing network traffic and resource usage initial scan & cache creation this process runs the first time the agent is installed or when its cache is cleared data collection use os native apis to get a complete list of installed and applicable (needed) patches windows utilize the windows update agent (wua) api linux use package managers like dpkg/apt (debian/ubuntu) or rpm/yum/dnf (red hat/centos) data points for each patch, collect kb id or package name (maps to patch release kb id) title/description (maps to patch release title) current status ('installed', 'needed', 'failed') installation date (if available) local caching (sqlite) create a simple local sqlite database on the device store the full scan results in a table that mirrors the essential fields of the backend's device patch state table (e g , kb id, status) initial upload serialize the entire list of discovered patches into a json payload and send it to the backend's ingestion endpoint this is the largest data transmission the agent will typically perform delta scans & differential uploads all subsequent scans will be delta scans to report only changes perform new scan execute the same os native data collection commands to get the current patch state compare with cache compare the results of the new scan against the records stored in the local sqlite database identify changes (deltas) new patches any patch present in the new scan but not in the local cache status changes any patch where the status has changed (e g , from 'needed' to 'installed') removed patches any patch in the cache that is no longer reported by the os (could indicate supersedence or uninstallation) construct payload create a json payload containing only these identified changes each item should clearly state the patch identifier and its new status upload delta send the smaller delta payload to the backend api update cache upon receiving a successful (http 200) response from the backend, update the local sqlite cache to reflect the state of the most recent scan 2\ backend api & data processing 🖥️ the backend is the central hub that processes agent data, manages policies, and serves information to the frontend data ingestion endpoint endpoint post /api/devices/{deviceid}/patch state logic authenticate the agent and validate the deviceid accept the json payload (both full and delta payloads are handled by the same logic) create a record in device patch scan to log the raw scan event for auditing iterate through each patch in the payload look up the patch release id from the patch release table using the kb id and os/product info if the patch is unknown, it may be added to the catalog in a pending/unverified state for later review look up the status id from the ref patch status table perform an upsert operation on the device patch state table for the given device id and patch release id this will either insert a new record or update an existing one with the new status id, last seen, and last change at timestamps after processing, trigger an asynchronous background job to recalculate the summary data for this device summary & kpi calculation this logic runs in a background job to avoid slowing down the api response device patch summary calculation for a given device id, query its records in device patch state join with patch release and ref patch severity to count pending patches where severity is 'critical' or 'important' calculate the compliance pct by dividing the count of 'installed' patches by the total count of applicable ('installed' + 'needed' + 'failed') patches update the last scan at from the most recent device patch scan record upsert the calculated data into the device patch summary table for that device id api endpoints for frontend dashboard summary get /api/patch management/summary aggregates data from device patch summary to get total compliance and missing patch counts counts devices from the device table where reboot pending = true dashboard patch list get /api/patch management/patches queries patch release and uses subqueries or left joins with device patch state to aggregate the counts of devices in 'installed', 'needed', and 'failed' states for each patch joins patch approval to retrieve the current approval status device specific patch list get /api/devices/{deviceid}/patches?status=\<status> queries device patch state filtered by the deviceid joins patch release and its related reference tables (ref patch severity, ref patch classification) to get descriptive details uses the status query parameter to filter for the tabs in the ui policy management (crud) get, post, put /api/patch policies/{policyid} these endpoints will handle all create, read, update, and delete operations for the policy related tables (patch policy, patch policy rule, patch policy assignment, etc ) 3\ frontend ui implementation 🎨 this section details how to build the user interface components based on the backend apis patch management dashboard (screenshot 1) kpi cards on page load, fetch data from /api/patch management/summary populate the summary cards with the response use a timer to refresh this data periodically patches by severity chart use the summary data to render a donut or bar chart with a library like chart js or d3 js patch status grid fetch data from /api/patch management/patches use a robust data grid component that supports server side pagination, sorting, and filtering to display the results render the "approval status" as a color coded badge make the count columns ("installed", "needed", "failed") clickable, linking to a filtered view of the affected devices device patching view (screenshot 2) this is a device specific view, routed via a url like /devices/{deviceid}/patching header on load, fetch device details and the patch summary from /api/devices/{deviceid}/patch summary to populate the header information tabs and grid implement tabs for "needed", "installed", "failed", etc when a tab is selected, call the /api/devices/{deviceid}/patches?status=\<status code> endpoint display the returned list in the data grid include action buttons like "deploy" which would trigger api calls to create patch deployment records, or "create exception" which would create a patch exception patch policy editor (screenshot 3) this is a form based interface for creating and editing policies data population when editing, fetch the full policy configuration from /api/patch policies/{policyid} use this data to populate the form fields, including the rules and assignments dynamic rule builder the "auto approval rules" section requires a dynamic form component users should be able to add or remove rule blocks the dropdowns within these blocks (e g , classification, severity) should be populated from reference data endpoints (e g , /api/ref/patch classifications) saving on save, serialize the entire form state into a single json object send this object in a post (for new policies) or put (for existing policies) request to the /api/patch policies endpoint the backend will handle the logic of updating all the related database tables