Annex I, Part I(2)(f) also requires protecting the integrity of programs and configuration against manipulation or modification that the manufacturer has not authorised. The build pipeline is where source code becomes the artifact that is delivered to users, so any weakness in it undermines every security control applied earlier in development. A build process that is undocumented, inconsistent or depends on manual steps is exposed to human error, and a build environment that isn't hardened can be abused to insert malicious code or swap artifacts without anyone noticing. Without a defined and protected build process, the manufacturer can't show that the delivered product matches the reviewed and tested source.

Formally define the build process end-to-end, as a set of clear instructions that either a person or an automated tool follows consistently to produce the same result each time. Keep this definition in one central, access-controlled location, preferably version-controlled next to the source code. The build definition must not contain secrets. Store the credentials the build needs, such as repository access tokens and signing keys, in a dedicated secrets management solution, encrypt them, and grant access on a least-privilege basis. Automating the build is strongly recommended, because it removes manual intervention and gives a natural place to run security checks. Where a build can't be fully automated, the formal definition must still be detailed enough that the build can be reproduced by someone other than its usual operator, and any manual steps must be documented and repeatable.

Use only build tools that the vendor or community actively maintains, keep them patched, and harden their configuration in line with vendor guidance and industry best practice. Pay particular attention to how they are exposed: web interfaces, runners/agents, and integrations with source repositories. Restrict who can change the build definition or the pipeline configuration, and review those changes the same way as code changes. Include appropriate security checks in the build, such as static analysis (SAST), dependency scanning and secret detection, and define how their findings are handled, for example as quality gates or through the defect management process. For every artifact produced, generate an integrity value such as a cryptographic hash or signature, and protect that value and any signing keys used. Keep the build definition, tooling inventory, hardening baseline and build records as part of the product's technical documentation (Annex VII), so the organisation can show that each released version was produced by a controlled, consistent and protected process.