Configuration drift

Configuration drift means the configuration on the live (production) site differs from the configuration saved in your code, usually because someone changed a setting in the admin pages and it was never committed. Sentinel shows it in three places when drift reporting is turned on. The connector (version 1.3.0 or later) sends only the names of the configuration objects that differ, never their values. When a site reports more than Sentinel keeps, the section says so. Every member who can read the site, viewers included, sees the tile, the column and the section. Nothing on these pages changes data, and no plan is required.

• Home: the Configuration drift card (see Dashboard: review the fleet).
• Sites: the Configuration drift column and filter (see Sites: add, connect, and inspect Drupal).
• Site page: open the History tab and go to Drupal configuration, its last section (the address ends ?tab=history#drift). It shows only while drift reporting is on.

The section shows a heading and badge for the state, then Objects, First seen and Last report. These are the states:

Unknown is never shown as clean. Do not read an unknown state as no drift.

What differs lists each object with its Collection (Default for the default collection), Name, Difference and First seen, 50 to a page with Previous and Next. Difference reads Only in production, Changed, Only in code or Renamed. Only in production means the object exists on the live site but not in your code (an import would delete it); Only in code means it is in your code but not on the live site (an import would create it). When the connector reported more objects than Sentinel keeps, the text says how many were reported and how many are kept.

How to fix it appears only while there is drift. Take a backup first, or make sure your deployment process takes one.

• If the connector reports the Config Pull Request module is enabled: on production open Configuration synchronisation, then Pull Request (/admin/config/development/configuration/pull_request), select the changed objects, create the pull request, review it in your repository, then merge and deploy it. When the connector reports an open configuration pull request, the section links to it.
• Otherwise, with Drush: run drush config:status on production to list the differences, run drush config:export -y on a copy of the site with the production database, commit the changed files and deploy them.
• To discard the production changes instead, run drush config:import -y on production. Changes made in the admin pages to those objects are lost.
• Make drush sentinel_connector:deploy the last step of every deployment, so Sentinel sees that production matches code straight away rather than at the next scheduled report.

Interpret assessment evidence

An assessment compares received inventory with published Drupal release and advisory data. It does not prove that a site has no vulnerabilities.

Expand Assessment details for timestamps, inventory revision, and advisory coverage. Read the unknown-extension and custom-module counts. No known applicable advisory means the checked dataset found none for that observation. It is not a guarantee of security.

Some advisory version ranges include alpha, beta or release candidate versions. Sentinel can assess supported ranges, but an improved assessment result does not always close an existing finding. The finding and its SLA clock can remain open while resolution cannot be recorded. Check the finding status as well as the assessment result. A module on a published alpha, beta or release candidate, or on an unsupported release branch, or a module whose Drupal.org project is marked Not supported, whatever version is installed, is identified on Drupal.org but has no security coverage there: Drupal.org does not issue security advisories for it. Sentinel counts such a module as assessed, so it does not keep the site Partial. On a supported branch it still gets an update status: Current when nothing newer is published, or a maintenance update when a newer release is out, even one without security coverage. Its security status reads Not covered in the All modules list. It is listed with its reason under Drupal.org coverage on the Overview tab; move it to a supported, covered stable release to get a security status. Other reasons still keep the site Partial: an unknown or development version, missing project identity, Drupal.org data unavailable, an incompatible or unknown version constraint, or an installed release absent from public data. In the Sites list and on the Dashboard, a site whose only gaps are modules without security coverage shows its security counts, not Unknown. On the site page, when a current partial check left some extensions unchecked, the Known vulnerable observations and Known outdated observations cards show a minimum count, with how many extensions were checked and how many were not. They show Unknown when there is no current check, or when the check is partial for another reason, such as an inventory that lists only some modules. The Drupal.org coverage panel lists each reason with its count beside it: Not checked first, then Checked, without Drupal.org security coverage, then custom modules under Your own code. On the Dashboard, Site Overview shows the message with "N on an unsupported branch or without security coverage." A Drupal core result does not establish the security status of contributed or custom modules.

The page checks a pending assessment for a limited time. If automatic checks pause, use Refresh status. This reads the existing assessment status; it does not send Drupal inventory or request a new assessment.

To ask Sentinel to check the site against Drupal.org again, select Re-check now in the Drupal.org assessment panel, next to "Drupal.org data checked …". While the check is queued or running the button reads Checking… and is disabled; the panel updates when it finishes. You can check a site on demand once every 3 minutes. If you select the button again while the last check is still running, you simply follow that check. If you select it within 3 minutes of a finished on-demand check, the panel says when you can try again ("You can check it again in N seconds") and the button stays disabled until then. Only checks you ask for count towards the 3 minutes. Re-check now is available to organisation admins and site managers, on paid plans and on installations with billing disabled. Viewers do not see it. On the Free plan the button is not shown: a Free site waits for Sentinel's scheduled refresh. Platform administrators viewing a customer's site do not see it either; they use the administration console. To check all the organisation's sites at once, see Re-check all sites under Sites above.

Sentinel also tries again by itself. If Drupal.org could not be reached, or answered with data Sentinel could not read for some modules, it retries that site after 1, 2, 4 and 8 hours, then waits for the next scheduled refresh. After a Sentinel update that changes how results are worked out, every site is assessed again automatically in batches, so you do not need to re-check each one. Unknown results caused by a temporary Drupal.org problem therefore usually clear on their own.

Security patching SLA

An SLA is the time allowed to apply a security update after its advisory is published. It is a patching target, not a site uptime percentage.

When enabled for the plan, an organisation admin or site manager can choose No SLA or one of the supported targets from six hours to 28 days, either in Add site or later in Edit site. If an old target is no longer supported, choose a supported value before saving. The Dashboard prompt to set an SLA appears only once a site has sent data, and waits while any site in the organisation has not reported yet.

Choose how the target applies:

• Apply to history: apply the first target to earlier recorded exposures. Historical evidence can be incomplete.
• From now on: do not judge exposures that began before that first target. Later changes use the target history for each exposure.

Pending within SLA, breached, no target, unscored history, and no data have different meanings. A missing check-in is not proof that an SLA was met. Changes can affect live calculations and newly generated reports. Already issued report figures stay in their stored version.

Where observed resolution is enabled and retained evidence supports it, patching calculations can end at the first accepted inventory observation that shows the fix. Otherwise, they use the time Sentinel confirmed resolution. Neither time proves when the update was installed. Retained evidence of a fix followed by a rollback can separate the periods of exposure. Missing project identity or incomplete older records can prevent this calculation. The Updates tab and Site Overview patching details show observation and confirmation times separately where recorded. Site Overview uses the clock stop to show whether an exposure remains open. Report views can still show confirmation times, which can be later than the time used in the calculation.

Maintenance update SLA

A maintenance update SLA is the time allowed to apply a maintenance (non-security) update after its upstream release. It is separate from the security patching SLA, and each has its own No SLA option, so a site can have security only, maintenance only, both, or neither.

Under Maintenance update SLA, in Add site or Edit site, an organisation admin or site manager can choose No SLA, 1 month, 2 months or 3 months. These are stored as 30, 60 and 90 days. The field appears under the same plan rule as the security SLA; viewers cannot set either SLA, and the server refuses the change.

When you choose a maintenance SLA, a separate SLA applies to choice appears for it:

• Apply to history: score every maintenance update on record against the SLA, including ones outstanding before it was set.
• From now on: only score maintenance updates released after the SLA was first set. Earlier ones show as outstanding, never as overdue.

Once a maintenance SLA is stored, In effect since shows its start date under the field.

A site's monthly verdict stays a security judgement. Monthly reports show maintenance SLA results in three places: the Summary's Maintenance within SLA figure (when a site in the report has a maintenance SLA), the Maintenance target in a site report's result block, and the SLA result on each maintenance change in the deployment ledger. The dashboard does not show maintenance SLA results yet.

Updates tab: status, tiles and panels

Open a site and select Updates. Organisation members who can read the site can read this tab; administrator access is not required, and it is the same on every plan. A red number on the tab counts the site's security updates when there are any.

A row called Update lists has three chips. Needs action is the default and holds everything described below. All modules shows the full inventory (see The five site tabs). Platform shows PHP, web server and database versions (see The Platform list). When the site has open platform matches, a line at the top of Needs action such as "Stack: 4 PHP vulnerabilities, 1 Nginx vulnerability" opens Platform.

The tab starts with one line. On the left, Security shows the site's security status badge. When the status is At Risk or Critical, the line also gives the reasons the site record shows: how many vulnerable components, known vulnerabilities in the server stack, Drupal core that is unsupported, PHP that is end of life, and how many modules have no security coverage. On the right, Last check shows when the site was last checked, with a freshness badge. With no check yet, the badge reads never checked; an old check reads outdated. The badge is left off when the check ran but its evidence could not be loaded. The amber assessment banner that the other site tabs show does not appear on Updates; this line replaces it.

Under the line are four tiles: Advisories, Security updates, Maintenance updates and Coverage. Each tile is a button. Select it to open its panel under the row, and select it again to close the panel. Only one panel is open at a time. When you arrive, a site with nothing to act on shows no panel. Otherwise the first tile with something to act on opens: Advisories, then Security updates, then Maintenance updates.

A tile is grey while its data loads, when it could not load, and when there is no current check. The Advisories tile is also grey when the check was partial or outdated and found nothing. It then shows …, – or Unknown instead of a zero. No current check, None confirmed and Could not load are not a clean result. An update tile for a partly loaded inventory reads, for example, "40 of 213 modules read".

Zero is shown on the tile, so the large green 0 components cards no longer appear. A note under the tiles says that green means nothing is listed in the data Sentinel has, and is not a whole-site all-clear. Read that note with the Coverage tile. A search with no matches in an update panel keeps the tile's total count and colour.

Advisories

The Advisories tile opens Outstanding advisories. It counts outstanding advisories, including those with No verified fixed release. Each advisory is counted once. Read its component, detection time, severity, advisory fixed version and latest check. Why it is not confirmed resolved explains why a finding stays open, for example an affected installed version, stale check, missing project identity or a result awaiting confirmation. Use Previous and Next to read further finding pages, with 25 findings per page. No confirmed outstanding findings does not give a whole-site all-clear when coverage is limited or custom components lack public advisory data; the panel says so and lists the limits.

When ticket links are on for your organisation, each advisory card also has a Ticket line and a checkbox. See Ticket links.

Security updates and Maintenance updates

Security updates and Maintenance updates list component release recommendations. Their counts can differ from the advisory count. Search each list by module, project or version. These searches do not filter Outstanding advisories or resolved evidence.

An empty list shows No security updates listed or No maintenance updates listed once the initial data requests have finished and inventory has loaded. Green zero stays green when assessment data is incomplete, outdated or unavailable. It means that no updates are listed in the available data; it does not confirm that the site is current. Read the Coverage tile for coverage limits and the Advisories tile for outstanding advisories.

Loading is not an empty result. While inventory or the initial assessment result loads, the tile and panel show Loading security updates… or Loading maintenance updates… in a neutral colour. If inventory could not be loaded, they show Security updates unavailable or Maintenance updates unavailable, with no zero count; select Retry inventory page. Known updates remain listed. If advisory evidence could not be loaded, select Retry. Reading or refreshing this page does not apply a patch or start an assessment.

Coverage

The Coverage tile opens Assessment coverage and Freshness. Read them separately from the advisory count. Assessment coverage shows whether the check was complete, partial or unknown, and the inventory revision. Freshness shows whether the latest check is fresh or stale, and when it ran. Components that were not assessed are grouped by reason. Modules without Drupal.org security coverage appear in the same groups with the reason "unsupported release branch" or "release without security coverage". Custom components are counted separately because they have no public advisory data. If inventory has changed since the accepted check, current assessment evidence is unavailable.

Inventory pages

On Updates, the line "Inventory page 1 · 213 loaded of 213 modules" shows only when the inventory has more than one page or a page failed to load. In the All modules list it always shows. Use it to see how much of the inventory the update lists are built from.

Resolved advisory evidence

On the History tab, below Update history, Resolved advisory evidence shows findings whose current exposure is resolved. Read the basis:

• Fixed by a version update: retained evidence identifies a version fix.
• Project removed from the site: the project was removed; this is not a patch.
• Advisory no longer applies: resolution has another recorded applicability basis.
• Resolved before resolution evidence was recorded: the older resolution lacks a recorded basis.

Fix first observed (or Resolution first observed) is the recorded inventory observation time. Confirmed resolved is when Sentinel confirmed the result. Neither proves the installation time. Unavailable names missing evidence; a legacy confirmation does not supply an observation time. Versions appear only when retained evidence supports them. Recorded later from retained evidence identifies a later reconstruction from stored records.

Expand Earlier exposures where available. A reopened finding appears under Outstanding advisories, with its earlier resolutions on that card. It is not also listed as currently resolved. Fixes observed and later rolled back shows recorded fix and rollback times; it does not mean the advisory is now resolved.

Without baseline access for the site, resolved and earlier exposure history is limited to the last 30 days. Recorded rollback intervals also have this limit. Outstanding findings remain visible regardless of age. The page names history outside the plan and records it could not read. An empty resolved list can mean no visible records within that limit.

Advisory evidence and Update history measure different things: an advisory exposure and a recommended release. One release can fix several advisories. A finding can have no matching Update history row. These panels do not add release rows or change the history medians.