A build pipeline that compiles only when a real runtime request proves the artifact is needed. In this pattern, the build system acts on exact kernel, distribution, and architecture identity rather than precomputing every possible variant. It improves efficiency, but it also makes request validation and dispatch authority part of the control surface.
Expanded Definition
Demand-driven build pipeline describes a build system that produces artifacts only when a genuine runtime request proves a specific build is needed. In NHI-heavy environments, that request must carry exact identity details such as kernel, distribution, and architecture so the pipeline can dispatch the correct workload without prebuilding every variant. The distinction matters because the pipeline is not just a CI convenience; it becomes an identity-aware control point that decides which request is authoritative enough to trigger compilation. That makes the workflow closely related to NIST Cybersecurity Framework 2.0 principles for access control and secure execution, even though no single standard governs this build pattern yet. In practice, the term is often used alongside ephemeral infrastructure, sealed build inputs, and signed artifacts, but definitions vary across vendors when they describe on-demand, lazy, or request-triggered compilation. The most common misapplication is treating any just-in-time build as demand-driven, which occurs when the pipeline still precomputes variants or accepts unsigned, unverified requests.
Examples and Use Cases
Implementing demand-driven builds rigorously often introduces request-validation overhead and tighter dispatch logic, requiring organisations to weigh faster artifact availability against more complex control enforcement.
- A multi-architecture container pipeline compiles only after a runtime request identifies the target architecture, reducing unnecessary arm64 and x86_64 build churn.
- A Linux distribution rebuild service accepts a signed request, validates the exact kernel version, and emits only the matching package variant.
- A hardened CI/CD workflow blocks anonymous build triggers and requires traceable request authority, as described in the CI/CD pipeline exploitation case study.
- A secret-sensitive release process uses demand signals to avoid pre-staging artifacts that could expose credentials, aligning with lessons from the Guide to the Secret Sprawl Challenge.
- An SBOM-linked pipeline defers compilation until the request includes the exact source revision, base image, and dependency set that will be attested.
For build integrity and supply-chain context, practitioners also map this model against published guidance such as the NIST Cybersecurity Framework 2.0 and incident reporting from the Reviewdog GitHub Action supply chain attack.
Why It Matters in NHI Security
Demand-driven build pipelines matter because they shift trust from bulk precomputation to request-time authorization, which is exactly where NHI controls tend to fail if secrets, service accounts, or dispatch tokens are over-permissioned. When a pipeline can build only on demand, every trigger becomes part of the attack surface, and identity assurance must be strong enough to resist spoofed requests, replayed jobs, and poisoned inputs. This is especially important in environments where build systems store credentials or exchange tokens with registries, artifact stores, and signing services. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes request-driven pipelines attractive targets if governance is weak. A demand-driven model supports least privilege and reduces unnecessary artifact generation, but it also raises the cost of failure because one malicious request can influence the only build that matters. Organisations typically encounter the operational risk only after a pipeline compromise or secret leak, at which point demand-driven dispatch authority becomes unavoidable to address.
For broader NHI governance, the control lesson is consistent with the Ultimate Guide to NHIs and with the reality that build-time identities must be as tightly governed as runtime service accounts when artifacts are produced on request.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers identity and access controls for non-human workloads that trigger builds. |
| OWASP Agentic AI Top 10 | Request-driven automation can behave like an agent with execution authority. | |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed so only authorized requests can initiate builds. |
| NIST Zero Trust (SP 800-207) | SC-7 | Demand-driven dispatch depends on continuous verification of request origin and context. |
| NIST AI RMF | Risk governance applies when build decisions are made dynamically from context. |
Require authenticated, least-privilege build triggers and validate every request before dispatch.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
