— Secure AI Platform Build Systems & CI/CD Security: Trusted Build Pipelines, Isolated Runners, Artifact Signing, Provenance, Build Reproducibility, Pipeline Permissions & Deployment Integrity
86.1 Introduction
A secure AI platform does not become trustworthy merely because its production application is protected.
The software, AI models, prompts, policies, containers, infrastructure definitions, dependencies, and configuration that eventually reach production must first pass through a build and delivery system.
That system is itself a high-value security boundary.
If an attacker compromises the build pipeline, they may be able to modify:
- application source code
- AI model artifacts
- prompt templates
- security policies
- container images
- dependencies
- infrastructure definitions
- deployment manifests
- configuration files
- generated artifacts
The result can be a supply-chain compromise in which production receives malicious or unauthorized software even though the production environment itself was never directly attacked.
Therefore, secure CI/CD must provide:
- trusted source inputs
- authenticated changes
- isolated build execution
- controlled pipeline permissions
- reproducible or verifiable builds
- artifact integrity
- provenance
- security scanning
- approval gates
- controlled deployment
- complete auditability
- reliable rollback
The fundamental principle is:
Production should receive only artifacts whose origin, build process, integrity, evaluation status, and authorization can be verified.
86.2 Build Systems as a Security Boundary
A build system transforms source inputs into deployable artifacts.
A simplified pipeline is:
Developer
↓
Source Repository
↓
Pull Request / Change Review
↓
CI Pipeline
↓
Dependency Resolution
↓
Build
↓
Security Tests
↓
AI / Model Evaluation
↓
Artifact Creation
↓
Artifact Signing
↓
Provenance Generation
↓
Artifact Registry
↓
Deployment Approval
↓
Production
Every stage introduces security decisions.
For example:
- Who can modify the source?
- Who can trigger the pipeline?
- Which credentials can the pipeline access?
- Which dependencies can it download?
- Which external services can it contact?
- Who can approve production deployment?
- Can a developer replace an approved artifact?
- Can an unsigned artifact reach production?
- Can a compromised runner access another project's secrets?
These questions should be answered through explicit controls rather than assumptions.
86.3 CI/CD Threat Model
A secure design begins with a threat model.
Important threats include:
Source compromise
An attacker gains unauthorized access to the source repository and inserts malicious code.
Pull-request manipulation
A malicious or compromised contributor submits a change that appears legitimate but modifies security-sensitive behavior.
Pipeline injection
Untrusted input changes how a CI job executes.
Secret theft
A build process exposes credentials, tokens, signing keys, or cloud access credentials.
Runner compromise
A malicious build or dependency compromises the machine executing the pipeline.
Dependency compromise
A malicious package or compromised upstream dependency enters the build.
Artifact replacement
An attacker replaces a legitimate artifact with a malicious one after the build.
Registry compromise
An attacker obtains write access to the artifact registry.
Pipeline privilege escalation
A low-privileged build job obtains permissions intended for deployment infrastructure.
Deployment bypass
An attacker bypasses testing or approval gates and deploys directly.
Provenance forgery
An artifact claims to have been produced by a trusted pipeline even though its origin cannot actually be verified.
86.4 Principle of Least Privilege for CI/CD
CI/CD systems frequently become overprivileged because they need access to many systems.
A common unsafe architecture is:
CI Runner
↓
Full Cloud Administrator
↓
All Resources
A better architecture is:
Build Job
↓
Build Permissions Only
Test Job
↓
Test Permissions Only
Artifact Publishing Job
↓
Registry Write Permission
Deployment Job
↓
Deployment-Specific Permission
Each job should receive only the permissions required for its function.
For example:
| Job | Appropriate access |
|---|---|
| Lint | Source read |
| Unit test | Source + test dependencies |
| Build | Source + approved dependencies |
| Image build | Build environment |
| Registry publish | Artifact registry write |
| Staging deployment | Staging deployment permissions |
| Production deployment | Restricted production deployment permission |
| Security scan | Artifact read |
| Evaluation | Evaluation dataset/model access |
A build job should not automatically have production administrator privileges.
86.5 Isolated Build Runners
Build runners execute code from potentially untrusted sources.
Therefore, they should be treated as disposable security environments.
A secure model is:
Job Starts
↓
Fresh Runner
↓
Checkout Source
↓
Build/Test
↓
Collect Artifacts
↓
Destroy Runner
The runner should ideally be:
- ephemeral
- isolated
- minimally privileged
- monitored
- network-restricted
- free of long-lived secrets
After the job completes, the environment should be discarded.
This limits persistence.
86.6 Persistent Runner Risks
Long-lived build machines create additional risk.
Suppose:
Build A
↓
Temporary malicious file
↓
Build B
↓
Malicious file remains
Build B may unknowingly inherit state from Build A.
Possible residual state includes:
- credentials
- cached packages
- source code
- temporary files
- environment variables
- compiled artifacts
- authentication tokens
- browser sessions
- build caches
Ephemeral runners significantly reduce this risk.
86.7 Network Isolation
A build runner does not necessarily need unrestricted Internet access.
Instead, network access should be controlled.
For example:
CI Runner
├── Source Repository
├── Approved Package Registry
├── Artifact Registry
└── Required Security Services
Everything else can be restricted according to the organization's requirements.
Network controls can reduce:
- unauthorized data exfiltration
- malicious callback connections
- command-and-control communication
- dependency download abuse
- accidental access to internal systems
The correct policy should depend on the build architecture.
86.8 Dependency Resolution Security
Dependencies are part of the build input.
Therefore:
Source Code + Dependencies
↓
Build
means the security of the resulting artifact depends partly on the security of the dependency acquisition process.
A secure build system should use:
- lockfiles
- version constraints
- trusted registries
- dependency allowlists where appropriate
- checksum/integrity verification
- vulnerability scanning
- software bills of materials
- controlled update processes
The dependency graph should be visible.
86.9 Build Reproducibility
A powerful security property is reproducibility.
Ideally:
Same Source
+
Same Dependencies
+
Same Build Environment
+
Same Build Configuration
↓
Same Artifact
If the same inputs unexpectedly produce different outputs, investigation may be necessary.
Perfect reproducibility is not always practical for every system, but build systems should maximize verifiability.
Useful controls include:
- pinned dependencies
- deterministic build configuration
- controlled compiler versions
- fixed base images
- immutable build inputs
- recorded environment metadata
- deterministic packaging
- artifact checksums
86.10 Artifact Integrity
After building an artifact, its identity should be established.
Examples include:
- cryptographic hashes
- signed packages
- signed container images
- signed metadata
- registry-controlled versions
Conceptually:
Artifact
↓
Hash
↓
Signature
↓
Trusted Identity
The deployment system can then verify that the artifact has not changed since it was approved.
86.11 Artifact Signing
Artifact signing establishes authenticity and integrity.
A conceptual process is:
Build
↓
Artifact
↓
Hash
↓
Digital Signature
↓
Artifact Registry
At deployment:
Production Deployment
↓
Verify Signature
↓
Verify Artifact Identity
↓
Verify Policy
↓
Deploy
Signing keys must be strongly protected.
They should not be stored casually in:
- source repositories
- plaintext configuration
- developer laptops
- ordinary build logs
High-value signing operations should use appropriate protected key-management mechanisms.
86.12 Key Separation
Different purposes should use different credentials and signing identities where practical.
For example:
Development Signing Identity
≠
Staging Signing Identity
≠
Production Signing Identity
This limits blast radius.
If a development credential is compromised, it should not automatically enable production artifact signing.
86.13 Build Provenance
Artifact integrity answers:
“Has this artifact changed?”
Provenance helps answer:
“Where did this artifact come from?”
Useful provenance information may include:
- source repository
- source revision
- build pipeline
- builder identity
- build timestamp
- dependency information
- build configuration
- parent artifacts
- evaluation status
- signing information
Conceptually:
Artifact
│
├── Source Revision
├── Builder
├── Build Process
├── Dependencies
├── Tests
├── Evaluations
└── Signature
This makes forensic investigation and deployment verification much easier.
86.14 AI-Specific Build Inputs
Traditional software builds are not the only concern for AI systems.
An AI platform may build or package:
- model weights
- tokenizer files
- prompt templates
- system instructions
- safety policies
- evaluation datasets
- embedding configurations
- RAG configurations
- agent tool definitions
- model-routing rules
- preprocessing pipelines
- post-processing logic
These should be treated as controlled release artifacts.
For example:
Application Code
+
Model
+
Prompt
+
Policy
+
RAG Configuration
+
Tool Definitions
↓
AI Release Artifact
Changing a prompt or model-routing policy can materially change system behavior even when application source code has not changed.
86.15 Model Artifact Verification
AI model files can be large and may originate from external repositories.
Before production use, model artifacts should be evaluated and verified.
Possible checks include:
- expected model identity
- expected version
- checksum
- source provenance
- licensing status
- malware scanning where applicable
- architecture compatibility
- evaluation results
- safety evaluation status
- resource requirements
A production system should not automatically trust every model file that can be downloaded.
86.16 Container Image Security
AI platforms frequently use containers.
A secure container pipeline should include:
Base Image
↓
Dependency Installation
↓
Application Build
↓
Security Scan
↓
Image Creation
↓
Image Signing
↓
Registry
↓
Deployment Verification
Important controls include:
- trusted base images
- pinned image versions
- vulnerability scanning
- minimal images
- non-root execution where possible
- image signing
- provenance
- registry access control
- immutable release references
86.17 Base Image Governance
A base image can introduce vulnerabilities before application code is added.
Therefore, organizations should maintain approved base-image policies.
Example categories:
Approved
├── Supported OS Image
├── Supported Runtime
└── Approved Security Baseline
Restricted
├── Unknown Image
├── Unmaintained Image
└── Unverified External Image
Base images should have identifiable owners and update processes.
86.18 CI Pipeline Configuration Security
Pipeline configuration itself is executable logic.
For example, a pipeline may define:
- commands
- permissions
- secrets
- deployment steps
- artifact destinations
- test execution
- external integrations
Therefore, pipeline configuration should receive the same security attention as application code.
Recommended controls include:
- version control
- code review
- restricted modification permissions
- security review for privileged pipeline changes
- validation
- audit history
- protected branches
- deployment approval controls
86.19 Secret Handling in CI/CD
Secrets are especially dangerous inside CI systems because logs and build processes can expose them.
Secrets should preferably be:
- injected only when required
- short-lived
- scoped
- rotated
- masked in logs
- inaccessible to untrusted jobs
- separated by environment
A strong design is:
Build Job
↓
No Production Secrets
Deployment Job
↓
Short-Lived Deployment Credential
This is safer than making every build job capable of accessing production.
86.20 Pull Request Security
Pull requests may contain code that has not yet been trusted.
Therefore, workflows triggered by untrusted changes should not automatically receive sensitive credentials.
The security model should distinguish:
Trusted Internal Change
vs.
Untrusted External Change
This distinction is particularly important when automated workflows execute arbitrary project code.
86.21 Approval Gates
Production deployment should have explicit conditions.
A possible release gate is:
Build Passed
↓
Security Scan Passed
↓
Tests Passed
↓
AI Evaluation Passed
↓
Artifact Signed
↓
Provenance Verified
↓
Approval
↓
Production Deployment
A failed critical gate should stop the release.
86.22 Separation of Duties
For sensitive production environments, the same person should not necessarily control every stage.
A stronger model can separate:
- development
- code review
- security validation
- release approval
- production deployment
This reduces the risk of a single compromised account bypassing the entire control chain.
86.23 Build Policy Enforcement
Security requirements should ideally be machine-enforced.
Examples:
IF artifact is unsigned
→ reject deployment
IF critical vulnerability exists
→ reject release
IF provenance is missing
→ reject release
IF required evaluation is missing
→ reject release
IF production approval is missing
→ reject release
This is stronger than relying exclusively on documentation.
86.24 Artifact Promotion
An artifact should ideally be built once and promoted between environments.
Example:
Build
↓
Artifact A
↓
Test
↓
Artifact A
↓
Staging
↓
Artifact A
↓
Production
Rather than:
Build for Test
Build Again for Staging
Build Again for Production
Rebuilding separately can introduce differences between environments.
Artifact promotion helps preserve release identity.
86.25 Immutable Artifacts
Once an artifact is approved, it should not silently change.
Instead:
application:v1.4.2
should refer to a specific immutable artifact identity.
If a new build is required, it should receive a new identity.
This makes deployment and rollback much more predictable.
86.26 Security Testing in CI
CI should automatically execute appropriate security checks.
Potential categories include:
Static analysis
Examines source code for security issues.
Dependency analysis
Identifies vulnerable or suspicious dependencies.
Secret detection
Detects accidentally committed credentials.
Container scanning
Checks container images.
Infrastructure scanning
Checks infrastructure definitions.
API security testing
Tests application interfaces.
AI evaluation
Tests model behavior, safety, quality, robustness, and regression.
The precise tests should reflect the application's threat model.
86.27 AI Evaluation as a Release Gate
For AI systems, ordinary unit tests are insufficient.
A model update may compile successfully while changing behavior significantly.
Therefore:
Model Update
↓
Functional Tests
↓
Quality Evaluation
↓
Safety Evaluation
↓
Regression Evaluation
↓
Approval
Important measurements can include:
- accuracy
- hallucination rate
- refusal behavior
- safety behavior
- retrieval quality
- latency
- cost
- tool-call correctness
- multilingual performance
- multimodal performance
86.28 CI/CD Observability
The build system should generate operational telemetry.
Useful information includes:
- build duration
- failed stages
- deployment frequency
- artifact creation
- security scan results
- approval events
- deployment events
- rollback events
- pipeline permission changes
- runner creation
- credential usage
Security logs should be protected against unauthorized modification.
86.29 Pipeline Audit Trail
A complete release should be traceable.
For example:
Release ID
↓
Source Commit
↓
Pull Request
↓
Build
↓
Dependencies
↓
Tests
↓
AI Evaluations
↓
Artifact Digest
↓
Signature
↓
Approval
↓
Deployment
This creates a useful chain for both security investigation and operational debugging.
86.30 Failed Build Handling
A failed build should not partially publish trusted artifacts.
The system should clearly distinguish:
Build Failed
from:
Build Completed but Release Blocked
and:
Artifact Approved
This state separation prevents accidental deployment of incomplete outputs.
86.31 Pipeline Failure Containment
A compromised or malfunctioning build should have limited blast radius.
Useful controls include:
- isolated runners
- restricted credentials
- network segmentation
- disposable environments
- artifact quarantine
- registry permissions
- independent security scanning
- deployment approval
The goal is:
A compromised build should not automatically become a compromised production environment.
86.32 Emergency Security Releases
Critical vulnerabilities sometimes require rapid deployment.
Emergency procedures should already exist.
A controlled emergency path may be:
Critical Vulnerability
↓
Emergency Change Classification
↓
Security Validation
↓
Authorized Approval
↓
Expedited Deployment
↓
Enhanced Monitoring
↓
Post-Incident Review
Emergency procedures should not mean “remove all security controls.”
They should mean “use a predefined faster control path.”
86.33 Rollback Security
Rollback must be tested and controlled.
A secure rollback should identify:
- previous artifact
- previous model
- previous configuration
- previous policy
- database compatibility
- deployment owner
- reason for rollback
Rollback artifacts should remain verifiable.
86.34 Build System Disaster Recovery
CI/CD is part of platform resilience.
If the primary build system becomes unavailable, the organization should know:
- where source code is stored
- where artifacts are stored
- how signing works
- how deployment credentials are recovered
- how pipelines are reconstructed
- how trusted builders are restored
- how release history is recovered
A platform that cannot securely rebuild after a major incident may become operationally dependent on an unavailable system.
86.35 Build Security Checklist
A production AI platform should verify:
Source
- [ ] Protected repository
- [ ] Strong authentication
- [ ] Branch protection
- [ ] Code review
- [ ] Controlled privileged changes
CI runners
- [ ] Ephemeral where practical
- [ ] Isolated
- [ ] Least privilege
- [ ] Network controlled
- [ ] No unnecessary persistent credentials
Dependencies
- [ ] Lockfiles
- [ ] Trusted registries
- [ ] Vulnerability scanning
- [ ] Integrity verification
- [ ] SBOM generation
Build
- [ ] Controlled environment
- [ ] Versioned build configuration
- [ ] Reproducibility strategy
- [ ] Security tests
- [ ] AI evaluation
Artifacts
- [ ] Immutable identity
- [ ] Hash/digest
- [ ] Signature
- [ ] Provenance
- [ ] Registry access control
Deployment
- [ ] Approval gates
- [ ] Signature verification
- [ ] Provenance verification
- [ ] Environment separation
- [ ] Rollback capability
Operations
- [ ] Audit logging
- [ ] Monitoring
- [ ] Incident response
- [ ] Emergency release process
- [ ] Disaster recovery
86.36 Reference Secure Build Architecture
A mature AI platform can use the following conceptual architecture:
┌─────────────────────┐
│ Source Repository │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Change Review/Gates │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Ephemeral CI Runner│
└──────────┬──────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Build/Test Security Scan AI Evaluation
│ │ │
└─────────────────┼─────────────────┘
▼
┌─────────────────────┐
│ Artifact Creation │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Signature + │
│ Provenance │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Trusted Registry │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Release Approval │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Deployment Control │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Production │
└─────────────────────┘
The important property is that production does not trust the build process blindly.
It verifies the resulting artifact and its release evidence.
86.37 Build Security Maturity Model
A useful maturity progression is:
Level 1 — Basic
- source control
- basic CI
- automated tests
- manual deployment
Level 2 — Controlled
- dependency scanning
- protected branches
- environment separation
- deployment approvals
Level 3 — Verified
- signed artifacts
- provenance
- SBOM
- ephemeral runners
- automated policy enforcement
Level 4 — Advanced
- reproducible builds
- strong workload identity
- automated verification
- AI-specific release evaluation
- continuous supply-chain monitoring
Level 5 — Resilient
- independently verifiable builds
- hardened build infrastructure
- strong separation of duties
- automated containment
- tested disaster recovery
- complete artifact lineage
86.38 Final Security Principle
The build pipeline is not merely a developer convenience.
It is part of the security architecture.
A production AI platform should be able to answer:
What source created this artifact?
Which dependencies were included?
Which builder produced it?
Which tests and AI evaluations passed?
Who approved it?
Has the artifact changed?
Can the deployment system verify its signature?
Can the organization trace the artifact back to its source?
Can the release be safely rolled back?
If these questions cannot be answered reliably, the platform has an important supply-chain security gap.
The strongest architecture treats every production artifact as a verifiable release object with:
known origin + controlled build + isolated execution + verified dependencies + security testing + AI evaluation + cryptographic identity + provenance + authorization + monitored deployment.
That approach transforms CI/CD from a simple automation pipeline into a trusted software and AI delivery control plane.
Chapter 86 Summary
Secure AI build systems should provide:
- trusted source control
- protected change workflows
- isolated build runners
- least-privilege pipeline permissions
- controlled dependency acquisition
- reproducible or verifiable builds
- immutable artifacts
- cryptographic signing
- build provenance
- secure container construction
- AI model and prompt verification
- automated security testing
- AI quality and safety evaluation
- release approval gates
- artifact promotion
- deployment verification
- complete audit trails
- secure rollback
- emergency release procedures
- build-system disaster recovery
Core principle:
Never allow production to trust an artifact merely because a CI pipeline produced it. Production should trust only artifacts whose identity, origin, integrity, evaluation status, and authorization can be independently verified.
Top comments (0)