Every host patched.
Every patch provable.

Exposure

A register of every CVE in the estate

Every CVE reported by an enrolled host on one page, counted by severity: how many machines carry it, which package closes it, and how long it has been pending. Each row opens on the hosts it affects.

Remediation

Closing them creates a patch wave

An entire severity tier can be closed in one action, across the estate or inside one application, run manually or on a date. It creates a patch wave, so approval, the freeze calendar and the schedule apply to it exactly as they do to any other run.

A wave that succeeds on every host moves into the wave history by itself. Where it does not, it returns as a draft aimed only at the hosts still exposed, so a retry never patches a machine that is already fixed.

Consistency

Package consistency across the estate

The inventory answers which versions of a package are installed and on which machines. A host running something other than the version most of its peers on the same release run is reported as drift, named rather than counted, and a single action brings every host that differs back to it.

A pinned package, whether company-wide, by group or on a single host, is left out of what a wave installs, while remaining visible to the inventory and to CVE reporting.

Measurement

Patch posture by environment, and the time to close by severity

Coverage is reported by environment and by application, with a 30-day or 90-day trend. Time to remediate and the SLA compliance rate are calculated per severity from the remediation events themselves, and the update SLA and the CVE SLA are separate measures with their own thresholds and their own switch: turned off, a measure does not appear in the report.

Open items are aged in buckets from under 30 days to over 180, and every host is checked against the published end-of-life date for its release.

Identity

People sign in with the account they already have

Active Directory or any other LDAP directory. An account is created here on first sign-in and takes the role its directory groups map to, one pair per line, so joining a team in the directory is the whole of granting access here.

Two rules make it safe to switch on. Local accounts always keep working: a username that already exists here is never checked against the directory, so one that is down, unreachable or misconfigured cannot lock anybody out. And a directory can never grant superadmin: that role is not in the mapping at all, so the directory cannot take over the installation.

Access control

Five roles, from read-only to full control

Viewer has read and print access only. Application user sees only the servers belonging to the applications they own and may request an exception. Operator creates and executes waves. Admin approves runs and administers users. Superadmin additionally controls company branding and licensing.

Every account is scoped to the applications it belongs to: a team lead opens the console and sees the systems under their responsibility, not the entire estate.

Exceptions

Exceptions with an owner, a reason and an expiry

The application owner submits the request with a justification, such as a change freeze, a ticket reference or a month-end close, and an administrator approves or rejects it. Once approved, the host is skipped on its next run and the exception is consumed, so it cannot become a permanent exclusion that no one remembers granting.

The requester, the justification, the approver and the run that consumed the exception are all retained, and the skipped host is reported as an exception rather than counted as patched.