TL;DR: Kernel-module build automation hit GitHub Actions matrix, output, and registry limits, according to Riptides, then the pipeline was reworked with chunked workflows, artifact caching, and alternate kernel sources to keep multi-distro builds moving at scale. The security implication is that workload identity programmes depend on build and release engineering behaving predictably under load, not just on runtime controls.
At a glance
What this is: This is a build-automation case study showing how Riptides scaled kernel-module workflows for workload identity after GitHub Actions limits exposed fragility in matrix size, output handling, and registry access.
Why it matters: It matters because workload identity programmes can inherit hidden operational risk from CI/CD and release engineering, especially when build pipelines become part of the trust chain for security-sensitive kernel components.
By the numbers:
- GitHub Actions imposes a maximum of 256 matrix jobs per workflow run, 1 MB output per job, and 50 MB total outputs per workflow run.
Context
Kernel-module build automation is not just a software delivery problem when the modules underpin workload identity. In this case, the build system had to produce kernel-specific artifacts reliably across many Linux distributions, versions, and architectures so SPIFFE-based identities could be issued from the kernel boundary without introducing release bottlenecks.
The governance gap is scale sensitivity: a pipeline that works for a handful of targets can fail once matrix size, output volume, and registry dependencies all grow together. For identity practitioners, that means build and release engineering becomes part of the control plane, because availability and predictability affect whether identity components can be delivered safely and on time.
The article is a typical example of how operational limits, not only security defects, can shape workload identity design. The important detail is that the trust model depends on repeatable builds as much as on runtime enforcement.
Key questions
Q: How should security teams handle build limits in workload identity pipelines?
A: Treat build limits as a governance issue, not a nuisance. If identity-critical code depends on large matrix builds, split the pipeline into governed chunks, preserve traceability across workflow boundaries, and test the failure modes of job caps, output caps, and registry throttling before release windows depend on them.
Q: When does CI/CD scaling become a workload identity risk?
A: It becomes a risk when release engineering can no longer prove that every kernel, distro, and architecture variant was built from the intended inputs. At that point, availability and repeatability of the build system start to shape identity assurance as much as the runtime control plane does.
Q: What breaks when large build matrices are not chunked?
A: The workflow stops being able to express the full set of builds within platform ceilings, which means jobs fail before compilation even starts. The practical effect is partial coverage, lost build metadata, and unpredictable release timing for identity-bearing components.
Q: What is the difference between build caching and artifact caching in large pipelines?
A: Build caching reduces the work needed to create a reusable environment, while artifact caching makes that environment or output available to many jobs without repeated external fetches. In this article, both patterns reduce registry pressure, but artifact caching also stabilises parallel execution at scale.
Technical breakdown
Why large build matrices break down in CI/CD
A build matrix is the set of target combinations a pipeline compiles in parallel. For kernel modules, each distribution, architecture, and kernel version expands that matrix quickly, and CI systems impose practical ceilings on job count and output size. Once the matrix exceeds those limits, the issue is no longer compilation speed but orchestration failure: the pipeline cannot express the work as a single run, and metadata needed to coordinate later stages becomes too large to pass cleanly. That creates a control-plane bottleneck even when the source code itself is stable.
Practical implication: design build fan-out with explicit limits on job count and output volume before scaling workload identity delivery.
How workflow chaining changes build orchestration
Workflow chaining splits one oversized build process into smaller child workflows. A generator workflow can compute the matrix, compare it with prior state, chunk it into manageable batches, and trigger each batch separately. The build workflow then consumes one chunk at a time and executes the compile step. This is an architectural workaround for platform ceilings, but it also introduces a governance question: the system now depends on consistent state transfer between workflows, so artifact provenance and matrix integrity become part of pipeline correctness.
Practical implication: treat workflow dispatch boundaries as governed interfaces, not just implementation convenience.
Why cached base images matter for workload identity builds
Large parallel builds often fail at the image and package layer before they fail at the compiler. Repeatedly pulling the same base image across many jobs can trigger registry rate limits and add avoidable startup latency. Caching prebuilt images as artifacts or tarballs shifts that load away from the registry and makes each job self-sufficient. For workload identity programmes, this matters because the release pipeline becomes more deterministic under scale, which reduces the chance that identity-bearing components drift between build intent and delivered artifact.
Practical implication: cache the build environment itself, not only the final artifacts, when identity-critical components must scale reliably.
Breaches seen in the wild
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
- 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
Build-system limits are now part of workload identity governance. When SPIFFE-based identity is issued from the kernel boundary, the build pipeline becomes part of the trust chain, not just the delivery chain. Matrix ceilings, output caps, and registry throttling can all delay or distort what gets shipped. The practitioner takeaway is that release engineering reliability is an identity control surface.
Kernel build automation exposes a pipeline-scale trust dependency. This article shows that workload identity programmes depend on predictable compilation and packaging across many kernel variants, not merely on runtime authentication mechanics. The named concept is build-system trust debt: every ungoverned scaling shortcut in CI/CD becomes a future reliability debt against the identity layer. Practitioners should treat build architecture as a first-class governance concern.
Chunking and caching are not just performance optimisations. They are resilience patterns that keep identity-related releases within platform limits while preserving reproducibility. The important distinction is that the control objective is continuity of governed delivery, not speed alone. The practitioner conclusion is to align pipeline design with the operational needs of workload identity rather than assuming generic CI/CD capacity will scale indefinitely.
Workload identity at the kernel edge amplifies operational fragility. The closer identity issuance moves to infrastructure boundaries, the more fragile the delivery path becomes if build orchestration is not engineered for load. That changes how teams should evaluate CI/CD maturity for identity projects. The practitioner conclusion is to review build governance whenever identity enforcement depends on low-level system components.
Platform limits reveal where identity programmes rely on invisible infrastructure assumptions. Matrix size, output volume, and registry behaviour all become hidden dependencies once build automation is heavily parallelised. Those assumptions rarely appear in policy documents, yet they determine whether identity code reaches production cleanly. The practitioner conclusion is to map those assumptions before scaling workload identity rollouts.
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: Cloud Workload Identity Guide
What this signals
Build-system trust debt: once workload identity delivery depends on kernel-specific CI/CD pipelines, the release path itself becomes part of identity governance. Teams should review whether their build systems can still prove completeness, provenance, and repeatability when matrix size grows faster than their control design.
Pipeline chunking and local image reuse are not merely engineering optimisations. They show that identity programmes need resilience patterns in the delivery layer, because runtime controls cannot compensate for a build process that fails under ordinary scale.
The operational lesson is to treat CI/CD limits as upstream constraints on identity assurance. If the pipeline cannot reliably build and package every supported kernel variant, the identity control is only as strong as the weakest release path.
For practitioners
- Map build pipeline limits to identity release risk Inventory the GitHub Actions ceilings, registry rate limits, and artifact-size constraints that affect kernel and workload identity builds, then document which releases fail first when demand spikes.
- Split oversized matrices into governed chunks Use a matrix generator and child workflows so each batch stays within job, output, and concurrency limits while preserving traceable build state across runs.
- Cache the build environment as an artifact Store prebuilt base images or equivalent build layers so parallel jobs restore locally instead of hammering registries for the same layers repeatedly.
- Validate alternate package sources for kernel coverage Confirm that internal build inputs can fall back to official package sources when standard repositories do not carry the kernel versions your supported estate needs.
Key takeaways
- Kernel-module build automation can become an identity governance issue when release engineering is responsible for delivering the components that establish workload trust.
- Riptides encountered hard limits in GitHub Actions matrix size, output volume, and registry usage while scaling kernel builds across many Linux variants.
- Chunking workflows, caching base images, and validating alternate kernel sources are the practical controls that keep workload identity releases predictable at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 — Environment Isolation | Parallel kernel builds depend on isolated, repeatable environments across many distro and kernel variants. |
| NHI-05 — Overprivileged NHI | Kernel build automation relies on powerful pipeline identities that should not exceed build-scoped access. | |
| Recommendation — Enforce isolated build environments so kernel identity artifacts are reproducible across every supported target. Restrict CI/CD identities to the minimum access needed for build, cache, and artifact operations. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline permissions govern who and what can generate, move, and publish identity-related build artifacts. |
| Recommendation — Review pipeline entitlements to ensure build jobs can only access the repositories, artifacts, and registries they need. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build automation depends on service accounts and runner identities that need disciplined lifecycle control. |
| Recommendation — Inventory and periodically review all CI/CD service accounts that can publish or consume identity-bearing artifacts. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Compromised build systems can leak tokens and artifacts if CI limits and caches are not governed. |
| Recommendation — Map pipeline abuse paths to credential access and exfiltration so detections cover build-time identity exposure. | ||
Key terms
- Build-system trust debt: The accumulated risk created when identity-critical software delivery depends on scaling assumptions that are not explicitly governed. In practice, the pipeline may still work for small runs, but its reliability, traceability, and repeatability weaken as load, fan-out, and external dependencies grow.
- Workflow chunking: A pipeline pattern that splits a large matrix or job set into smaller batches so each execution stays within platform limits. For workload identity builds, chunking preserves delivery continuity while keeping traceability and failure containment manageable.
- Artifact caching: Artifact caching stores reusable build inputs or outputs so parallel jobs can restore them without repeating expensive external downloads. In identity delivery pipelines, it reduces shared dependency pressure and helps keep release behaviour stable when concurrency increases.
- Workload identity release path: The delivery chain that turns source code, build inputs, and packaging steps into the components that establish machine or kernel-level identity. If that path is unreliable, the identity programme inherits operational fragility even when runtime controls are sound.
Deepen your knowledge
NHI governance, workload identity security, and secrets management 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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org