[Incubation] KubeArmor Incubation Application

[HighnessAtharva]

Review Project Moving Level Evaluation

• I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

KubeArmor Incubation Application

v1.6

This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/kubearmor/KubeArmor (and the wider github.com/kubearmor organization — see the Related Repositories section of the README)
Project Site: https://kubearmor.io | Documentation: https://docs.kubearmor.io/kubearmor/
Sub-Projects: Listed in README → Related Repositories and in GOVERNANCE.md § Subprojects.
Communication: #kubearmor on CNCF Slack · GitHub Discussions · biweekly community call (zoom.kubearmor.io, minutes)

Project points of contact:

• Rahul Jadhav — @nyrahul — nyrahul@gmail.com
• Atharva Shah — @HighnessAtharva
• Barun Acharya — @daemon1024 — barun1024@gmail.com
• Achref Ben Saad — achref9612@gmail.com
• General project alias — support@kubearmor.io

Continuity with the prior application:
This issue continues the previous incubation application cncf/toc#1326 which was closed Not Ready — Will Return via cncf/toc#1757 on 2025-06-20. The TOC's guidance was a 6–12 month window to (a) close the eight identified blockers and (b) demonstrate adherence to the new governance in practice. This reapplication is filed inside that window with evidence of both. The technical, contributor-community, and ecosystem sections that the DD accepted are reused below; sections that were unchecked in the DD are answered with new evidence from the past 12 months.

• (Post Incubation only) Book a meeting with CNCF staff — not applicable at application time.

---

Incubation Criteria Summary for KubeArmor

Application Level Assertion

• This project is currently Sandbox, accepted on 2021-11-16 (sandbox issue #226), and applying to Incubation.
• This project is applying to join the CNCF at the Incubation level.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity (current public list at ADOPTERS.md; a supplementary list of organizations in production use will be provided privately to the assigned DD reviewer per the adopter definition FAQ):

Public adopters (with form of use):

• AccuKnox — KubeArmor as part of enterprise hardening, Zero Trust posture, application behavior at scale.
• Open Horizon (LF Edge) — KubeArmor natively integrated as the default security engine.
• Intel Smart Edge — KubeArmor integration available on Intel Smart Edge.
• 5G-SBP / SEDIMENT — KubeArmor integration for securing SEDIMENT, demonstrated in the 5G Super Blueprint.
• IDSM Automotive — KubeArmor for securing ECU in IDSM Automotive workloads.
• R6 Security — KubeArmor integrator for R6's Automated Moving Target Defense operator.
• AnyLog — KubeArmor natively integrated in AnyLog for distributed event visualization and alerting.

Note to TOC reviewer: Additional direct adopters running KubeArmor in production, including ones not yet listed in ADOPTERS.md for confidentiality reasons, will be submitted via the Adopter Interview Questionnaire and surfaced to the assigned reviewer privately. We acknowledge that the previous DD's adoption blocker is the most consequential remaining item and we are addressing it directly.

---

Application Process Principles

Suggested

• Engage with domain-specific TAG(s) to present the technical architecture of the project.
  • Most recent: TAG Security presentation on 2024-10-09, with TAG recommendation in comment #2403861372.
  • Prior: TAG Policy WG, 2021-06-09 (recording).

Required

• Complete a General Technical Review (GTR).

  • Status: This is a net-new v1.6 requirement that did not exist when cncf/toc#1326 was filed. We are working towards completing the GTR in parallel with the DD and will link the GTR document back from this issue once filed.

• Complete a Governance Review.

  • Status: We are working towards submitting the new GOVERNANCE.md to the Project Reviews subproject for formal Governance Review. The governance was written to address each of the unchecked items raised in the prior DD (cncf/toc#1326) and aligned with the CNCF vendor-neutrality and project lifecycle guidance.

• All project metadata and resources are vendor-neutral.

  • Evidence (new since the prior DD):
    • The kubearmor.io website footer no longer carries "Powered By AccuKnox". A new Community page was added that links directly to governance, maintainers, CoC, release process, and security policy — see the commit.
    • The ModelArmor link issue noted in the prior DD was resolved on 19 May 2025 (acknowledged in the DD itself).
    • The security alias has moved from support@accuknox.com to support@kubearmor.io (see SECURITY.md and GOVERNANCE.md § SRC).
    • Vendor-neutrality language is now in the governance document itself (§ Vendor neutrality).
  • Known remaining items: AccuKnox-driven framing and the Travis CI dependency in policy-templates are being removed in a follow-up PR; the in-flight work is tracked and a status will be shared on the DD.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

  • Acknowledged during Sandbox application on 2021-11-16 (sandbox#226). The Sandbox-separation concern (vendor-owned security email) raised in the prior DD has now been resolved — see the security-alias change above.

• Due Diligence Review.

  • This issue is the start of the DD; resolution of concerns and public comment will satisfy this item.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

  • Getting Started / Deployment Guide, Use Cases, Policy specifications, Full documentation site.

---

Governance and Maintainers

Suggested

• Complete a Governance Review with the Project Reviews subproject.

  • In progress, see above.

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

  • The original GOVERNANCE.md (June 2022, commit 59440c05) was a 45-line minimal document, as flagged by the prior DD.
  • The new GOVERNANCE.md was merged on 2026-06-30 via PR #2719 (commit 27ded4a9). It expands on every DD-flagged area.
  • A follow-up governance commit iterated on the vendor-neutrality wording. Iteration history is visible via git log GOVERNANCE.md.

• Clear and discoverable project governance documentation.

  • GOVERNANCE.md is linked from the README and surfaced on the website Community page, addressing the prior DD's discoverability finding.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

  • GOVERNANCE.md describes the actual mechanism currently in use: biweekly community calls (linked in README and CONTRIBUTING.md), lazy consensus on PRs, and Maintainer voting via PR for governance, role, and release decisions.
  • The Maintainers list and CODEOWNERS reflect actual reviewers/approvers; reconciliation of one historical inactive CODEOWNERS entry is tracked in MAINTAINERS.md TODOs and will be resolved before DD close.

• Governance clearly documents vendor-neutrality of project direction.

  • GOVERNANCE.md § Vendor neutrality covers affiliation disclosure, communication-channel neutrality, and branding rules. Maintainer affiliations are listed inline in MAINTAINERS.md.

• Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

  • GOVERNANCE.md § Decision making defines three vote classes (Ordinary, Sensitive, Structural) with thresholds and voting windows.
  • § CNCF requests and integrations covers how CNCF interactions are decided.
  • § Changing this document describes the structural-vote process for governance changes.
  • CONTRIBUTING.md covers contribution acceptance.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

  • GOVERNANCE.md § Sub-teams defines the sub-team framework. The Security Response Committee (SRC) is the first sub-team chartered, with explicit onboarding (nomination → second → shadow period) and offboarding rules. See § Security Response Committee (SRC).

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

  • GOVERNANCE.md § Roles defines five tiers: Community Member, Contributor, Reviewer, Maintainer, Emeritus Maintainer.
  • § Inactivity and removal covers offboarding and Emeritus transition, including quarterly activity review against CNCF DevStats.

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

  • Status: We are working towards this. Reconciliation of the inactive CODEOWNERS entry flagged by the prior DD is the first demonstrable lifecycle event under the new governance; the resulting PR will be linked here. Additional historical maintainer transitions will be backfilled into the Emeritus section of MAINTAINERS.md as part of the same exercise.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

  • GOVERNANCE.md § Subprojects classifies repositories into core subprojects (governed by this document) and community subprojects (own MAINTAINERS, autonomous on technical decisions, bound by CoC and vendor-neutrality). The classification table for each repository under github.com/kubearmor is being populated and will be linked from README § Related Repositories before DD close.

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • MAINTAINERS.md lists eight Maintainers with GitHub handles and company affiliations. Domain of responsibility is documented via CODEOWNERS. A general project contact alias is support@kubearmor.io.

• A number of active maintainers which is appropriate to the size and scope of the project.

  • Eight Maintainers from four organizations (AccuKnox, CERN, Dankook University, Independent). The 12-month commit and review activity is visible on the contributor graph and on CNCF DevStats.
  • 20+ releases shipped in the last 12 months (release list) demonstrating sustained operational engagement.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

  • The new governance defines explicit Maintainer and Reviewer tiers; CODEOWNERS is being aligned to those tiers as part of the Reviewers reconciliation work mentioned above.

• Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

  • CODE_OF_CONDUCT.md adopts the canonical CNCF Code of Conduct without modification. The wrapper file adds only the project-side reporting path. The website CoC has been updated to match (commit). This closes the prior DD blocker that the modified CoC and broken CNCF link were in conflict with the canonical version.

• CNCF Code of Conduct is cross-linked from other governance documents.

  • Linked from GOVERNANCE.md, CONTRIBUTING.md, README.md § Community & Governance, website Community page, and the website footer.

• All subprojects, if any, are listed.

  • README § Related Repositories lists every active repository under github.com/kubearmor with a one-line description, grouped into Core, Integrations, Deployment, and Specialised. Subproject classification (core vs community) is being added inline.

---

Contributors and Community

Suggested

• Contributor ladder with multiple roles for contributors.
  • GOVERNANCE.md § Roles defines a five-rung ladder with explicit numeric thresholds (Reviewer = 3-month minimum + 5 reviews + 5 authored PRs; Maintainer = 3-month minimum at Reviewer + 30 authored/reviewed PRs; both sponsored by an existing Maintainer).

Required

• Clearly defined and discoverable process to submit issues or changes.

  • CONTRIBUTING.md, Development Guide, Testing Guide.

• Project must have, and document, at least one public communications channel for users and/or contributors.

  • Multiple — see below.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

  • Listed on the website Community page: general contact support@kubearmor.io, #kubearmor on CNCF Slack, GitHub Discussions, GitHub Issues, YouTube channel, @KubeArmor on X/Twitter, LinkedIn, community.cncf.io/kubearmor, and the Kubernetes & Cloud Native Security India meetup.
  • Non-public channels: a private CoC-and-security maintainer thread reachable via support@kubearmor.io (used for sensitive votes per GOVERNANCE.md). No other non-public channels are in use.

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

  • Biweekly community call: zoom.kubearmor.io, meeting minutes, Google Calendar invite, ICS file.

• Documentation of how to contribute, with increasing detail as the project matures.

  • CONTRIBUTING.md covers code, docs, policy templates, blogs, community work, and mentorship (GSoC, LFX).

• Demonstrate contributor activity and recruitment.

  • 145 contributors to the main repository (contributor graph). From the prior DD (March 2025) to today, contributors have moved from ~150 cited contributors to 145 active in the contributor list with sustained PR throughput.
  • 600+ Slack members, 250+ YouTube subscribers.
  • GSoC and LFX Mentorship cohorts each year (details).

---

Engineering Principles

Suggested

• Roadmap change process is documented.

  • GOVERNANCE.md § Roadmap and contribution acceptance describes how features, bugs, and proposals enter and progress through the KubeArmor projects board, including the threshold at which a written proposal is required.

• History of regular, quality releases.

  • 20+ releases in the last 12 months (release list) — v1.6.6 through v1.7.4-rc2. This is a clear upgrade from the "approximately twice annually" cadence flagged in the prior DD.
  • Release quality is gated by the per-release release checklist issues — most recent example #2704 (v1.7.4). The full process is documented in RELEASES.md.

Required

• Document project goals and objectives that illustrate the project's differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

  • Differentiation document.

• Document what the project does, and why it does it - including viable cloud native use cases.

  • Use cases overview, Hardening Guide, Least Permissive Access, Workload Visibility, Deployment Models.

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

  • KubeArmor Projects board. Process documented in GOVERNANCE.md (link above).

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

  • Architecture overview in the README, KubeArmor Design PDF, docs.kubearmor.io.

• Document the project's release process.

  • RELEASES.md is a new document (merged via PR #2719 on 2026-06-30) that addresses the prior DD's "no documented release process" finding. It covers versioning, monthly cadence, ad-hoc/security releases, branching, support window, the rotating Release Manager role, RC flow, the release checklist, release notes shape, and coordinated releases across the charts and kubearmor-client repositories.

---

Security

Suggested

• Complete a joint security assessment with TAG Security and Compliance.
  • Status: We are working towards this. The Security Self-Assessment (see Required item below) is the precursor and is actively being driven to merge.

Required

• Clearly defined and discoverable process to report security issues.

  • SECURITY.md — vulnerability reports go to support@kubearmor.io (the project-owned alias; the prior support@accuknox.com vendor alias is no longer in use). GitHub native security advisories are also enabled.

• Enforcing Access Control Rules to secure the code base against attacks.

  • Branch protection enforced on main requiring at least one Maintainer review for merge. 2FA enforced for all members of the GitHub organisation. Access-control requirements are documented in the Maintainer responsibilities section of GOVERNANCE.md.
  • The prior DD cited an OpenSSF Scorecard signal about "last push approval" on main. We have reviewed the current Scorecard report at securityscorecards.dev/viewer and the configuration matches the CNCF security guidelines on access management. A short written rebuttal will be appended to this issue if the DD reviewer raises Scorecard again.

• Document assignment of security response roles and how reports are handled.

  • SECURITY.md + GOVERNANCE.md § Security Response Committee (SRC) define the SRC sub-team with explicit onboarding (nomination → second → shadow), offboarding, and the project security alias support@kubearmor.io. The SRC roster will be populated as the first sub-team formed under the new governance and linked here when filed. The Kubernetes SRC model (onboarding/offboarding) is the explicit template.

• Document Security Self-Assessment.

  • Self-assessment is filed in cncf/tag-security#1430. The PR is currently open and we are actively pushing it to merge.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

  • OpenSSF Best Practices badge for KubeArmor (project 5401) — passing.

---

Ecosystem

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.).

  • ADOPTERS.md.

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters).

  • Status: We are actively working to update ADOPTERS.md and to surface additional production-capacity adopters. Each confirmed adopter will be submitted via the Adopter Interview Questionnaire and confirmed privately to the DD reviewer to satisfy the CNCF adopter definition. Status updates will be posted to this issue as adopters are confirmed.

• TOC verification of adopters.

  • Tied to the item above.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

  • CNCF and adjacent: Kubernetes (CRD-driven policy model), OpenTelemetry, Helm charts, Prometheus exporter, Kubernetes PolicyReporter CRD.
  • Non-CNCF: Open Horizon, Rancher UI extension, Grafana data source, Kafka client, GitHub Action, Packer plugin, Nephio integration, LF 5G Super Blueprint, Red Hat Certified Operator catalog.

---

Additional Information

Continuity with the prior cycle. This application reopens the conversation closed by cncf/toc#1326 and cncf/toc#1757. Of the eight Final-Assessment blockers identified in the prior DD, the project's status against each one is:

#	Blocker	Status today
1	Vendor neutrality (separate from AccuKnox)	Largely resolved. Website, governance, and security alias all updated. Policy-templates cleanup is the remaining in-flight item.
2	Code/doc ownership matches governance	Resolved at the documentation level (new GOVERNANCE.md + Maintainers tiers); CODEOWNERS reconciliation of one historical inactive entry is in flight as the first demonstrable governance event.
3	Adopt CNCF Code of Conduct	Resolved. CoC replaced with canonical CNCF CoC in both KubeArmor and kubearmor.io repos.
4	List subprojects	Resolved at the inventory level (new README Related Repositories table). Core vs. community classification per repo is in flight.
5	Document release process	Resolved. New RELEASES.md.
6	Access control enforcement	Project configuration unchanged from the prior cycle; the prior DD noted the Scorecard signal may be inaccurate. Rebuttal available on request.
7	Security response roles + non-vendor alias	Resolved. SRC sub-team chartered in GOVERNANCE.md; security alias moved to support@kubearmor.io.
8	≥3 independent direct adopters in production	We are actively working to update ADOPTERS.md and confirm production-capacity adopters; status updates will be posted to this issue.

Net-new in the past 12 months (since the DD closed): GOVERNANCE.md rewrite (PR #2719), MAINTAINERS.md with tiers, RELEASES.md, canonical CNCF CoC, README Community & Governance + Related Repositories, support@kubearmor.io alias, website Community page, 20+ releases shipped, contributor count grown to 145.

Reviewer access. For follow-up questions or private adopter verification, the assigned DD reviewer can reach the Maintainers at support@kubearmor.io or via the points of contact listed at the top of this issue.

[angellk]

DD Triage

Welcome back — this is KubeArmor's second incubation application, following the prior DD (#1326) which closed Jun 2025 with a recommended 6-12 month window to address blockers.

Required items complete:

• SSA ✓
• OpenSSF Best Practices passing badge ✓
• Vendor neutrality asserted with updated governance ✓
• Adopter questionnaire: 10 responses submitted ✓

Required items in progress:

• GTR (General Technical Review): Unchecked — the project acknowledges this is a new v1.6 requirement and is working on it. The DD cannot complete without this.
• Governance Review: Unchecked — governance has been updated to address prior DD feedback. Recommend submitting to the Project Reviews subproject.

Suggested items unchecked:

• Maintainer lifecycle with outcomes — demonstrate a maintainer addition or removal through the documented process
• Joint security assessment with TAG Security

LFX org dependency: 73% — moderate concentration (AccuKnox dominant). Better than several applications in this triage batch. The DD will evaluate vendor neutrality and governance mechanisms.

Prior DD feedback: The application references the prior DD (#1326, PR #1757) and describes governance updates to address those blockers. The DD will verify these changes.

The GTR needs to be completed and submitted before the DD can proceed. Please follow up here when it's ready.