Civil Infrastructure Platform: How Industrial Linux Stays Patched

The Civil Infrastructure Platform (CIP) is a Linux Foundation project that maintains Linux for machines that run for decades: railways, power grids, factories and medical equipment. It keeps Super Long-Term Support kernels and a Debian based core package set patched for at least ten years, and documents its process against IEC 62443.

CIP turned ten in 2026. To mark it, LF Research published a report on the project, and the Linux Foundation blog summarised it on 6 October 2026. This guide starts from that post, then checks the project's own pages, kernel.org and the ISA summary of IEC 62443 to show what CIP delivers, where its limits are, and what an industrial team still has to do itself.

Key takeaways

• CIP exists because of a gap in time. Upstream Linux long-term kernels get a few years of fixes, while a signalling system or a substation controller may stay in service for 20 to 50 years, according to CIP's kernel working group.
• The project maintains five Super Long-Term Support (SLTS) kernel series today: 4.4, 4.19, 5.10, 6.1 and 6.12. Each targets at least ten years of support, with the newest, 6.12, planned until 2035.
• CIP Core is a small, curated set of Debian packages, maintained for ten years or more by extending Debian's LTS and Extended LTS work, and built into reproducible reference images with the Isar build system.
• Security work is organised around IEC 62443-4-1 (secure development process) and IEC 62443-4-2 (technical requirements for components). CIP says it completed a 62443-4-1 conformance assessment in August 2024 and a 62443-4-2 assessment in February 2026. That helps product makers. It does not certify your product.
• CIP tracks kernel CVEs per branch in the public cip-kernel-sec repository and relies on the Debian Security Tracker for package CVEs.
• An SBOM is still your job. CIP gives you a known package list and reproducible builds, which makes an accurate SBOM much easier to produce and keep current.

What the Civil Infrastructure Platform is

CIP describes itself as a collaborative project, hosted by the Linux Foundation, that builds an open source base layer of industrial grade software. Companies shipping embedded Linux controllers for railways or power plants used to maintain their own private kernels for each product's whole life, tracking the same security bugs in isolation. CIP pools that work so the common layer is maintained once, in public.

The project's own pages list the domains it targets:

• Transportation, including trains and railway infrastructure
• Power generation and power distribution
• Management of buildings and cities
• Communication systems
• Industrial control and supervision
• Healthcare equipment

CIP's FAQ names Codethink, Hitachi, Plat'Home, Siemens and Toshiba as early supporters. Governance follows the usual Linux Foundation model: a Governing Board handles money, and a Technical Steering Committee sets technical direction. Kernel contributions are licensed under GPL version 2.0, other project contributions under Apache 2.0, and any organisation can join, though it must also be a Linux Foundation member.

The work is split into working groups. The ones that matter most for security are:

What the LF Research report adds

The Linux Foundation post by Hilary Carter, who wrote the report, frames CIP as a cost sharing answer to a structural problem: consumer software support windows do not match physical assets that last decades. The research page puts global infrastructure investment at an expected 150 trillion US dollars by 2050, which is the economic case for software that has to last.

Based on interviews at five member companies, the post recommends that companies help govern the open source they depend on, build on verified industrial baselines, share regulatory work through pre-competitive frameworks, and get silicon suppliers working with open software communities so chip and software lifecycles line up.

The post also points to the EU Cyber Resilience Act and cites maximum penalties of 15 million euros or 2.5 percent of global annual turnover for non-compliance. That figure comes from the Linux Foundation's summary; check the regulation itself on EUR-Lex before you quote it in your own compliance documents.

Why ordinary Linux support windows are not enough

The kernel.org release page lists the current longterm kernels and their projected end of life. As of late October 2026 it shows:

kernel.org also notes that only important fixes go into longterm kernels, and that older trees see infrequent releases. CIP's kernel working group puts the upstream longterm window at four to six years and compares it with 20 to 50 years for railways and power generation. Even a product that ships on day one of a new longterm kernel will outlive upstream support several times over.

Before CIP, the options were to freeze the kernel and stop patching, to pay a team to backport fixes into a private fork forever, or to jump kernels every few years, which in a safety regulated product can mean recertification and field visits. CIP's tenth anniversary post calls this a maintenance crisis that pushed companies into costly and insecure private forks. CIP is the shared alternative.

For a wider look at why code below the application layer so often goes unpatched, see why firmware below the OS goes unpatched.

CIP SLTS kernels: how ten years of support works

The series and their dates

CIP's kernel working group lists every series it has maintained. All of them aim for at least ten years:

The two CIP sources disagree slightly on when the first series began: the anniversary post from the TSC chair gives 2016 for 4.4, while the kernel working group lists 2017. Both agree on the 2027 end.

CIP members choose the next SLTS series every two years, taking into account the kernel Debian uses, so the kernel and the Debian based user space stay aligned.

What happens after upstream stops

When an upstream longterm kernel reaches end of life, CIP does not stop. For 4.4 and 4.19, which upstream no longer maintains, the kernel working group continues in what it calls a self-maintenance model. That model narrows the scope to a subset of CPU architectures and to kernel configurations provided by members. If your product uses a driver or architecture outside that set, you cannot assume a fix will be backported for you.

This is the most important practical point about SLTS. It is ten years of maintenance for the parts of the kernel CIP members use and test, not ten years of everything in the kernel tree. CIP's kernel page says the scope of subsystems, drivers and features is defined by members together with the CIP kernel maintainers.

How fixes get into a CIP kernel

The kernel page describes the flow. SLTS kernels start from a standard longterm kernel. CIP maintainers follow the queue of fixes going into active longterm kernels, help with review and testing, and pick the patches that need to be backported into the SLTS trees. Once upstream support ends, CIP does the backporting itself.

The kernel working group says it reviews patches backported into the newest longterm kernel it supports, currently 6.12.y, since most fixes for older kernels land there too. It has tested more than 600 longterm kernel versions, backported roughly 100 fixes upstream, and follows an upstream first rule: new fixes go to mainline first, then flow back into longterm and CIP kernels.

Hardware support in an old kernel

New SoC variants arrive years into an SLTS series. CIP's written policies accept driver backports that do not break the existing driver framework, support for variants of SoCs already supported, and features needed for industrial use, each reviewed and tested on hardware. CIP notes the gap between upstream hardware support and an SLTS kernel containing it can reach two years.

Real-time kernels

Deterministic timing matters for control systems. CIP joined the Real-Time Linux project in 2017, supported the work to merge PREEMPT_RT into mainline, and still funds it. It publishes real-time variants of its kernels. In the linux-cip repository these show up as tags with an extra real-time suffix, alongside the normal tags. For example, the 6.12 series is tagged in the form v6.12.112-cip33, and real-time builds carry an additional -rt number.

Each update is built and tested with GitLab CI/CD, on real boards through LAVA, and through KernelCI, of which CIP is a founding member. The kernel working group also says it is setting up AI supported patch review, which is a plan rather than a finished capability.

How CIP tracks kernel CVEs

The Linux kernel produces a very large number of CVE records, and many do not apply to a given product's configuration. CIP's anniversary post describes its triage as a way to filter the "CVE flood" down to issues that affect CIP kernel configurations.

The tool behind this is public. The cip-kernel-sec repository tracks the status of each kernel CVE across mainline, stable and configured branches, stored as YAML files. Its README describes scripts that:

• import issue data from Debian's kernel security tracker and Ubuntu's CVE tracker,
• read git commit logs to find which fixes were backported to stable and other branches,
• report which issues affect the branches you specify, or all active branches, and
• run a small local web view for browsing branches and issues.

CIP's CVE handling document adds that MITRE, NVD and a distribution bug tracker are checked for more detail, and that the generated report is shared with CIP kernel users on a regular basis. The kernel working group also built a tool called kernel-cve-triage that narrows CVEs to those affecting specific kernel configurations, starting with the reference boards and configurations CIP maintains. Both are designed for general use, so you can point them at your own branch and your own configuration.

That configuration step is the part most teams skip. A CVE in a driver you do not compile is not a risk on your device. A CVE in a subsystem you do compile, on an interface an attacker can reach, may be urgent even if its CVSS score is middling.

CIP Core: the user space side

Devices also need a C library, an SSH server, a TLS library and the rest. CIP Core covers that.

Debian as the base

CIP chose Debian as its reference distribution. CIP's kernel page explains that CIP Core extends the work of Debian Long Term Support and Debian Extended LTS so that the selected packages are maintained for at least ten years. Debian's own LTS page says LTS aims to extend every Debian stable release to at least five years. CIP's contribution covers the years after that, for the packages on its list.

The list itself is deliberately small and lives in the cip-pkglist repository. The CIP Core working group picks packages based on real field demand.

Profiles and the Isar build system

CIP offers a Tiny profile for constrained devices and a Generic profile for standard industrial use, both built with Isar, which assembles images from Debian binary packages. The reference builder, isar-cip-core, has options for each SLTS kernel, a real-time kernel, a security image, Secure Boot with test keys, SWUpdate, encrypted partitions and reproducible builds. Its release policy says regular releases come roughly every three months.

Reproducible builds

The anniversary post says CIP continuously verifies bit for bit reproducible builds of its reference images. If two independent builds of the same inputs produce the same image, you can check that the binary you ship matches the source you reviewed.

CVE handling for CIP Core packages

For user space, CIP does not change Debian packages when it builds reference images. So its CVE handling for CIP Core is mostly about reporting: it collects CVE data for installed packages and shares reports with users, and it relies on the Debian Security Tracker and Debian's security advisories for analysis. The CVE handling document advises users to do their own risk assessment, since a high severity CVE may not apply to Debian's build or to a given use case.

This creates a common trap. Debian, and therefore CIP Core, often fixes a vulnerability by backporting a patch into an older upstream version. A scanner that only compares version numbers may then report the package as vulnerable when it is fixed. For how to read those version strings, see why a Debian version number can look vulnerable after a backported fix.

Updates in the field

Patching a kernel tree is half the job. The fix still has to reach a device bolted into a cabinet by a railway line. CIP's Software Updates working group builds that into CIP Core. Its page lists the topics it covers: device management for many devices, deployment, safe updates with rollback and power failure safety, and security against unauthorised update images.

The anniversary post names the components: SWUpdate for applying updates, The Update Framework for secure delivery of signed artifacts, and A/B partitioning for safe rollback. It also says the group is working on integrating an update workflow tool to automate updates across large fleets.

CIP's own IEC 62443-4-2 assessment notes record how this maps to the standard. For the embedded and network device requirement on support for updates, the notes mark it as met through the SWUpdate framework, which downloads and installs the update file. For update authenticity and integrity, they say CIP supports signed updates and that SWUpdate verifies checksums before installation begins, with a deliberately corrupted update file used as test evidence. The notes also tell users to create their own signing keys. The reference images ship with test keys; production devices must not.

If you are deciding between update layouts, our comparison of A/B slots and single slot firmware updates walks through the trade offs, and verified boot on embedded Linux from end to end covers the boot chain that checks what you install.

IEC 62443 and what CIP's work means for it

The series in brief

The ISA/IEC 62443 standards define requirements and processes for securing industrial automation and control systems. ISA's summary page describes a holistic approach that spans operations and IT, and process safety and cybersecurity. It also stresses shared responsibility across four groups: asset owners, product suppliers, integrators and service providers. ISA notes that ISA and IEC editions are identical, and that IEC recognised the series as a horizontal standard in 2021.

The parts most relevant to embedded Linux, as listed by ISA:

ISA's certification body, ISCI, runs schemes against these parts: component assurance, system assurance, an IoT component scheme and a development lifecycle scheme.

What CIP has done

CIP's security page explains the two parts it targets. 62443-4-1 covers how a supplier develops products: security requirements, secure design, secure implementation and coding guidelines, verification and validation, defect management, patch management and end of life. 62443-4-2 covers technical capabilities of components, organised under the foundational requirements and graded by security level.

CIP says it engaged an ANSI accredited certification body to run a gap analysis against both parts. According to the anniversary post, CIP became the first open source project to complete a 62443-4-1 conformance assessment, in August 2024, and completed the 62443-4-2 assessment in February 2026. CIP's security page adds that its investigation found the CIP ecosystem, including reference hardware, can deliver over half of the functionality needed for security level 2.

The process documents are public on Read the Docs and map to 62443-4-1 practice codes, from secure development (SM) and defect management (DM) to security update management (SUM). The 4-2 assessment pages mark each component requirement as met or not applicable, with notes. For example, integrity of the boot process is marked not applicable at the CIP level, since it depends on the product's hardware and firmware.

What it does not do for you

CIP's assessments cover CIP's base layer and process. Your product is a different thing: your hardware, your boot chain, your application, your configuration and your organisation's development process. A product supplier still needs its own 62443-4-1 process and its own 4-2 evidence for the component it sells. CIP gives you a head start, reusable documentation and a base layer that already meets many requirements. It does not hand you a certificate.

For asset owners, the relevant parts are 2-1, 2-3 and 3-3. A vendor building on CIP tells you how kernel fixes can reach you, not how fast it ships them or what its support term is. Ask.

For a practical view of patching on a plant floor, see factory floor vulnerability management with IEC 62443.

OpenSSF Gold: an external check on the process

In February 2026, CIP earned the OpenSSF Best Practices Gold badge, according to a CIP blog post by a Texas Instruments engineer. CIP's post says around 80 projects hold Gold, and that the three badge levels together cover more than 180 criteria. Gold adds structural requirements such as a bus factor of at least two, review of at least half of proposed changes by someone other than the author, reproducible builds and hardening headers on project websites.

Evidence included GPG signed releases, CVE response through cip-kernel-sec, static and dynamic analysis, and Developer Certificate of Origin sign off. Read the badge as a record of practices, not a guarantee about the code.

How industrial operators keep Linux patched for decades

CIP solves the upstream side. Operators and product makers still have to run a process that gets fixes from the CIP tree onto devices. Here is a pattern that works, built from CIP's own documents and 62443's shared responsibility model.

1. Pick the right series at design time

Choose the newest SLTS series your hardware supports when you design the product. A product that ships in 2026 on 6.12 has support planned to 2035. The same product on 5.10 has five years. CIP members choose new series every two years, so if a new one is close, it may be worth waiting.

2. Stay inside the maintained scope

Compare your kernel configuration and architecture with what CIP maintains. Use CIP's reference configurations as a starting point and keep your additions small. Every driver outside the maintained scope is a driver you may have to patch yourself in year eight.

3. Track the CIP tree, not a frozen snapshot

Rebase onto new CIP tags on a schedule, even when you do not plan to ship. A quarterly rebase is cheap; four years of drift is a project.

4. Triage CVEs against your configuration

Run cip-kernel-sec against your branch and configuration, and record each decision: affected, not built, not reachable, or fixed in a given tag. That record becomes your VEX data.

5. Build updates you can ship safely

Use signed updates with rollback, test the path with a corrupted image as CIP does, and replace test keys before production.

6. Agree on support terms with your customers

Operators cannot install a patch the vendor never ships, and vendors cannot fix devices the operator never updates. Write down the support period, the critical fix cadence and how notification works, which is what 62443-2-3 and 2-4 expect.

7. Plan for the end

Ten years is long, but it is not 40. Decide when each device moves to a newer SLTS series and what happens to devices that cannot. Our guide to upgrading, extending, isolating or retiring end of life software covers the choices.

SBOM for embedded and industrial Linux

An SBOM lists the components in a product. For an embedded Linux device that means the kernel and its configuration, the user space packages, the bootloader, your own applications and their dependencies, and any vendor binary blobs. CISA's SBOM page describes the related idea of VEX, an attestation that says whether a product is affected by a given vulnerability. Embedded teams need both: the SBOM to know what is inside, and VEX to explain which CVEs do not apply.

CISA's page also points to updated 2026 guidance on SBOM minimum elements, published jointly with partners, which adds data fields and practices. If you produce SBOMs for customers, read the current guidance rather than the 2021 baseline.

What CIP makes easier

• A known package list. CIP Core's package list is small and published, so the user space part of the SBOM is short and stable.
• Reproducible images. If the build is reproducible, the SBOM generated from it describes exactly the binary you ship.
• CVE reports by package. CIP Core's CVE checker generates reports from the installed package list, which is the same list your SBOM needs.
• Per branch kernel CVE status. cip-kernel-sec gives a public, versioned record of which kernel CVEs are fixed in which CIP tags.

What you still have to do

CIP does not publish an SBOM for your product. Isar based builds can export the installed package list, and you can turn that into SPDX or CycloneDX with standard tooling. If your product uses the Yocto Project instead of Isar, its documentation says the OpenEmbedded build system generates an SPDX SBOM by default through the create-spdx class, written as a JSON file next to the image. Either way, add the kernel version with its CIP tag, the kernel configuration, the bootloader and your application layer.

For a detailed comparison of build system outputs, see which SBOM output you get from Buildroot or Yocto, and for the wider topic, SBOMs for embedded systems.

Step by step: build, inspect and track a CIP based image

These steps use CIP's public repositories. They assume a Linux workstation with git, Python 3 and Docker or Podman.

Step 1: see the CIP kernel series and latest tags

# Clone the CIP kernel tree (large; a shallow clone is fine for browsing tags)
git clone --filter=blob:none https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
cd linux-cip

# List CIP branches
git branch -r | grep -- '-cip'

# Show the five most recent CIP tags for the 6.12 series
git tag -l 'v6.12.*-cip*' | grep -v rebase | sort -V | tail -5

# Show the five most recent real-time tags for 6.1
git tag -l 'v6.1.*-cip*-rt*' | grep -v rebase | sort -V | tail -5

On a running device, uname -r prints the kernel release. Compare it with the CIP tag your build used, which you should record in your build metadata so the answer is not a guess.

Step 2: check kernel CVE status for CIP branches

git clone https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec.git
cd cip-kernel-sec

# Needs PyYAML and html5lib (Debian: python3-yaml python3-html5lib)
python3 -m pip install --user pyyaml html5lib

# Create the local kernel repo with mainline, stable and CIP remotes
# (by default it is expected at ../kernel)
./scripts/prepare_remotes.py

# Report which tracked issues affect the active branches, with descriptions
./scripts/report_affected.py --show-description

Feed the output into your own triage. For each CVE that the report lists for your series, check whether the affected code is built in your configuration. Write down the result and the reason.

Step 3: build a CIP Core reference image

The isar-cip-core README uses kas in a container. Podman is recommended for unprivileged builds.

git clone https://gitlab.com/cip-project/cip-core/isar-cip-core.git
cd isar-cip-core

# Pick target, kernel series and options interactively
./kas-container menu

# Or build directly, for example a BeagleBone Black image with a real-time kernel
./kas-container build kas-cip.yml:kas/board/bbb.yml:kas/opt/rt.yml

# Run a QEMU x86 build of the security image
TARGET_IMAGE=cip-core-image-security ./start-qemu.sh x86

Step 4: flash a physical target

Warning: the next command overwrites the whole target device. Writing to the wrong device destroys its data, including your workstation's own disk. Identify the SD card first and check the device path twice.

# 1. List block devices before inserting the card, then again after
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

# 2. Confirm the new device (for example /dev/sdX) is the card: right size,
#    removable, not mounted, and not your system disk
lsblk /dev/sdX

# 3. Only then write the image (replace sdX with the confirmed device)
sudo dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic \
     of=/dev/sdX bs=1M status=progress conv=fsync

The image name in the README example uses an older Debian release. Use the file your build actually produced in build/tmp/deploy/images/.

Step 5: produce a package inventory for the SBOM

On a booted target, or in the image's root file system, list installed Debian packages with versions:

dpkg-query -W -f='${Package}\t${Version}\t${Architecture}\n' | sort > packages.tsv
uname -r > kernel-release.txt

Convert that list into SPDX or CycloneDX with the tool your build pipeline already uses, then add the kernel tag, kernel configuration and your application components. If you use Safeguard, an existing SBOM file can be scanned with:

safeguard scan --sbom product-sbom.cdx.json
# Results are written as JSON under ./output

Read the results with the backport caveat from earlier in mind: version matching on Debian packages can flag a CVE that Debian fixed by backport. Check the Debian Security Tracker before you act on a package finding, and record your decision.

Step 6: keep it current

Re-run steps 2 and 5 on every CIP Core release, which arrives roughly every three months, and on every new CIP kernel tag you adopt. Store each SBOM next to the release it describes. When a new CVE lands, the question "which shipped products contain this?" becomes a search, not an archaeology project. Our post on using SBOMs to find affected products fast covers that workflow.

Decision table: should your product build on CIP?

Common mistakes

• Treating "ten years" as covering every driver. SLTS covers what CIP maintains, and for older series the scope is reduced to member configurations. Check your drivers and architecture.
• Freezing at the first CIP tag. Using CIP but never rebasing gives you none of the benefit. Track tags on a schedule.
• Reading CVE lists without configuration context. Most kernel CVEs touch code a given device does not build. Triage against your configuration, and record the reasoning.
• Trusting version comparisons on Debian packages. Backported fixes keep old upstream version numbers. Confirm with the Debian Security Tracker.
• Keeping test signing keys. CIP's reference images use test keys for Secure Boot and updates. Generate and protect your own before production.
• Calling the product "62443 certified because it uses CIP". CIP's assessments are about CIP. Your product needs its own evidence and, if you want it, its own certification.
• Leaving the application layer out of the SBOM. The Python, Node or Go services on a gateway often carry more third party code than the base image.

FAQ

What is the Civil Infrastructure Platform?

It is a Linux Foundation project, started in 2016, that maintains an open source base layer for industrial and civil infrastructure devices. It provides Super Long-Term Support kernels, a small Debian based core package set, update tooling and IEC 62443 process documentation, all maintained jointly by member companies.

How long are CIP SLTS kernels supported?

Each series aims for at least ten years. The current plan is 4.4 to 2027, 4.19 to 2029, 5.10 to 2031, 6.1 to 2033 and 6.12 to 2035, according to CIP's kernel working group.

What is the difference between a CIP SLTS kernel and an upstream LTS kernel?

An SLTS kernel starts from an upstream longterm kernel and keeps receiving backported fixes after upstream support ends. Upstream longterm kernels are typically maintained for four to six years. After that point, CIP maintains a defined scope of architectures and configurations itself.

Is CIP IEC 62443 certified?

CIP says it completed an IEC 62443-4-1 conformance assessment in August 2024 and an IEC 62443-4-2 assessment in February 2026. Those cover CIP's base layer and process. A product built on CIP still needs its own assessment if it wants certification.

How does CIP handle kernel CVEs?

CIP tracks each kernel CVE per branch in the public cip-kernel-sec repository, importing data from Debian and Ubuntu trackers and reading backport history from git. It filters issues against the configurations and reference boards it maintains and shares reports with users.

Does CIP provide an SBOM for my product?

No. CIP gives you a published package list, reproducible builds and CVE reports, which make an SBOM easier to produce. Your build pipeline still has to generate the SBOM for your product, including your applications.

How do industrial devices on CIP get updates in the field?

CIP Core integrates SWUpdate for applying signed updates, with A/B partitions for rollback and The Update Framework for secure delivery, according to the project. Product makers set up their own keys and update servers.

Does the EU Cyber Resilience Act apply to industrial Linux products?

Many products with digital elements sold in the EU fall under it, and CIP's anniversary post notes the CRA requires security updates across a product's support period. Check the regulation text and its exclusions for your specific product category.

Fix it without waiting for upstream

CIP keeps the kernel and core packages patched, but the applications, services and container images that product teams build on top of that base pull in open source dependencies that CIP does not maintain. That application layer, plus the build tooling around it, is where the following controls apply; they do not patch device kernels or firmware.

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

Safeguard does not maintain kernels, flash devices, scan firmware or manage a device fleet. Where it fits is the software that product teams write and assemble on top of a base like CIP: application dependencies, container images used in build and gateway tooling, and SBOM files produced by the build. If you want to try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan, which is the same flow you would use on the web or service code that ships alongside an industrial device. More background is in the Safeguard CLI overview.

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

The second demo sets up the runner on your own machine, approves it with its device code, and then scans from the terminal. For embedded teams whose build hosts sit on restricted engineering networks, running scans from a machine you control is the natural place to check the SBOM files your Isar or Yocto builds produce.

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 lets you choose which tools Claude can use. That is a practical way to ask questions such as which projects contain a given component version, while keeping the assistant's access limited to the tools you picked.

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

Quick check

Sources

• Linux Foundation blog: A Decade of Industrial Grade Linux: How the Civil Infrastructure Platform Is Securing Mission-Critical Systems (6 Oct 2026)
• LF Research: Civil Infrastructure Platform: Industrial Grade Linux at 10
• Civil Infrastructure Platform: home page
• CIP: About
• CIP: FAQ
• CIP: Linux Kernel and Core Packages
• CIP: Security / IEC-62443-4-2
• CIP: Software Update
• CIP blog: A Decade of Industrial Grade Linux: Reflecting on the CIP Journey and the Road Ahead (28 Apr 2026)
• CIP blog: A Decade of Stability: 10 Years of the CIP Kernel WG (6 Aug 2026)
• CIP blog: Civil Infrastructure Platform Achieves OpenSSF Best Practices Gold Badge (22 Jul 2026)
• CIP documents (Read the Docs)
• CIP documents: CIP CVE handling
• CIP documents: IEC 62443-4-2 assessment, FR 3
• linux-cip kernel repository on git.kernel.org
• cip-kernel-sec README on GitLab
• isar-cip-core README on GitLab
• isar-cip-core version and release policy
• kernel.org: Active kernel releases
• ISA: ISA/IEC 62443 Series of Standards
• Debian: Long Term Support
• Yocto Project documentation: Creating a Software Bill of Materials
• CISA: Software Bill of Materials (SBOM)

Last reviewed: 23 October 2026. CIP support dates, kernel.org projected end of life dates and IEC 62443 editions change over time; check the linked project and standards pages for current details.