Ticket links

Ticket links are an optional record of which support or Jira ticket covers the update for a vulnerability. They appear only when Sentinel has turned ticket links on for your organisation. If you see none of the controls below, your organisation does not have them yet, and nothing else in Sentinel is different.

A ticket link is a note. Linking never marks a finding fixed, never changes its status, and never changes any count, score or report figure. Sentinel never contacts your ticket system: it does not open, check or change your tickets, and it does not know whether a ticket is open or closed. Linking is not a way to close an advisory. Use the fix itself for that.

You can link tickets to two kinds of finding: Outstanding advisories (Drupal core and module security advisories) and Known vulnerabilities (matches for your PHP, web server and database versions, including ones marked Not affected). Other updates, such as bug fix releases, have no ticket. Each finding on a site has one current ticket. One ticket can cover many findings on many sites.

Who can do what.

Everyone who can see a site sees its ticket links. Whether they can open the ticket depends on your ticket system. Viewers see no checkboxes, + Link or Remove ticket.

Set up a ticket system (optional). An Organisation admin opens Settings → Integrations (Integrations) and finds the Ticket links panel, below Slack. Select Add ticket system and fill in:

1. Name.
2. Kind: Freshdesk, Jira or Other.
3. Link template: it must start with https:// and contain exactly one {ticket} where the ticket number goes, in the path or in a query value. For example https://support.example.com/support/tickets/{ticket}. Sentinel refuses templates with a username, password, token or signature in them.
4. Example ticket. The Preview link shows the address the template builds. It opens in a new tab.
5. Tick Make this the default for new links if you want it chosen first.

Select Edit to change a system. A change applies to new links only; links you saved earlier keep the address they were saved with. Archive a system from inside Edit: its links stay readable but it takes no new links. Restore brings it back. A restored system is not the default again, and cannot be restored while another live system has the same name. Organisation admins also see how many links use each system, for example "14 links", or "31 links kept" once it is archived. Site managers and Viewers see a read-only list of the live systems, with a note to ask an Organisation admin to change them. With no systems the panel says "No ticket systems yet. You can still paste a full ticket link on any finding."

Link a ticket on one site.

1. Open the site. For advisories, open Updates and the Outstanding advisories list. For PHP, web server and database matches, open the Stack tab and find Known vulnerabilities.
2. Each advisory card has a Ticket line. Each Known vulnerabilities row has a Ticket column. Select + Link to link one finding. To link several, tick their checkboxes and select Link ticket (N). On the Stack tab this button sits next to Mark selected not affected. Mark selected not affected still takes open rows only, but Link ticket (N) also takes rows already marked Not affected. Resolved rows show their ticket read-only.
3. In the Link ticket dialog, choose the Ticket system and type the Ticket number (a Jira system asks for an Issue key, like WEB-482). The Opens box shows the address the link will have, so you can open it and check. Freshdesk numbers are digits only.
4. Or select Paste a ticket URL instead, paste a link that starts with https:// and, if you like, add a Label. Without a label the link shows as View ticket. Use a link that asks people to sign in, not a public share link. If no ticket system is set up, the dialog goes straight to this form. Select Use a ticket system instead to go back.
5. Select the button at the foot of the dialog, for example Link 3 findings.

The dialog says "Linking does not mark anything fixed." A ticket link opens in a new tab and does not tell your ticket system where you came from.

When some findings already have a ticket. The dialog asks you to choose: Only link findings without a ticket (the others keep their ticket) or Replace on N findings (the old link stays in the history). Replace is never chosen for you.

See the history, remove a link. The ⋯ button next to a ticket opens a menu with Ticket history and, for Site managers and Organisation admins, Remove ticket. The history lists every link, replacement and removal on that finding, newest first, with who made the change, when, and where it came from: the dashboard, the API, the CLI or MCP. Removing a ticket leaves the finding unchanged.

Undo. After a change, a line under the list says what was saved, for example "Linked 3 with Freshdesk #4821." Select Undo in that line to reverse it. Undo is a new recorded change: it removes the new links and puts any earlier tickets back, and the history keeps both changes. Undo is there until you dismiss the line or leave the page.

Up to 200 at a time. One change covers at most 200 findings. Select fewer, then link the rest in another change. If the list changed while you were choosing (someone else linked a ticket, or a finding was resolved), the dialog says so and offers Refresh the list. Nothing is saved until you refresh and choose again.

If a finding comes back. A fixed vulnerability that returns later starts with no ticket. The earlier ticket stays in its history. Linking one ticket on several sites does not link the advisory everywhere: a new finding starts without a ticket. If a site moves to another organisation, its ticket links and history stay behind and the new organisation never sees them.

Findings across sites. When ticket links are on, the top of Sites has a Sites | Findings switch. Findings opens the findings of all your sites in one list at /app/sites/findings, grouped by site, 25 per page. Use the filters, then select Find:

• State: Open, Resolved or All.
• Source: Drupal advisories or Known vulnerabilities.
• Severity.
• Ticket: Any, Not linked or Linked. Not linked is the quickest way to find what still needs a ticket.
• Ticket system (shown once at least one system exists), and Ticket number.

Each row shows the finding, component, severity, its Sentinel status and its Ticket. Site managers and Organisation admins tick rows, or use Select this page, which selects only the rows shown. The choice is kept as you move between pages, and cleared when you change a filter or the organisation. A bar at the foot of the page says, for example, "3 selected on 2 sites", with Clear and Review and link. Review and link opens the same Link ticket dialog. Viewers see the list, tickets and history with no checkboxes. If ticket links are off for your organisation, the address shows "Page not found".

In monthly reports. Reports show each finding's ticket as it was at the end of the month, in a Ticket column, and end with a Ticket list that groups the report's findings by ticket. It does not change any figure. See Tickets in reports.

If something goes wrong. A message in the dialog or under the list explains it in plain words. A refused link template, a number the system cannot use or an address that does not start with https:// can be corrected and sent again. "Findings could not be loaded." has a Retry button. If you lose access to the organisation or ticket links are switched off, the controls disappear and nothing is changed.

Update history

On the History tab, in the Update history panel, use the Project filter for a project machine name, choose a From and To date, and select security, maintenance, or all updates. Use page controls for more records. Read the observed version change, time, and classification. These filters apply only to Update history; the advisory evidence panels have separate page controls.

The history panel also shows median time to apply security and maintenance updates when enough observations exist.

History records changes Sentinel observed in submitted inventory. It does not prove the exact deployment time. Not recorded or partial history must not be read as zero changes.

Releases

Open a site and select History; Releases is its first section. Readers, site managers and organisation administrators can read releases for sites in their organisation. The site and its organisation must be active; an assigned client must also be active and belong to that organisation. If access is denied, ask an organisation administrator to check your membership and site access.

Deployments lists observed version changes and releases where a module or custom code was added or removed, newest first. See What counts as a deployment under Reports for how they are counted. The first inventory, unchanged check-ins and assessment-only changes are not deployments. Use Show → Inventory activity for changes where a version is unknown or only written differently, without a qualifying version change. This activity is counted separately. A deployment made only of additions or removals has an unknown rollback status, with the reason that components were only added or removed. Its rows say Not counted as a version change and have no linked fixes, and its Changes column reads, for example, "2 other changes".

Last site report shows the latest accepted report; newer changes can remain missing until the next report. No site report received means no releases can be shown yet. A stale, unknown or unavailable Security check, including an earlier check, limits fix evidence; it does not show how recently the site reported.

Filter by an exact component machine name or project, then select Apply. Use drupal for Drupal core. Choose Rollback, From and To as needed; dates use your time zone. Not rollbacks excludes entries whose rollback status is unknown. Use Previous and Next for pages of 25 entries, or Clear filters to widen the result.

Select Show details for component types, changes, previous and new versions, direction and source inventory revisions. Custom-code changes do not establish a security assessment. First observed is when Sentinel first received accepted inventory showing the change. Inventory accepted is the receipt time. Neither is the installation time. Deployment verification, completion time and environment are unavailable with the current inventory evidence. A release does not establish that the whole site is secure or up to date.

Linked fixes and Findings reopened show only retained evidence tied to the release. Read each relation: a version fix, an earlier fix later rolled back, or a reopened finding. Observation and confirmation times describe evidence, not installation. Unknown does not mean that nothing was fixed or reopened. A link-list limit can mean that more evidence exists. Follow Resolved advisory evidence under Updates to inspect advisory history. Status-only changes without a new release remain in Updates. Use Update history there for each recommended update and when Sentinel observed it applied.

Counts follow the filters and your plan's history window. At least means partial history. Unknown, missing records and a failed load are not zero deployments. Without baseline access for the site, the page shows the last 30 days; installations with billing disabled have no plan history limit. Try again retries a failed read. No matching entries can mean the filters exclude the records.

Release history requested across several sites through the API uses one shared time window. If any included site lacks baseline access, the view shows the last 30 days for all included sites; it does not hide that site or delete older records. Open an individually entitled site to read its full retained release history. When every included site has baseline access, the shared view can show the full retained history. New PAYG activation is limited to the enabled test flow described under Plan boundaries.

Opening details adds the release ID to the page address. Copy that address to share the release; recipients still need site access and a plan that includes its history. A release link can open details outside the displayed page. An invalid, unavailable or inaccessible link shows an explanation.

Where the plan includes monthly reports, release details link to that site's report for the observation month. Report release links return to the site's Releases details. Recalculated reports use observed releases; an older issued report keeps its stored figures. Opening a link does not change an issued report.

TLS certificate checks

The certificate is the first row of Health checks on the Overview tab. The Setup tab also has a Certificate card. The row shows the latest result, what it means, and how many days are left, with a bar for the share of the certificate's lifetime that remains. Select the row to see the issuer, expiry date, time remaining and last check, and expand Recent checks for previous results. Checks run daily when enabled for the installation.

• Valid: the certificate is trusted and matches the address.
• Expiring: renew it before its expiry date.
• Expired, hostname mismatch, untrusted, or invalid: ask the site operator to correct the certificate or chain.
• Unreachable: the check could not connect; it did not confirm the certificate.
• Refused: the address cannot be checked. Checks use public addresses on port 443.
• Not applicable: the registered address does not use HTTPS.

The page can also show that checks are disabled or that the first check has not run. An unavailable result is not a valid certificate result.