Part 2 of: Aligning with the UK’s Software Security Code of Practice

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:

1. Access Control
   • Are all accounts accessing the build system federated and MFA-enforced?
   • Are temporary credentials used for CI/CD workflows?
2. Build Process Integrity
   • Are artifacts cryptographically signed and traceable to source commits?
   • Can you demonstrate an immutable audit trail of builds?
3. Logging and Monitoring
   • Are logs centrally aggregated and reviewed weekly/monthly?
   • Are there established SLAs for investigating CI/CD anomalies?
4. 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

Frequently asked questions

How should I secure my CI/CD pipeline under the UK Software Security Code of Practice?

The article focuses on reducing the chance of unauthorised access or tampering in the build and release process. Practical steps include using isolated, ephemeral build agents, enforcing multi-factor authentication, protecting branches and merge requests, and keeping logs in a central system. It also recommends treating build integrity as a governance issue, not just a developer task.

What does the article mean by ephemeral build agents?

Ephemeral build agents are short-lived runners that are created for a build and then discarded afterwards. This helps reduce residue risk, such as secrets left in memory or unwanted processes carried over between jobs. The article suggests using dedicated virtual machines or containers to keep projects and tenants separated.

How should secrets and signing keys be stored for build and release workflows?

The article advises against hardcoding secrets in source code or CI/CD variables. Instead, credentials, signing keys and tokens should be kept in a dedicated secrets manager, with short-lived credentials where possible. It also recommends code signing for binaries and build artefacts so they can be verified before deployment.

What kind of change control does the article recommend for build systems?

Changes to code, configuration and infrastructure should go through protected branches and merge policies rather than direct commits to main or master branches. The article suggests requiring approval from multiple reviewers, including code owners and security reviewers for higher-risk changes. It also recommends status checks such as linting, unit tests and security scans before changes are accepted.

What should leadership ask about logging and monitoring in the build environment?

Leadership should check that logs are centralised, immutable where practical, and reviewed on a regular basis. The article highlights build starts and finishes, pipeline definition changes, secrets access, login events and permission changes as useful events to record. It also suggests having clear response times for investigating unusual CI/CD activity.