The Hexnode patch catalog: curation and validation pipeline

Executive Summary

This page describes the content layer behind Hexnode’s patch management — the process by which application titles enter the catalog, get validated, and become available for deployment. Every customer receives patches sourced through this same pipeline, regardless of which delivery route (cloud-direct or DAFS) is used to reach a given endpoint. For how patches move from repository to device, see Patch delivery architecture.

What the catalog is?

Hexnode maintains a catalog of 1,300+ applications for which it provides pre-packaged, pre-validated patches. This catalog is the sole source of the binaries that reach managed endpoints — it’s the “centralized repository” referenced in the delivery architecture, populated and maintained by Hexnode’s own catalog team.

How titles enter the catalog?

1. Monitoring vendor release channels

   Hexnode’s catalog team continuously monitors the release channels of supported software vendors — official vendor update feeds, release notes, and published manifests — to detect when a new version or patch becomes available upstream.

   It’s important to be precise about what this monitoring does and doesn’t mean: vendor release channels and third-party manifests are observed strictly as availability signals. They tell Hexnode’s catalog team that a new version exists and should be evaluated. No third-party package manager, vendor CDN, or external manifest source participates in packaging or delivery. Detecting that an update exists is a separate act from building, validating, and distributing the package that reaches an endpoint — Hexnode does the latter entirely in-house.

2. Packaging

   Once a new version is identified, Hexnode’s catalog team builds the installation package themselves, from the vendor’s original release. This is a Hexnode-authored packaging step, not a repackaging or pass-through of a third-party installer pulled from a public package repository.

3. Validation and testing

   Each packaged title goes through a central validation and testing pass before it’s added to the catalog. This is what confirms the package installs cleanly, matches the intended vendor version, and behaves as expected across supported OS versions before any customer ever sees it.

4. Publication to the catalog

   Once validated, the title becomes available in the catalog for admins to deploy — the same validated binary every customer draws from.

Availability SLA

New titles and updates to existing titles are typically made available within 3–5 business days of detection on the vendor’s release channel, covering the packaging and validation steps above.

Requesting a new title

If a title isn’t yet in the catalog, admins can submit a request to Hexnode. Requested titles go through the same packaging and validation pipeline as titles Hexnode proactively monitors — there’s no separate, lighter-weight path for customer-requested titles; a request simply adds a title to the pipeline sooner than it might otherwise be picked up.

The supply-chain security argument

This pipeline exists to remove a specific class of risk from the admin’s hands: admins never package, modify, or directly source the binaries they deploy. An admin selecting a title from the catalog is deploying a binary that Hexnode’s catalog team has already built and validated centrally — not a file the admin downloaded from a vendor site, a public package manager, or a third-party mirror and pushed out themselves.

This matters for supply-chain security because it removes the two riskiest points in a typical patch workflow:

• No admin-side packaging: There’s no step where an individual admin’s environment, tooling, or judgment determines what binary gets built or how.
• No dependency on external package managers at the point of packaging or delivery: Vendor channels and manifests inform Hexnode that something changed — they are never the mechanism by which the payload is built or shipped to an endpoint.

The result is a single, centrally controlled point of validation between the original vendor release and every endpoint in a customer’s fleet — consistent with the hash-verifiable chain described in the patch delivery architecture.

Related documentation

• Patch delivery architecture
• Manual patch deployment