CNCF maturity levels describe adoption and project health. Sandbox projects are early and experimental, incubating projects have successful production use by a relatively small group of users, and graduated projects are stable and widely adopted. None of the levels is a security audit result.
The three levels as CNCF describes them
On its project metrics page, CNCF says projects have one of three maturity levels, mapped to the Innovators, Early Adopters and Early Majority groups in the Crossing the Chasm model:
- Sandbox: early, experimental projects not yet broadly proven in production, at the leading edge of technology.
- Incubating: projects with successful production use by a relatively small group of users and a solid contributor base.
- Graduated: projects that are stable, widely adopted and production ready, attracting thousands of contributors.
CNCF says the level signals which types of enterprises should adopt each project. That is an adoption framing.
How a project moves up
Projects advance by showing sustainability to the Technical Oversight Committee. That includes adoption, a healthy rate of change, and committers from multiple organizations. They must also adopt the CNCF Code of Conduct and achieve and maintain the Best Practices Badge. The page links to graduation criteria for full detail.
Two of those are directly useful to a buyer. Committers from multiple organizations lowers the chance a project disappears if one company leaves. The badge means the project has answered a set of practice questions, though it is self certified, as covered in OpenSSF badge, Scorecard and Baseline compared.
What to infer and what not to
You can reasonably infer:
- Sandbox: expect change, rough edges and a smaller user base. Pilot, do not depend on it for critical paths without a fallback plan.
- Incubating: real production use exists, but ask who uses it and at what size.
- Graduated: broad use and governance maturity, so migration risk is lower.
You cannot infer that the code is free of vulnerabilities, that your configuration is safe, or that a project has been independently audited. A security audit is a separate fact you check per project.
Practical use in selection
Make maturity a filter on risk tolerance. A team with a thin platform group should lean toward graduated projects, because upgrades and community answers are easier to find. A team exploring a new area can accept sandbox projects with clear exit plans.
Then check what maturity does not tell you: release cadence, how security issues are reported, and whether the project supports your environment.
A note on vendor claims
Product pages sometimes mention that a tool is built on, or integrates with, a CNCF project of a given level. Treat that as a statement about the underlying project, not about the product wrapped around it. A graduated project can sit inside a product with its own configuration, defaults and extra code that CNCF never assessed. Ask which parts are the project and which parts are the vendor's own work.
Where Safeguard fits
Safeguard offers dependency scanning and SBOM generation that include the open source components you pull in, graduated or not. The free scan at gold.safeguard.sh/scan shows what it finds.
Quick check
Is a graduated project audited?
CNCF's description of graduation covers adoption, governance and project health. It does not describe a security audit as a requirement on that page.
Sources
Last reviewed: 19 October 2026.
