Author: Kamlesh Gurudasani, Texas Instruments
The Achievement
In February 2026, the Civil Infrastructure Platform (CIP) project earned the OpenSSF Best Practices Gold Badge, the highest level in the Open Source Security Foundation’s best practices certification program. The achievement came in CIP’s tenth anniversary year and puts CIP in a small group of around 80 projects worldwide that hold Gold, including the Linux Kernel, curl, and the Zephyr Project.
You can view CIP’s badge at: https://www.bestpractices.dev/projects/10564
The OpenSSF Best Practices Badge program (formerly the CII Best Practices Badge under the Linux Foundation’s Core Infrastructure Initiative) gives open source projects a structured way to demonstrate their security and development practices. It defines three levels: Passing, Silver, and Gold, each building on the last, covering everything from security and testing to governance and contributor practices.
Passing captures what most projects already do: documenting how to report vulnerabilities, adding tests alongside new functionality, and using static analysis tools. Silver and Gold go further. Gold in particular addresses the structural health of a project: a bus factor of at least two, at least 50% of proposed changes reviewed by someone other than the author before release, reproducible builds, and security hardening headers on all project websites. These are not documentation tasks. They are commitments about how the project operates.
Out of thousands of registered projects, only around 80 have completed all three levels, covering more than 180 criteria in total.´
Its Significance
Yoshitake Kobayashi, CIP TSC Chair, As the foundation for critical infrastructure and industrial systems, CIP prioritizes security above all else for Linux in industrial-grade applications. We are delighted that the OpenSSF has recognized this commitment and helped make our security practices visible to the broader community.
David A. Wheeler, Director of Open Source Supply Chain Security at the Linux Foundation, has described Gold badge projects as those that have “implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found.” For a project whose kernels may power industrial systems for the next decade or longer, all three of those qualities matter.
CIP was created to address a real gap in civil infrastructure: power generation, railways, factory automation, and healthcare systems need software they can trust over very long timescales. The systems that run on CIP kernels are not commodity applications. They are control systems, safety systems, and communications infrastructure. The consequences of a security failure are not measured in user complaints or business disruption, but in physical and societal risk.
For OEMs, system integrators, and operators considering CIP for critical deployments, the Gold badge offers something tangible: an externally defined, publicly verifiable standard against which anyone can evaluate CIP’s development practices. It is not a claim CIP makes about itself. It is a structured framework that anyone can inspect, verify, and rely on.
The timing is also relevant to the regulatory environment. The EU Cyber Resilience Act and industrial standards like IEC 62443 increasingly require documented evidence of secure development practices, not just secure code. The OpenSSF badge is a recognized framework for providing that evidence.
The real goal was never the badge. It was to verify and strengthen the practices behind software that people rely on daily. The badge is the record of that work.
The Work Involved
Getting to Gold required going through all 180+ criteria across the three badge levels systematically. Each one was evaluated against CIP’s actual practices, documented with evidence, and in cases where gaps existed, addressed directly.
The work covered several areas.
Security: Verifying CIP’s use of cryptographic algorithms from the Linux kernel subsystem (AES, RSA, SHA-2/3, ChaCha20), documenting the release signing process using GPG, confirming HTTPS delivery, and confirming timely CVE response through cip-kernel-sec, the project’s CVE tracking and triage system. Vulnerability response processes across all five SLTS kernel series were reviewed and documented.
Static and dynamic analysis: CIP inherits static analysis from upstream: Coverity, sparse, and smatch run on the Linux kernel codebase that CIP backports from. On top of that, Coccinelle scripts and checkpatch.pl run on CIP patches directly. For dynamic analysis, KernelCI handles boot and functional testing, LAVA runs tests on real hardware, and KASAN, UBSAN, and KMSAN provide runtime memory safety checking. The upstream Linux kernel also runs syzkaller fuzz testing on code shared with linux-cip.
Governance and contributor practices: Confirming that patches were being reviewed by more than one person before merging, documenting the bus factor across kernel maintainers and TSC members from multiple member companies, verifying Developer Certificate of Origin (DCO) requirements, and documenting the governance structure across CIP’s working groups.
Build and reproducibility: Reviewing the build process across the linux-cip kernel tree and the supporting repositories (isar-cip-core, cip-testing, and cip-kernel-sec) and documenting reproducibility practices.
Documentation and project health: Checking that contribution guidelines, security documentation, project roadmap, and relevant policies were publicly available and current.
CIP’s practices were also compared against reference projects including the Linux Kernel, Kubernetes, and LLVM, to understand where the bar was set and where additional work was needed.
Impact on the CIP Ecosystem
CIP now stands alongside the Linux Kernel, curl, and the Zephyr Project as one of the very few open source infrastructure projects to hold Gold.
For the industrial community that builds on CIP kernels, the badge strengthens the case for CIP as a trusted platform, one where the practices behind the software can be evaluated, not just the software itself. For CIP member companies, it gives them a concrete, externally defined data point when discussing their security posture with customers and regulators. For the broader open source infrastructure community, it shows that a kernel project with CIP’s scope and complexity can meet the most demanding open source security standards.
CIP intends to keep pace as the OpenSSF criteria evolve, maintaining and building on the practices that earned this recognition.
Get Involved
If you are building products on CIP kernels, or considering CIP for your next platform, we encourage you to explore the project. The CIP kernel source is at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git. Supporting repositories for build, testing, and security are at https://gitlab.com/cip-project/cip-kernel. To join the community or learn more, visit https://www.cip-project.org or subscribe to the cip-dev mailing list at https://lists.cip-project.org/g/cip-dev.
The Civil Infrastructure Platform is a Linux Foundation project.