RapidFort announced a GitLab partnership on November 3, 2026, covering hardened container images for regulated Self-Managed deployments. A detail matters when reading its remediation promises: the stated clock begins when an upstream patch is available. A vulnerability’s discovery date and the availability of its fix are separate events.
RapidFort’s November 3 company-issued announcement
Read the trigger beside the deadline
The announcement gives seven calendar days for Critical and High severity CVEs, 21 for Medium and 28 for Low, once an upstream patch is available. RapidFort’s indexed partnership explainer repeats that starting condition. Treat these as the provider’s published terms to confirm for the particular image and service under discussion, not independently measured patch performance.
RapidFort’s partnership explainer and published remediation periods
The company also says multiple GitLab images are immediately available in its curated catalog. That is an availability claim. It does not establish which image a particular organization runs or whether that organization has deployed an updated build. No image, registry account or running GitLab installation was tested for this article.
Separate four dates in a review
Keep a record of when the issue became known to your team, when the relevant upstream fix became available, when a suitable curated image was published and when your environment actually adopted it. Give each entry its own evidence and owner. If a date cannot be verified, mark it unknown instead of substituting the date of a press release.
Consider a fictional tracking example. A team records an issue at elapsed day 0. The relevant upstream patch becomes available at day 4. For an applicable seven-calendar-day period, simple elapsed-day arithmetic reaches day 11. Counting seven days from day 0 would use a different starting point. This example does not determine a real contractual due time; confirm timestamps, applicability and the governing service terms with the provider.
If a curated image appears at day 6 but the team deploys it at day 9, those entries document different stages. Neither the day-6 publication nor the day-9 deployment should overwrite the earlier dates. Keep the image reference and the observed deployment state beside the record so later reviewers can tell what each timestamp describes.
Identify the version being evaluated
GitLab’s Docker installation documentation advises production users to pin a specific GitLab version. It describes the latest tag as suitable for testing. That documentation concerns GitLab’s own images; it does not by itself verify a third-party image’s compatibility or support conditions.
GitLab Docs: choosing a version and edition for Docker installation
For a planned evaluation, ask the supplier to identify the exact image, GitLab edition and version, applicable patch policy and supporting change evidence. Use your organization’s approved deployment and recovery procedures for any real change. The practical outcome is a traceable record that distinguishes a fix becoming available from a revised image being published and that image reaching your environment.