Build Environment Security – A Technical and Organisational Implementation Guide
Overview
This section of the UK government’s Software Security Code of Practice makes use of the Principles-Based Assurance (PBA) model. Each security principle maps to a set of “claims” (outcomes you assert) and must be supported with tangible evidence.
This guide provides:
- A breakdown of the requirements
- Step-by-step developer guidance
- Governance-level evaluation mechanisms
- Recommended commercial and open-source tooling
- Strategies for executive and operational enablement
Objective
To ensure the integrity, confidentiality, and availability of the software build and delivery pipeline by protecting it against compromise. This includes securing developer environments, CI/CD systems, artifact stores, credentials, and change workflows. A compromised build system can be exploited to inject malware, bypass controls, or exfiltrate sensitive assets, making this a high-risk attack vector (see: SolarWinds, XZ Utils backdoor).
1. Build Pipeline Hardening
What this means
Prevent unauthorised access, privilege escalation, or manipulation of the build and release process.
Technical Implementation
Isolated and Ephemeral Build Agents
- Use short-lived, ephemeral runners (e.g., GitHub Actions ephemeral runners, GitLab autoscaling runners).
- Prevent reuse of build environments to reduce residue risks (e.g., secrets in memory, rogue processes).
- Run builds in dedicated VMs or containers to isolate projects and tenants.
Enforce Multi-Factor Authentication (MFA)
- Enforce MFA for all user and service accounts accessing:
- CI/CD platforms (e.g., Jenkins, GitHub, GitLab)
- Source code repositories
- Artifact registries
- Use SSO integration via IdPs like Okta or Azure AD for consistency and auditing.
Secrets and Key Management
- Do not hardcode secrets in source code or CI/CD variables.
- Store credentials, signing keys, and tokens in a dedicated secrets manager:
- Commercial: HashiCorp Vault Enterprise
- Open Source: Mozilla SOPS + GitOps, HashiCorp Vault OSS
Secure Signing and Verification
- Use code signing for binaries and build artifacts.
- Implement Sigstore for signing and verifying container images, packages, and releases.
- Prevents tampering of build artifacts between creation and deployment.
2. Change Control and Approvals
What this means
Ensure that all code, configuration, and infrastructure changes are reviewed and traceable.
Technical Implementation
Enforce Protected Branches & Merge Policies
- Block direct commits to main/master branches.
- Require pull/merge request approval by multiple reviewers, including:
- Code owners
- Security reviewers for high-risk changes
- Enforce status checks:
- Linting
- Unit tests
- Security scans (SAST/SCA)
Code Signing and Provenance Tracking
- Integrate in-toto or SLSA (Supply-chain Levels for Software Artifacts) to validate build steps.
- Enforces provenance: who built what, when, from which sources.
Potentially useful tools
- Commercial: GitHub Enterprise w/ Code Owners, Branch Protection, and required reviewers
- Open Source: GitLab CE with merge request approval rules, pre-commit hooks, and SLSA toolchain
3. Centralised Audit Logging and Monitoring
What This Means
Detect unauthorised or anomalous activity within build and deployment environments.
Technical Implementation
Immutable and Centralised Logs
- Enable logging of:
- Build initiation and completion
- Changes to CI/CD pipeline definitions
- Secrets access
- User login events and permission changes
- Export logs to a central SIEM or logging platform:
- Set data retention policies that align with internal and regulatory requirements (e.g., 12-36 months)
- Prevent tampering by writing logs to append-only storage
Potentially useful tools
- Commercial: Splunk, Datadog CI Visibility, Microsoft Sentinel
- Open Source: ELK Stack (Elasticsearch, Logstash, Kibana) or Loki + Promtail + Grafana
Anomaly Detection and Alerts
- Set alerts for:
- Unexpected pipeline triggers (e.g., external PRs triggering full builds)
- Credential access outside business hours
- Modifications to signing keys, secrets, or deployment targets
- Integrate with SIEM or EDR to flag lateral movement or compromise of the CI/CD environment.
Executive Evaluation and Governance Controls
For senior leadership:
Ask your teams:
- Access Control
- Are all accounts accessing the build system federated and MFA-enforced?
- Are temporary credentials used for CI/CD workflows?
- Build Process Integrity
- Are artifacts cryptographically signed and traceable to source commits?
- Can you demonstrate an immutable audit trail of builds?
- Logging and Monitoring
- Are logs centrally aggregated and reviewed weekly/monthly?
- Are there established SLAs for investigating CI/CD anomalies?
- Self-Assessment and Reporting
- Has your organisation mapped its current practices against the Code’s “claims” and provided evidence?
- Is there a plan for continuous improvement?
Enabling compliance across your organisation
Foundational Controls
- Appoint an SRO: Assign accountability to a named leader who owns SDLC and supply chain security.
- Define Baselines: Create and publish minimum security standards for CI/CD environments (e.g., MFA, ephemeral agents).
- Central Security Engineering Function: A team that builds hardened shared pipelines and supports application teams in adoption.
Training and Awareness
- Run DevSecOps training focused on:
- Secure CI/CD design
- Secrets hygiene
- Interpreting supply chain telemetry (e.g., SBOM diffs, SLSA attestations)
- Make training part of onboarding for all software engineers and DevOps staff.
Summary: What Good Looks Like (under the UK Software Security Code of Practice)
| Control Area | Expectation |
| Identity & Access | MFA enforced; federated identities; role-based access |
| Build Agents | Ephemeral, isolated runners; no shared state |
| Secrets Management | Centralised, encrypted storage; short-lived credentials |
| Code Approvals | Merge request with approvals, protected branches, status checks enforced |
| Logging | Immutable, centralised, reviewed regularly |
| Artifact Integrity | Signed builds; provenance tracked via SLSA or in-toto |
| Monitoring & Response | Alerts for pipeline anomalies; SIEM or EDR integration |
Final Recommendations
- Perform a gap analysis using the APC (Assurance, Principles & Claims) model provided in the Code of Practice.
- Start small: secure your most critical pipeline(s) first.
- Leverage automation for consistency across teams.
- Track maturity over time, move from basic hardening to zero-trust CI/CD architectures.
Missed part 1? You can find it at Part 1 of: Aligning with the UK’s Software Security Code of Practice
Comments are closed