Demand-driven kernel driver builds reduce coverage gaps and wait time

At a glance

What this is: This is an analysis of a demand-driven kernel driver build pipeline that prioritises exact-match artifact lookup and on-demand compilation to close coverage gaps in a long tail of kernel variants.

Why it matters: It matters because platform and workload teams need driver availability to track the actual fleet state, not a speculative kernel matrix, or nodes remain blocked waiting for compatible modules.

Context

Kernel driver distribution breaks down when build coverage is based on what exists in distribution mirrors rather than what actually boots in production. In NHI terms, the control problem is not identity governance in the traditional sense, but artifact governance for host-level enforcement components that must be ready at node startup.

Riptides' approach treats the build pipeline as an operational dependency in the boot path. That means the platform has to handle exact kernel, architecture, distribution, and distro version matching before a node can become fully usable.

The article shows a shift from speculative precompilation to demand-driven coverage. That is the right lens when the long tail of supported environments is open-ended and stale coverage creates avoidable start-up delay.

Key questions

Q: What should teams do first when a required kernel package is not already built?

A: Check the artifact store first and only trigger a build when the exact package is absent. That keeps most requests on the fast path, avoids duplicate workflows, and ensures the build service only spends capacity on kernels the fleet actually needs.

Q: Why do on-demand kernel builds work better than speculative prebuilding for long-tail fleets?

A: Speculative prebuilding wastes CI capacity on kernel variants that may never appear in production, while on-demand builds spend compute only when a real node proves the need. The model improves coverage where it matters and keeps the fleet aligned to actual runtime demand.

Q: What breaks when distro version is not part of the build identity?

A: Different distro versions can ship different toolchains and metadata expectations, so a module may compile but fail to load cleanly on the target host. Treat distro version as part of the artifact identity, not a minor metadata field.

Q: How should teams keep kernel build coverage aligned with what the fleet actually runs?

A: Use a demand-driven source of truth that records successful builds and feeds them back into the next batch cycle. That approach keeps the matrix tied to observed fleet behaviour instead of mirror inventory or crawler completeness.

Technical breakdown

How demand-driven kernel builds close the artifact gap

The core mechanism is a check-first build service that looks for an existing package before it dispatches a new workflow. If the artifact is present in GitHub Releases, the node proceeds immediately. If not, the service validates the request, dispatches a GitHub Actions build with the exact kernel and distro inputs, and the caller polls for completion. This is a classic artifact-on-demand pattern: the build system becomes part of the runtime delivery path rather than a batch-only factory. The practical effect is that build latency becomes bounded by first-encounter time, not nightly scheduling.

Practical implication: treat the build pipeline as a boot-critical service and design for exact-match artifact lookup before any new compile starts.

Why distro version and livepatch handling matter

Kernel compatibility is not just about the kernel release string. The article shows that distro version changes the toolchain, which can alter module metadata and produce runtime load errors even when compilation succeeds. That is why the build request carries distro version through the whole chain, from service to workflow to Docker build arguments. The same logic applies to Amazon Linux livepatch kernels and Fedora or CentOS mirrors that age out quickly. The fallback path has to preserve the exact target environment, or the artifact is technically built but operationally unusable.

Practical implication: bind each build to the target distro version and discovery source so the resulting module matches the host it will run on.

Why kernels.json is a better source of truth than speculative crawling

The article replaces broad kernel crawling with kernels.json as the default input for nightly builds. That changes the control objective from exhaustive precompilation to observed-demand coverage. Every successful on-demand build appends the new kernel to the file, so the matrix grows from real fleet behaviour rather than mirror inventory. That matters because speculative lists inevitably overbuild variants no customer ever boots, while omitting the long tail that does appear. The result is a feedback loop between runtime need and future build coverage.

Practical implication: maintain the supported build matrix from observed fleet demand, then let successful on-demand builds enrich the future batch list.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Demand-driven build coverage is the right control when the runtime environment is the unknown. The article shows that nightly matrix builds eventually hit a ceiling because distribution mirrors and crawler data cannot predict the exact kernel a node will boot. For identity and access practitioners, the parallel is clear: governance assumptions fail when coverage is based on catalogue completeness instead of live state. The implication is to design control points around observed runtime demand, not static expectations.

Exact environment matching is a delivery requirement, not an optimisation detail. The article makes clear that kernel release, architecture, distribution, and distro version all affect whether a driver can load successfully. That is a useful reminder for host-enforcement tooling, where a successful compile can still fail at the point that matters. Practitioners should treat environment fidelity as part of operational correctness, not as a packaging preference.

Kernel inventory should be derived from real fleet behaviour. kernels.json is effectively a governed source of truth because it is fed by successful on-demand builds, not by a speculative crawl of everything that exists in public mirrors. That creates a tighter link between what the fleet actually needs and what the build system prepares next. The broader lesson is that coverage models improve when they are driven by actual runtime exposure.

Build latency becomes part of the security and operations user experience. The article shows that a faster package path shortens the time a node waits before it can load its driver and become fully operational. In practice, any control that delays enforcement or visibility at boot has to be evaluated as a service-level dependency, not just a CI efficiency issue. Teams should measure how long critical host controls remain unavailable after startup.

Demand-driven coverage reduces waste, but it also narrows the gap between discovery and readiness. Once the first node triggers a build, later nodes on the same kernel benefit immediately from the prebuilt artifact. That feedback loop is what makes the model operationally sustainable. Practitioners should think in terms of first-seen latency versus steady-state readiness, because that is where the real trade-off sits.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to NHI Rotation Challenges

What this signals

Demand-driven kernel coverage is a better operating model than speculative matrix expansion. Once booted hosts can force an exact-match build, the question changes from whether a kernel exists somewhere in public mirrors to whether the fleet has already proven it needs the artifact. That shifts control ownership from precomputation to runtime readiness.

Build latency is now a host-enforcement issue as much as a CI issue. When the loader waits for a package before the node becomes fully operational, pipeline optimisation directly affects enforcement uptime. Teams should watch for any critical runtime control whose delivery path still depends on slow, general-purpose build queues.

For practitioners

• Check for an existing artifact before triggering any build Resolve package availability from the release store first, and only dispatch a workflow when the exact kernel, architecture, distribution, and distro version are missing.
• Keep the build request fully specific Carry kernel version, architecture, distribution, distro version, and driver version through the service, workflow inputs, and build cache key so different targets do not collapse into one build.
• Add a distribution-aware fallback chain Use a deterministic path such as DNF repositories, explicit kernel URLs, and Koji or CBS fallbacks so older kernel-devel packages remain buildable after mirror turnover.
• Treat livepatch discovery as a separate input source Query the livepatch CDN directly when crawler data does not include those kernels, because standard mirror scraping can miss livepatched variants entirely.
• Maintain kernels.json from observed demand Append successful on-demand builds into the matrix source so the next batch run reflects what the fleet actually booted, not what a crawler merely found.

Key takeaways

• The core problem is not compilation alone, but whether a node can get the exact driver artifact it needs at boot without waiting for a batch cycle.
• The article's operating model replaces speculative coverage with observed-demand coverage, which is a more accurate fit for long-tail kernel diversity.
• Practitioners should treat artifact lookup, environment fidelity, and build feedback loops as one governed delivery path, not separate engineering concerns.

Key terms

• Demand-Driven Build Coverage: A delivery model where builds are triggered by actual runtime need instead of speculative precompilation. In kernel or workload environments, it reduces wasted capacity and keeps the artifact set aligned with the fleet that really exists.
• Artifact On Demand: A pattern in which the system checks for a ready-made package before creating a new one. For host-enforcement or workload tooling, it shortens the gap between a node requesting support and receiving an exact-match artifact.
• Environment Fidelity: The degree to which a test environment matches the real operating conditions of the application. High fidelity means devices, integrations, security protections, and workflow constraints are preserved so results reflect production behaviour rather than an artificially simplified lab scenario.
• Runtime Coverage Gap: The difference between the environments a pipeline can build for and the environments the fleet actually boots on. In practice, this gap shows up when the right artifact does not exist at the moment a node needs it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.