Security & Maintenance pipeline overview
A high-level tour of how Core collects daily host snapshots, refreshes three CVE feeds, correlates risks against snapshots, and applies remediations inside customer maintenance windows.
Last updated 20 days ago
Security & Maintenance pipeline overview
The Security & Maintenance pipeline is the part of ImpulseCore that watches every host an Impulse module manages for known vulnerabilities and applies patches inside customer-scheduled windows. Modules supply the data and the action; Core supplies the chrome, the scheduling, the CVE feed, and the audit trail.
This article is a high-level orientation. The deep doc at /docs/impulsecore/security is the source of truth for behaviour.
Daily snapshot collection
Each module that opts in ships a SecurityCollector class in lib/Security/. Core auto-discovers these at install time and calls them on a schedule.
The security_collect task ticks daily. For every service (or every host, for shared infrastructure) the module manages, Core calls the registered Collector and writes one row into the snapshots table — pending package updates, kernel version, service versions, reboot-required state, defensive posture (UFW, fail2ban, SSH config).
Each Collector has a 5-minute timeout. If a single host's collection fails, the failure is captured on the snapshot row as a collectorError; the rest of the run continues.
CVE feed refresh
Core maintains its own CVE feed in mod_impulsecore_cve_feed, refreshed from three upstream sources:
The NVD-by-CPE feed is what catches the things USN misses — managed Postgres, MinIO, Meilisearch, GoTrue, and anything else a module declares as a direct-install product.
Risk correlation
The matcher intersects every snapshot against the CVE feed:
- The host's pending apt upgrades against USN entries by package name.
- The host's running module products against NVD entries by CPE, gated on whether the running version falls inside NVD's affected range.
Matches are surfaced on the admin Security tab, with severity routing the visible posture:
- Critical (CVSS 9.0+ or KEV-listed) — red banner on customer Overview, badge on Security tab, email. Auto-scheduled patch within 24h. Not deferrable.
- High (CVSS 7.0–8.9) — amber banner on Security tab. Standard window patch, deferrable.
- Medium / Low — listed in Security tab, no banner.
Remediation during a maintenance window
Modules can optionally ship a SecurityActuator alongside the Collector. The Actuator implements snapshotBeforePatch(), applyUpdates(), reboot(), and restoreFromSnapshot() for one host.
The default maintenance window is Sunday 02:00 in the client's WHMCS timezone, 60 minutes. Customers can edit day-of-week, start hour, duration, and timezone from their service's Security tab. Operators don't schedule windows manually — customers own them.
The security_apply_window task ticks every 5 minutes. When a scheduled patch is due and the customer's window is open, the walker calls the Actuator: pre-patch snapshot, apply updates, reboot, health check, rollback if the health check fails. Each step writes to both mod_impulsecore_audit_log and mod_impulsecore_security_events.
Standard (non-critical) patches can be deferred once per cycle, capped at 14 days from when the patch first became applicable. After the cap the Defer button disappears and the next window applies the patch automatically. Critical patches never render the Defer button.
Pre-patch snapshot and auto-rollback
Before applyUpdates() runs, the Actuator calls the module's VPS provider snapshotBeforePatch(). The supported providers (Vultr, Linode, Hetzner, DigitalOcean) all implement snapshot APIs and return a provider snapshot id. If the patch fails or the post-patch health check goes red, the walker calls restoreFromSnapshot() to roll the host back.
Null is a valid return — an unsupported plan or transient API failure degrades to "patch without rollback safety net" rather than blocking the patch. A snapshot_skipped audit entry records which patches went out without one.
Opt-in, not mandatory
Not every module registers a Collector or Actuator. Modules opt in by shipping the classes under lib/Security/; Core picks them up automatically at install time. A module without a Collector contributes no snapshots and doesn't appear on the Security tab. A module with a Collector but no Actuator shows up as read-only — admins and customers see the posture, but the Patch and Reboot buttons are disabled.