OpenInfra Foundation Explained: OpenStack, Kata and the Linux Foundation

The OpenInfra Foundation is the open source foundation that hosts OpenStack, Kata Containers, StarlingX and Zuul. It began life as the OpenStack Foundation, and in 2025 it became part of the Linux Foundation: the boards announced the intent on 12 March 2025 and the foundation said the move was complete in early June 2025. Its projects keep their own technical governance, release cycles and security processes.

If you run OpenStack in production, run Kata Containers under Kubernetes, or ship anything built on Zuul or StarlingX, the foundation's rules decide how long your release is supported, who handles a vulnerability report, how long an embargo lasts and what happens when a branch stops getting fixes. This guide reads those rules from the source: the Linux Foundation's press release, the OpenInfra Foundation's own pages and blog, the OpenStack releases site, the OpenStack Project Team Guide on stable branches, the Technical Committee charter, the release cadence resolution that created SLURP releases, the OpenStack Vulnerability Management Team process, the OSSA list, and the Kata Containers security policy and VMT document. Every date and rule below comes from one of those pages as fetched on 24 October 2026.

Key takeaways

• The Linux Foundation announced on 12 March 2025 that the Open Infrastructure Foundation intended to join it as a member foundation, after unanimous approval by both boards. OpenInfra's executive director published a post dated 3 June 2025 saying the move was official and that members had voted.
• The press release said OpenInfra would keep functioning as it did on board positions, project governance, budget, memberships and the Four Opens. The OpenInfra site now describes the foundation as "part of the nonprofit Linux Foundation".
• The foundation's projects page lists four confirmed projects: Kata Containers, OpenStack, StarlingX and Zuul. It also runs working groups on digital sovereignty, AI workloads, the Computing Force Network and migration from proprietary virtualization.
• OpenStack ships every six months. Every other release is a SLURP (Skip Level Upgrade Release Process) release, so operators can upgrade once a year. Releases are Maintained for roughly 18 months, may then move to Unmaintained (no releases are allowed from those branches) and finally End of Life.
• As of 24 October 2026 the newest OpenStack release is 2026.2 Hibiscus (released 30 September 2026). 2026.1 Gazpacho and 2025.1 Epoxy are the SLURP releases still in the Maintained phase, and 2027.1 Indri is in development with an estimated release on 24 March 2027.
• OpenStack security reports go to the Vulnerability Management Team (VMT), which publishes OpenStack Security Advisories (OSSAs) and, for issues that need guidance rather than a patch, OpenStack Security Notes (OSSNs). Downstream embargoes are deliberately short (3 to 5 business days), and no embargo should run past 90 days.
• Kata Containers is a rolling release project: only the latest monthly release gets security fixes and there are no long term support branches. The latest release when we checked was 4.3.1, published 21 October 2026.

What is the OpenInfra Foundation?

The OpenInfra Foundation is a non-profit that builds and funds communities writing infrastructure software that runs in production. Its about page says it has "over 110,000 members in 187 countries", which counts individual community members, not paying companies. Companies join as members at different tiers (the site lists Platinum and Gold members), fund the foundation and get seats or representation on its board.

The foundation's own description of its job is short: bring together developers, operators and organisations in an open way, guided by principles it calls the Four Opens, and support "the development and adoption of production infrastructure with open source components". In practice that means it runs the shared services that projects need but rarely want to run themselves: legal and trademark ownership, event programmes (the OpenInfra Summit, OpenInfra Days and the Project Teams Gathering), community infrastructure, a user survey, and the governance machinery that elects project leaders.

Where did it come from?

The organisation started as the OpenStack Foundation, created to give the OpenStack cloud platform a neutral legal home outside any one company. The foundation's projects page says OpenStack has been running "since launching in 2012"; that is the year the foundation formed, while the OpenStack software itself was first released earlier. As the foundation began hosting projects that were not OpenStack (Kata Containers, StarlingX and Zuul), it renamed itself the Open Infrastructure Foundation, shortened to OpenInfra. The TC charter still uses the older wording in places, for example requiring TC members to be "OpenStack Foundation" individual members, which is a useful reminder that governance documents lag behind names.

In 2022 the foundation added a directed funding model, which lets member organisations fund a specific project's hosting rather than only the foundation as a whole. The foundation's home page links to its announcement of that change, made at the 2022 OpenInfra Summit in Berlin. Directed funding is the model that let it host projects beyond OpenStack without asking OpenStack's backers to pay for all of them.

What does "open infrastructure" mean here?

The phrase covers the software layers under applications: virtualization, bare metal provisioning, software defined networking and storage, container isolation, edge cloud stacks and the CI systems that test all of it. OpenInfra and the Linux Foundation also publish an "Open Infrastructure Blueprint", which the Linux Foundation's press release describes as an integration of Linux, OpenStack and Kubernetes. The idea is a fully open stack from the kernel to the container orchestrator.

How did the foundation move to the Linux Foundation?

The move happened in two public steps in 2025.

What the announcement promised

The press release is specific about what would not change. "Pending completion of the process," it said, the OpenInfra Foundation "will operate within the Linux Foundation" and "will continue to function as it currently does regarding board positions, project governance, budget, memberships" and its community approach guided by the Four Opens. That sentence is the one to hold the foundation to. It means:

• OpenInfra keeps its own board of directors and its own membership tiers.
• OpenStack keeps its Technical Committee, its elected project leads and its release process. Kata Containers, StarlingX and Zuul keep their own governance.
• OpenInfra keeps its own budget inside the larger organisation, rather than being folded into a general pool.

The stated reasons were the data centre market being reshaped by AI workloads, migration away from proprietary virtualization, and digital sovereignty. The release also pointed to closer work with other Linux Foundation projects, naming Linux, Kubernetes and PyTorch.

What "member foundation" means

The Linux Foundation hosts many sub-foundations, each with its own board, budget and charter, while the Linux Foundation provides the legal entity and shared services such as finance, events, legal and staff. OpenInfra joined that structure. You can see the shared services in action already: the Linux Foundation's events business ran the OpenInfra Summit alongside its cloud native and PyTorch conferences in China in 2026, and the OpenInfra site's blog includes a post from its former executive director about taking a new Linux Foundation role leading the PyTorch Foundation.

What it does not mean

It does not mean OpenStack became a CNCF project, and it does not mean Kata Containers moved into the CNCF's sandbox, incubating and graduated ladder. CNCF is a different Linux Foundation sub-foundation with its own Technical Oversight Committee and its own project maturity process. OpenInfra projects keep the governance they had.

Which projects does OpenInfra host today?

The foundation's projects page, as fetched on 24 October 2026, lists four confirmed projects and four working groups.

The working groups are the Computing Force Network working group, a Digital Sovereignty working group, an OpenInfra for AI working group and a working group that helps organisations move from proprietary virtualization platforms to OpenStack.

OpenStack

OpenStack is a collection of services that together turn racks of servers into a cloud you control. The best known are Nova (compute), Neutron (networking), Cinder (block storage), Swift (object storage), Glance (images), Keystone (identity), Ironic (bare metal), Manila (shared file systems), Octavia (load balancing) and Horizon (the dashboard). Each is a separate project team with its own Project Team Lead (PTL), but they all release together on the same six month schedule under the same name.

The foundation says OpenStack powers "75 public cloud data centers and thousands of private clouds" at "more than 15 million physical cores". Those are the foundation's own figures from its projects page; we have not checked them independently.

Kata Containers

Kata Containers runs each container, or each Kubernetes pod, inside its own lightweight virtual machine. The container sees a normal Linux environment, but under it sits a guest kernel and a hypervisor boundary instead of a shared host kernel. The architecture document in the Kata repository describes the runtime launching a configured hypervisor, which boots a VM from a guest image, after which an agent inside the guest starts the container. Kata supports multiple hypervisors, documented in its hypervisors guide.

For security teams, the attraction is isolation: a kernel bug exploited inside one Kata pod has to cross a hypervisor boundary before it reaches the host or neighbouring pods. The cost is extra memory per pod, slower start times than a plain container, and the need for hardware virtualization on the node.

StarlingX

StarlingX packages a full cloud stack for distributed edge sites where latency matters, such as telecom radio access networks and industrial control. The foundation describes it as based on "mature production software deployed in mission critical applications". It combines OpenStack and Kubernetes components with its own configuration and fault management.

Zuul

Zuul is the CI system the OpenStack project built to test changes across hundreds of repositories at once. Its core idea is speculative gating: a change merges only after it passes tests together with every change queued ahead of it, across all the repositories it depends on. That keeps the main branch of every repository releasable. Zuul's site describes it as specialising in "gating changes across multiple systems and applications".

How is the OpenInfra Foundation governed?

There are two layers: the foundation's corporate governance, and each project's technical governance. Joining the Linux Foundation changed the first layer's legal home but not the split.

The board of directors

The OpenInfra Foundation has a board of directors (the site calls it the Governing Board) that sets strategy and budget. Its chair at the time of the Linux Foundation announcement was Julia Kreger, who said in the press release that member organisations had grown by 15 percent, "including two new Platinum members", and that the community was "110,000-strong". Corporate members sit at different tiers, and the higher tiers carry board representation.

The board does not decide technical questions for OpenStack, Kata or the other projects. Those decisions sit with each project's elected technical leadership.

The Four Opens

The Four Opens are the principles every OpenInfra project is expected to follow. The OpenStack TC's reference document sets them out:

The Four Opens matter to downstream users for a practical reason. When a project's design discussions, code review and security process are public, you can audit what changed and why, rather than trusting a vendor's release notes. They also commit the projects against an open core model, so the version you can download is the version that is fully featured.

The OpenStack Technical Committee

The TC charter makes the TC responsible for "all technical matters" across OpenStack project teams and special interest groups (SIGs). Key rules:

• The TC is composed of directly elected members and is "partially renewed using elections every 6 months".
• All TC members must be individual members of the foundation.
• After each election the TC proposes one of its members as chair, and the chair recruits a vice chair.
• PTL seats are "completely renewed every development cycle", with a separate election for each project team.

So OpenStack's technical leadership turns over on the same six month rhythm as its releases. Anyone who has contributed in the relevant period can vote, which is how the Four Opens' "open community" is made concrete.

Project teams, SIGs and pop-up teams

Under the TC sit OpenStack project teams (which produce the software up to release) and SIGs, which work across projects on a theme. The Security SIG is the relevant one here: the SIG list describes it as improving the security of OpenStack projects, "maintaining the list of security notices in OpenStack" and making sure incidents are handled in a coordinated way. The VMT is described as "a more autonomous subgroup of the Security SIG".

Kata Containers governance

Kata Containers has its own governance in its community repository: an Architecture Committee elected by contributors, plus maintainers for each area of the code. It has its own Vulnerability Management Team with its own process document. Kata does not report to the OpenStack TC; it shares the foundation, not the technical governance.

How does OpenStack release and support its software?

The six month cycle and release names

The OpenStack releases site says plainly: "OpenStack is developed and released around 6-month cycles." Since 2023 releases carry a year and number (2023.1, 2023.2) as well as a name, and the names run alphabetically. The current set as published on the releases site on 24 October 2026:

Note one timing detail. On the day we checked, the releases site still listed 2025.1 Epoxy as Maintained even though its estimated move to Unmaintained (2 October 2026) had passed. Estimates move; the status column is the one that counts, and branch transitions are done by the release team when they happen. If you run Epoxy, plan as if the move is imminent.

What SLURP means

The TC's 2022 resolution on release cadence kept the six month cycle but marked every other release as a "SLURP (Skip Level Upgrade Release Process)" release. The resolution says upgrades will be supported "between SLURP releases" as well as between consecutive releases. That gives operators two valid patterns:

• Upgrade every six months, taking every release.
• Upgrade once a year, from one SLURP release to the next (for example 2025.1 Epoxy to 2026.1 Gazpacho), skipping the non-SLURP release between them.

The resolution also says a skip level upgrade job is maintained in the grenade test repository, so the skip path is tested in CI rather than just promised. The SLURP releases are the .1 releases (2023.1, 2024.1, 2025.1, 2026.1, 2027.1).

Maintained, Unmaintained, End of Life

The Project Team Guide's stable branch page defines three phases:

Two points are easy to miss. First, phases apply per project and branch, so one service can still be Maintained while another has moved on. The guide says it is "quite reasonable" for a project to stay in Maintained while all the others have transitioned. Second, Unmaintained does not mean "supported but slower". There are no point releases from those branches. If a security fix lands there, you have to build from the branch yourself.

How does OpenStack handle security?

The Vulnerability Management Team

The VMT is a small group that receives vulnerability reports for the OpenStack projects it oversees, coordinates fixes privately where that is warranted, and publishes advisories. Its process document on security.openstack.org is long and detailed; the essentials are below.

Reporting. A report "can be received either as a private encrypted email to one of the VMT members, or as a StoryBoard or Launchpad security bug". If the report arrives by email, the VMT creates a private bug and prefixes the description with an embargo reminder, "including an end date for its embargo".

Triage. The VMT adds a task for the ossa tracker. If the VMT confirms an advisory is warranted, the task moves to Confirmed. If the issue needs guidance rather than a patch, the VMT can write an OpenStack Security Note (OSSN) instead. If neither is warranted, the task is closed as Won't Fix or Invalid and the bug is made public.

Private patch development. For a private report, the patch is developed and reviewed in the private bug, "not sent to the public" code review system. Privately developed patches are pre-approved by core reviewers so they can merge quickly on disclosure day.

CVE. The VMT tries to get a CVE assigned for full traceability, "generally done as the patch gets nearer to final approval", through MITRE's CVE request form. The process notes that OpenStack's own impact classifications do not map exactly onto other scoring schemes.

Downstream notice. Distributions and vendors that ship OpenStack get advance notice so they can prepare packages. The process says the embargo for that advance notice "is kept voluntarily small (3-5 business days)".

Embargo limits. Issues that would take "more than 2 weeks" to fix, or need a complex patch, "are usually better solved in the open". If a report is held for 90 days without a fix, or significant details leak, the VMT coordinator ends the embargo. The embargo reminder template says the embargo "shall not extend past" 90 days and "will be made public by or on that date even if no fix is identified."

OSSAs and OSSNs

OpenStack Security Advisories are numbered by year (OSSA-2026-048 and so on) and listed on security.openstack.org. The list is active: when we checked, the six most recent were OSSA-2026-043 to OSSA-2026-048, covering Ironic, a Redfish driver method, Manila, Cinder, Mistral and Zaqar, mostly authorization and cross-project isolation issues. That pattern is typical of a multi-tenant cloud platform: the bug classes that matter most are the ones that let one project's user see or change another project's resources.

OSSNs cover issues that are better handled by configuration or deployment guidance, such as hardening a default setting or warning about a risky deployment pattern.

Which projects the VMT covers

The VMT only manages advisories for the repositories it oversees; its process document applies to "all Repositories Overseen". Other OpenStack deliverables still fix security bugs, but they may not get a formal OSSA. Before you rely on OSSAs for a given service, check whether its repository is on the VMT's overseen list, which OpenStack governance records.

How does Kata Containers handle vulnerabilities?

Kata's SECURITY.md is short and blunt, and it sets expectations that differ sharply from OpenStack's.

Rolling releases only. "Kata Containers is a rolling-release project: every monthly release replaces the previous one, and only the current release series receives security fixes. There are no long-term-support branches." The supported versions table lists the latest monthly release as actively maintained and "any prior release" as unsupported. The policy explains why: back-porting patches would reintroduce the maintenance burden the rolling model avoids.

Reporting. SECURITY.md asks reporters not to open a public issue or pull request, and to use GitHub's private vulnerability reporting workflow. The Kata VMT process document in the community repository describes reports being received through the Kata Containers Launchpad as private bugs. The two documents describe different intake routes; the SECURITY.md in the main repository is the newer, more prominent one, so start there and use the VMT document for how the team works a report once received.

Targets. Kata states target times rather than guarantees, and says they are independent objectives, not sequential steps:

Downstream notice. The Kata VMT sends embargo notifications to a private embargo notice mailing list "a few days in advance of public announcements". Kata says it follows the OpenSSF vulnerability handling guidelines.

Where fixes show up. Each release's GitHub notes include a Security section listing the CVEs addressed, and published advisories are on the repository's Security tab. Kata says it does "not publish separate stable-branch advisories because unsupported branches receive no fixes."

The practical consequence: if you run Kata, your patch policy is "stay on the latest monthly release". If a distribution or platform ships an older Kata, the security fixes for it come from that distributor, not from upstream.

What changes for members, projects and users after the Linux Foundation move?

For member companies

Members now join an OpenInfra Foundation that sits inside the Linux Foundation. The press release committed to keeping board positions and memberships as they were, so existing members kept their tiers. What changes is the surrounding services: shared events (the 2026 joint China event is one example), access to Linux Foundation research, training and LFX tooling, and closer adjacency to other sub-foundations such as CNCF and the PyTorch Foundation. Companies that are members of both now deal with one parent organisation.

For projects

Technical governance did not change. OpenStack's TC still runs elections every six months; PTLs are still elected each cycle; Kata's Architecture Committee still governs Kata. The release cadence resolution and stable branch policy are TC documents and are unaffected by who owns the legal entity. Project infrastructure (code review, CI, mailing lists) remained under the projects' control.

The new possibility is closer integration with Linux Foundation projects, which both sides named as a goal: Kubernetes, Linux and PyTorch. For Kata, which plugs into Kubernetes and containerd, that adjacency is direct.

For downstream users and operators

If you consume OpenStack or Kata, very little changed day to day. Your release support phases, advisory channels and embargo practices are the same. What you should re-check is the paperwork:

• Trademark and legal notices may now name the Linux Foundation. If your compliance records list the foundation as the copyright or trademark holder for a component, update the reference.
• Security contacts and URLs are still security.openstack.org and the Kata repository's Security tab. If a new channel is introduced, it will be announced by the projects themselves; do not assume a Linux Foundation wide process replaced theirs.
• Supplier and steward records. If your organisation tracks open source stewards for regulatory purposes, such as the EU Cyber Resilience Act's open source steward concept, record the Linux Foundation as the legal parent and OpenInfra as the operating foundation. We have not seen a public statement from either about formal steward designations for specific OpenInfra projects.

How does OpenInfra compare with other foundations?

This table compares structure, not quality. Each model suits different projects.

Two observations matter for supply chain work. First, in all four models the security response happens at the project level, so you track the project's advisory feed, not the foundation's. Second, OpenStack's six month cycle with 18 month maintenance and Kata's monthly rolling release sit at opposite ends of the support spectrum even inside one foundation, so "OpenInfra project" tells you nothing about support length on its own.

Step by step: check support, subscribe to advisories and evaluate Kata

Step 1: Find which OpenStack release you run

Run these on a controller node or wherever the services are installed. Adapt package names to your distribution.

# The release of the OpenStack client and the service APIs you talk to
openstack --version
openstack versions show

# Python package versions of core services, if installed with pip
pip show nova neutron cinder keystone glance 2>/dev/null | grep -E '^(Name|Version)'

# Distribution packages (Debian or Ubuntu)
dpkg -l | grep -E 'nova|neutron|cinder|keystone|glance' | awk '{print $2, $3}'

# Distribution packages (RPM based)
rpm -qa | grep -E 'openstack-(nova|neutron|cinder|keystone|glance)'

Map the service version to a series using each project's release notes on releases.openstack.org. For example, look up the nova deliverable page for the series and compare the version numbers. Container based deployments show the series in the image tag, so check your deployment tool's configuration as well.

Step 2: Check the support phase for that series

The releases page has the status column. A quick check from a script:

SERIES="2025.1"
curl -s https://releases.openstack.org/ \
  | python3 -c "import sys,re,html;t=re.sub(r'<[^>]+>',' ',sys.stdin.read());t=html.unescape(re.sub(r'\s+',' ',t));i=t.find('$SERIES');print(t[i:i+160])"

Read the result against the phase table above:

• Maintained: you can still get point releases. Keep upgrading within the series and plan the next SLURP jump.
• Unmaintained: no point releases. Fixes may land on the unmaintained/<series> branch, but you must build them yourself or rely on a distribution that backports. Treat this as a plan-the-upgrade-now signal.
• End of Life: the branch is closed. Upgrade.

Step 3: Track OpenStack advisories

Bookmark the OSSA list at security.openstack.org and check it on a schedule. A simple daily diff in CI or cron:

mkdir -p ~/ossa-watch && cd ~/ossa-watch
curl -s https://security.openstack.org/ossalist.html \
  | grep -oE 'OSSA-20[0-9]{2}-[0-9]{3}[^<]*' | sort -u > today.txt
touch seen.txt
comm -13 seen.txt today.txt   # prints advisories you have not seen yet
mv today.txt seen.txt

For each new OSSA, check the affected projects and versions against Step 1. If your distribution ships OpenStack, also follow the distribution's security announcements, because the distribution's package is what you actually install and it may carry the fix under a different version number.

Step 4: Decide whether a Kata Containers pod fits your isolation need

Start with the threat you are trying to address. Kata is a strong fit when:

• You run untrusted or multi-tenant code (CI jobs from forks, customer supplied workloads, plugin execution) and want a kernel boundary between tenants.
• You need a different guest kernel or kernel configuration from the host for a specific workload.
• Your nodes support hardware virtualization and you can spare per pod memory overhead.

Kata is a weaker fit when start time and density matter most, when nodes are themselves VMs without nested virtualization, or when the workload needs privileged host access that defeats the point of isolation.

Step 5: Check a node can run Kata

On a test node with Kata installed:

# Version of the runtime and its components
kata-runtime --version

# Checks hardware virtualization support and configuration.
# Network checks query GitHub for the latest release; skip them in air-gapped labs.
kata-runtime check --no-network-checks

The Kata README notes that running the check as root runs extra checks, including whether an incompatible hypervisor is already running, and disables network checks automatically.

Step 6: Run one workload with a RuntimeClass

With containerd configured to offer the Kata runtime handler (the Kata installation guides cover the containerd configuration), define a RuntimeClass and opt a single pod into it:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
---
apiVersion: v1
kind: Pod
metadata:
  name: isolation-test
spec:
  runtimeClassName: kata
  containers:
    - name: app
      image: registry.example.com/team/app:1.4.2
      resources:
        limits:
          memory: "512Mi"

Confirm inside the pod that the kernel differs from the host kernel (uname -r in the pod and on the node). Then measure start time and memory use against the same pod under the default runtime before you widen use.

Step 7: Put Kata on the monthly upgrade track

Because only the latest Kata release gets fixes, add the Kata release feed to whatever watches your other dependencies:

curl -s https://api.github.com/repos/kata-containers/kata-containers/releases/latest \
  | python3 -c "import sys,json;d=json.load(sys.stdin);print(d['tag_name'], d['published_at'])"

When we ran this on 24 October 2026 it returned 4.3.1 published on 21 October 2026. Compare it with kata-runtime --version on your nodes, and read the Security section of each release's notes.

Step 8: Inventory the guest image too

A Kata pod runs a guest kernel and a guest root filesystem that the Kata project builds. Those are software components with their own versions and vulnerabilities, separate from your container image. Record which Kata guest assets you deploy and update them with the runtime, not separately.

What should an operator running OpenStack in production take from all this?

Pick a cadence and write it down

The SLURP model gives you a clear choice: every six months, or once a year on .1 releases. A yearly cadence on SLURP releases fits most enterprise change processes. Whichever you choose, schedule the upgrade before the series leaves Maintained, not after. With roughly 18 months of maintenance and a yearly cadence, you have about six months of overlap to test and roll out the next SLURP release.

Treat Unmaintained as a deadline, not a support tier

Several older series (Caracal, Antelope, Zed, Yoga) sit in Unmaintained with no End of Life date set. That can look like extended support. It is not: no releases are allowed from those branches, and fixes depend on volunteers in the unmaintained core teams. If you rely on one, you rely on your own builds or a distributor.

Know what your distribution adds

Many operators run OpenStack through a commercial or community distribution, a deployment project, or a managed private cloud. Distributions can offer longer support than upstream by backporting fixes themselves. That is a real service, but it means the version strings, advisory numbers and timelines you see come from the distributor. Ask each supplier three questions: which upstream series their release tracks, how long they patch it after upstream stops, and how they map OSSAs to their own advisories.

Watch the isolation bug class

The recent OSSA list is dominated by authorization and cross-project issues. That is where a private cloud's risk concentrates. Keep policy files (the policy.yaml overrides for each service) under version control, test them after every upgrade, and review OSSNs for hardening guidance.

Remember the Python underneath

Every OpenStack service is a Python application that pulls in dozens of third party libraries, governed by the shared openstack/requirements project and its upper constraints file. Those libraries have their own vulnerabilities and their own release schedules, and an OSSA will not tell you about them. Container based deployments bundle them into images. Treat those images and virtual environments as software you ship, with an inventory and a patch path, separate from the OpenStack series itself.

Common mistakes

• Assuming the Linux Foundation move changed project security processes. It did not. OpenStack reports still go to the OpenStack VMT and Kata reports to Kata's VMT.
• Reading Unmaintained as supported. Releases are not allowed from Unmaintained branches. If your series is Unmaintained, plan the upgrade.
• Jumping from a non-SLURP release across two releases. Skip level upgrades are tested between SLURP releases. Going from a .2 release to the release after next is not the supported skip path.
• Running an old Kata release because "it is stable". Kata has no long term support branches. Any release other than the latest is unsupported upstream.
• Watching only OSSAs. OSSAs cover VMT managed OpenStack projects. They do not cover your Python dependencies, your container base images, your host kernel, or OpenStack deliverables outside VMT oversight.
• Treating the foundation's numbers as independent data. Adoption figures on foundation pages are the foundation's own claims. Useful context, not audited statistics.
• Ignoring the Kata guest kernel. It is a separate kernel with its own patch stream. Updating the host kernel does not update it.
• Assuming one foundation means one support policy. OpenStack and Kata sit in the same foundation with completely different release and support models.

FAQ

What is the OpenInfra Foundation?

It is the non-profit foundation that hosts OpenStack, Kata Containers, StarlingX and Zuul. It began as the OpenStack Foundation, renamed itself when it took on other projects, and is now part of the Linux Foundation.

When did the OpenInfra Foundation join the Linux Foundation?

The intent was announced on 12 March 2025, after unanimous approval by both boards. OpenInfra's executive director announced in a blog post dated 3 June 2025 that the move was official and that members had voted.

Is OpenStack now a CNCF project?

No. CNCF and OpenInfra are separate sub-foundations of the Linux Foundation. OpenStack keeps its Technical Committee and its own governance under OpenInfra.

What projects does the OpenInfra Foundation host?

Its projects page lists Kata Containers, OpenStack, StarlingX and Zuul as confirmed projects, plus working groups on the Computing Force Network, digital sovereignty, AI workloads and migration from proprietary virtualization.

How long is an OpenStack release supported?

Each release is Maintained for about 18 months, with point releases. It may then become Unmaintained, where no releases are allowed, and finally End of Life. Check the releases site for your series' current status.

What is an OpenStack SLURP release?

SLURP stands for Skip Level Upgrade Release Process. Every other OpenStack release (the .1 releases) is a SLURP release, and upgrades between consecutive SLURP releases are supported and tested, so you can upgrade once a year.

How do I report a vulnerability in OpenStack?

Send a private encrypted email to a VMT member or file a private security bug in the project's tracker, as the VMT process on security.openstack.org describes. The VMT coordinates the fix and publishes an OSSA or OSSN.

How long are OpenStack security embargoes?

Advance notice to downstream stakeholders is kept to 3 to 5 business days. Issues that would take more than two weeks to fix are usually handled in public, and no embargo should run past 90 days.

Does Kata Containers have long term support releases?

No. Kata is a rolling release project with monthly releases. Only the latest release gets security fixes, and older releases are unsupported upstream.

Did anything change for OpenStack users after the Linux Foundation move?

Day to day, very little. Release cadence, support phases, the TC and the security process are unchanged. Legal and trademark references may now point to the Linux Foundation.

Where Safeguard fits

Safeguard does not manage OpenStack clouds, hypervisors or Kubernetes runtimes, and it does not scan host kernels or firmware. The fit is narrower and practical: OpenStack services and the tooling around Kata are built from open source packages, and those packages ship inside container images and Python environments that you build and deploy. Safeguard can scan those repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), match components against vulnerability databases, show which projects contain a given component and version, rank findings with reachability analysis and enforce policies and gates. The upgrade itself, from one OpenStack series to the next or from one Kata release to the next, is still your operations team's work.

An OpenStack deployment or a Kata based platform is a large stack of open source components, from Python libraries in each service image to the tools that build the guest image, and each one is pulled in again every time you rebuild. Foundation governance tells you when the project ships a fix; the steps below are about how quickly that fix, and the fixes in all the dependencies around it, reach the images you run.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a vulnerable lodash version in a repository; the assistant reads the finding and advisory, asks before each command, edits the manifest, runs install and tests with approval and pushes nothing. The same flow applies to the Python requirements behind an OpenStack service image or the tooling repository that builds your Kata guest assets.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. For an OpenStack team, that is how you would scan the images your deployment tool builds without sending source anywhere first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. An operator could then ask about findings across the repositories that build an OpenStack or Kata platform from the same conversation where they plan the upgrade.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard or read the CLI documentation.

Quick check

Sources

• Linux Foundation: Open Infrastructure Foundation Board Announces Intent to Join the Linux Foundation (12 March 2025)
• Linux Foundation press releases
• OpenInfra Foundation: OpenInfra joins the Linux Foundation (blog, 3 June 2025)
• OpenInfra Foundation home page
• OpenInfra Foundation: about
• OpenInfra Foundation: projects
• OpenInfra Foundation: governing board
• OpenStack releases and series status
• OpenStack Project Team Guide: stable branches
• OpenStack TC resolution: release cadence adjustment (SLURP)
• OpenStack Technical Committee
• OpenStack Technical Committee charter
• OpenStack: the Four Opens
• OpenStack special interest groups
• OpenStack Security
• OpenStack Vulnerability Management Process
• OpenStack Security Advisories list
• Kata Containers
• Kata Containers README
• Kata Containers security policy (SECURITY.md)
• Kata Containers architecture
• Kata Containers community and governance
• Kata Containers VMT process
• Kata Containers latest release (GitHub API)
• StarlingX
• Zuul
• CNCF TOC project process
• Apache Software Foundation: how it works
• Linux Foundation: about

Last reviewed: 24 October 2026. OpenStack series status and Kata release numbers change often; check releases.openstack.org and the Kata releases page before planning an upgrade.