THE LINUX FOUNDATION PROJECTS
Monthly Archives

July 2026

Jul 22 2026

Civil Infrastructure Platform Achieves OpenSSF Best Practices Gold Badge

By Announcement, Blog, Press Release

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.

Jul 08 2026

“Trust in Longevity”: How Cybertrust leverages CIP to Provide Enterprise-Grade Support and Security for Industrial-Grade Linux Distributions.

By Announcement, Blog, In the News

By Hirotaka Motai, Cybertrust Japan.

We develop and provide “EMLinux,” an industrial-grade commercial Embedded Linux, for the Japanese manufacturing industry and critical infrastructure (such as industrial controllers, professional communication equipment, and medical devices). EMLinux is based on the achievements of CIP. To maintain a robust common foundation for industrial Linux, we participate in the CIP project and engage in collaborative development. On the occasion of the 10th anniversary of the CIP project, we would like to share the background of our participation, our gratitude to CIP, and our next 10 years together.

Why We Joined CIP

At that time, while expanding our embedded Linux customization business, we strongly felt the seeds of need for “long-term security support” in the critical infrastructure sector.

Japanese embedded products are characterized by high quality and extremely long product lifespans. On the other hand, because stable operation was the top priority, companies previously hesitated not only to install disruptive OS major version upgrades but also to apply security patches after shipment. However, as security breaches targeting embedded systems and OT systems became real threats around the world, many Japanese companies found it necessary to apply security patches continuously. Especially for critical systems, “Linux that can be securely and continuously used for a long time” was indispensable, rather than Linux that focuses on bleeding-edge technology.

In the face of these realistic challenges in the manufacturing industry, CIP’s activities, which advocate 10 years of super-long-term support, were exactly the answer we were looking for. Supporting the strength of Japanese manufacturing—”high quality and long lifespan”—from the open-source layer was the primary reason why we decided to join CIP.

Gratitude to CIP

CIP realizes the “super-long-term safety and reliability” essential for critical infrastructure in a sustainable way. For us, CIP’s activities for the “super-long term,” such as the Linux kernel and Debian LTS, sustainably supports the Linux ecosystem and its software supply chain. Therefore, these efforts constitute an indispensable core of our products.

In the manufacturing and critical infrastructure sectors, where device lifecycles are long, it is essential to continue cooperating with the open-source community to keep responding to security threats. By participating and working within CIP, we can sustainably provide 10-year-scale vulnerability response and technical support, which would be difficult on our own.

In addition, CIP’s “Upstream First” policy is also important. By minimizing custom changes and returning fixes to the Linux community, our achievements can be widely adapted as global standards. As a result, it helps build a positive cycle that improves the stability and quality of our own products. It is of great value for us to work under the policy of emphasizing continuity with the upstream community. This allows us to reflect our own needs and knowledge back into the upstream.

The Next 10 Years with CIP

Beyond providing the SLTS kernel, we expect CIP to drive a robust software supply chain that ensures Linux can be used stably over the long term.

CIP’s “Upstream First” policy plays an important role in enhancing the sustainability of the entire ecosystem. This is achieved not only through code contributions, but also through checking quality via automated testing and supporting related OSS communities. As part of this role, we have been strongly committed to activities such as participating in the “cip-kernel-sec” activity as a maintainer,  which collects and analyzes vulnerability information, and building a test environment linked with “KernelCI”,  which is an open automated testing foundation for the Linux kernel. These efforts, which support long-term support from both security and quality perspectives, make the community’s achievements even stronger. In the coming years, it will be important for CIP members’ activities to encompass the entire software supply chain and to build and maintain a framework that continuously ensures long-term reliability.

Even 10 years from now, we will continue to develop “Linux that can be used with peace of mind over the long term,” just as we do today. This journey with CIP toward that goal is the very mission of Cybertrust, supporting the foundation of Japan’s digital infrastructure.