# Chapter 86 — Secure AI Platform Build Systems & CI/CD Security

— 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.