# Self-hosted software: is it still supported and patched?

Self-hosted software does not update itself and its vendor does not know which version you run. These are the questions that show whether each version in your estate still receives security fixes, and what to do about the ones that do not.

_Version 1.0 · last reviewed 9 October 2026 · https://trustlist.uk/due-diligence/self-hosted-software-support_

Flaws that were fixed years ago keep turning up in the exploited-vulnerabilities lists because the fix only protects the installs that received it. This list is for the person who owns the risk of software the organisation hosts itself. The first section is about knowing what you run; the second establishes what the vendor has promised and until when; the third is about hearing of flaws in time; the fourth checks your versions against what is being exploited; the last is for the versions that have run out of road. Most answers can be found on public pages and in your own servers in an afternoon.

## What you actually run

A support policy is only useful if you can match it to a version. Start with the list.

- [ ] **Do you have a list of every self-hosted product, with the exact version number running on each host, taken from the host and not from memory or the original purchase order?** _(Deal-stopper)_
      - Why: Advisories are written against version ranges. 'The 4.x line' or 'latest at install' cannot be compared with a range, and installs drift from what the documentation says they should be.
      - Ask for: An inventory with product, exact version, host, internet exposure and owner, produced from the systems themselves and dated.
      - Red flags: The list names products but not versions; Nobody can say who installed a particular server; The only record is the original project document
      - Answer:

- [ ] **Do you know which libraries, runtimes, databases and operating systems each product depends on, and their versions?** _(Important)_
      - Why: A supported application on an operating system or runtime that has left support is not a supported deployment. Vendors also bundle third-party components that age independently of the product.
      - Ask for: For each product, the supported platform list from the vendor and, where available, a software bill of materials for the release you run.
      - Red flags: The vendor cannot say which components ship in a release; The host operating system is past its own end-of-support date
      - Answer:

- [ ] **Which of these systems can be reached from the internet, and which are reachable only from inside?** _(Deal-stopper)_
      - Why: Exposure decides how fast you must act. A flaw on a public-facing service is an emergency; the same flaw on an isolated host may be a scheduled job. Without the answer, everything has to be treated as urgent or nothing is.
      - Ask for: An external scan or a firewall rule review, recorded against each inventory line.
      - Red flags: A service was opened to the internet for a project and never closed; The management interface is exposed alongside the application
      - Answer:

## What the vendor has promised, and until when

Support is a calendar the vendor controls. Find it, read it, and write the dates down.

- [ ] **Does the vendor publish a lifecycle or support policy with end-of-support dates for the branch you run, and have you recorded those dates?** _(Deal-stopper)_
      - Why: Vendors end support for branches while the product carries on, so a healthy vendor tells you nothing about your version. If the dates are not published, you are inferring support from release activity.
      - Ask for: The vendor's policy page for your branch with the release date, the end of feature support and the end of security support, copied with the date you read it.
      - Red flags: No end-of-life dates are published anywhere; Two official pages give different dates for the same branch; The branch you run is not mentioned in the policy
      - Answer:

- [ ] **Which phase of support is each version in, and what does that phase include: security fixes, bug fixes, new features, help from the vendor?** _(Important)_
      - Why: Supported is not a yes or no answer. A version can be past its feature support and still patched, or past its free security support and patched only through a paid programme.
      - Ask for: The vendor's definition of each phase, matched to your versions in the inventory.
      - Red flags: The phase is described only in a sales email; Security fixes in the later phase need a separate contract you do not hold
      - Answer:

- [ ] **Does your support contract name the versions it covers, say whether older branches get security fixes, and say what happens if you fall behind on upgrades?** _(Important)_
      - Why: A contract that says 'supported' may require you to be on the latest update to be eligible. Learning that at the moment you need help is expensive.
      - Ask for: The support terms and any order form, with the clauses on eligible versions and on required update levels highlighted.
      - Red flags: Coverage depends on a web page the vendor can change; Support lapsed and nobody noticed; Nobody can find the signed terms
      - Answer:

- [ ] **Is the end-of-support date for each product in a calendar, with an owner, twelve months and six months ahead?** _(Important)_
      - Why: End dates arrive without a message to you. A migration or an upgrade takes months, so the date that matters is the end date minus the time the response needs.
      - Ask for: Calendar entries linked to the inventory and assigned to a named person.
      - Red flags: The dates exist only in a spreadsheet nobody opens; The owner has left the organisation
      - Answer:

## Hearing about flaws in time

A fix does nothing for an install whose owner never heard of the flaw.

- [ ] **Is someone subscribed to each vendor's security advisories or release notes, through a shared address and not a personal one?** _(Deal-stopper)_
      - Why: Many open-source projects tell paying customers first and everyone else through public advisories and release notes. If you are in the second group, watching those pages is your only early warning.
      - Ask for: A list of subscriptions or feeds next to the inventory, each with a team mailbox and a named reviewer.
      - Red flags: Advisory emails go to a person who has changed role; Nobody has subscribed for products installed by a contractor
      - Answer:

- [ ] **Do you know how the vendor discloses flaws and in what order: customers before the public, embargo length, advisory page, CVE record?** _(Worth asking)_
      - Why: A free-tier or community user may learn of a flaw weeks after paying customers. Knowing the sequence tells you how long the gap can be and where the first public notice appears.
      - Ask for: The vendor's security policy page, with the disclosure and embargo rules noted.
      - Red flags: No security policy or advisory page exists; Fixes are released without a note saying they are security fixes
      - Answer:

## Checking your versions against what is being exploited

Severity scores rank flaws in general. Exploitation lists tell you what attackers are using right now.

- [ ] **Is your inventory compared against the CISA Known Exploited Vulnerabilities catalog on a fixed schedule, by vendor and product?** _(Deal-stopper)_
      - Why: The catalog regularly adds flaws that are many years old, because exploitation continues against installs that were never patched. A match is a priority whatever the score says.
      - Ask for: A dated record of each comparison, ideally from a short script reading the catalog's JSON feed, with matches and actions listed.
      - Red flags: The catalog is read only when a headline appears; A match was found and no owner was named
      - Answer:

- [ ] **For each product, have you read the affected version range in the National Vulnerability Database configuration data, and compared it with your version?** _(Deal-stopper)_
      - Why: The prose description and the configuration range can differ, and a range can include a branch that never received a fix. If your branch is inside the affected range and the fixed version is on another branch, there is no patch for you, only a migration.
      - Ask for: For each advisory, the affected range, the first fixed version, and whether your branch has a fixed version at all.
      - Red flags: The fixed version is on a major release you do not run; Your distribution backports fixes and nobody has checked its own tracker
      - Answer:

- [ ] **For any match, have you checked whether the flaw was used against you before you fixed it?** _(Deal-stopper)_
      - Why: Patching closes the way in; it says nothing about whether someone already came through. A flaw that was exploitable for years was exploitable on your system too.
      - Ask for: A log review covering the period since the flaw was published, not since you noticed it, with copies kept before any rebuild.
      - Red flags: Logs are kept for less time than the flaw has been public; The system was rebuilt before anyone looked
      - Answer:

## When a version has run out of support

Some answers will be no. Decide what happens next and put a date on it.

- [ ] **For each unsupported version, is there a chosen response (upgrade, replace, buy extended support or contain) with an owner and a date?** _(Deal-stopper)_
      - Why: Doing nothing is a decision made by the calendar. Each response takes time, and the catalog's own due dates can be as short as three days.
      - Ask for: A register entry per unsupported version with the response, owner, budget and target date.
      - Red flags: The plan is to upgrade 'when there is time'; The date is the end of support itself
      - Answer:

- [ ] **If you buy extended security support, does it cover every component of your deployment, and when does it end?** _(Important)_
      - Why: Extended programmes often cover the operating system or the core package and not every layer above it. They buy time, and they end.
      - Ask for: The programme's written scope for your product and version, and an end date in your calendar.
      - Red flags: Coverage is described as 'security updates' without naming components; No end date has been agreed
      - Answer:

- [ ] **If a version cannot be replaced soon, has it been removed from the internet or restricted to named networks, run with minimum privilege and monitored?** _(Important)_
      - Why: Reducing exposure shortens the list of people who can reach the flaw. It is a stopgap, but it is the one you can do today.
      - Ask for: Firewall rules, a gateway requiring authentication, and an alert on unexpected access, each reviewed on a stated date.
      - Red flags: The workaround was applied once and never reviewed; The management port is still open to the internet
      - Answer:

- [ ] **Has the migration to a supported version been rehearsed on a copy with real data, including plugins, custom code and integrations?** _(Important)_
      - Why: Moves across a major release can change data models and APIs. A migration discovered to be harder than expected after the deadline is the usual way a temporary exception becomes permanent.
      - Ask for: A completed trial migration with a list of what broke and how long each fix took.
      - Red flags: Plugins you depend on have no supported equivalent; Nobody who built the original customisation is available
      - Answer:

---

General guidance, not legal, security or financial advice. It does not replace your own advisers.
Maintained by TrustList.