Summary
Software and configuration must be stored within an approved version control system.
Description
Version control is required to maintain a history of all software and configuration changes across all releases. It provides traceability of who made changes and when, establishing the provenance of software over time.
The control establishes verifiable evidence of the state of source code or configuration at the time a release was created. This is important not only for identifying who made changes, but also for understanding what functionality existed at a given point in time — enabling diagnosis of software behaviour weeks, months, or even years after it was originally built, tested, and deployed.
Version control is also integral to ensuring that the software being built and tested is the same software being deployed, by tracking the specific commit or version and providing a reference for traceability.
The integrity of this history is what gives it evidentiary value. The objective is that history cannot be altered or destroyed without detection — not that it can never change. Strict immutability is the simplest way to achieve this, but it is equally acceptable to permit amendment where the system retains a retrievable, attributable record of what changed and why. Unauthorised modification or deletion remains prohibited; only authorised, logged amendment — such as purging a committed secret — is permitted.
Requirements
In order for a version control system to be effective, it must provide the following properties when used for storing software and configuration.
- Tamper-Evident History — The version control system must either preserve history immutably, or provide a retrievable, attributable record of the events and changes that took place, such that the state of the software and configuration at any past point in time can be reconstructed. In either case, history must not be silently or undetectably altered or destroyed.
- Controlled History Amendment — Where history is amended for legitimate reasons — for example, to remove committed secrets or personal data that must not persist — the amendment must be an authorised, logged exception. The fact of the amendment, its justification, and the authorising party must be recorded, and the amendment must not be used to obscure the legitimate change record.
- Release Traceability — It must be possible to retrieve the exact version (commit or revision) of software and configuration that was released to production, for the applicable retention period.
- Verified Committers — The version control system must record the author of each change. Techniques such as commit signing could be employed to demonstrate this.
- Retention — History must be maintained for the lifetime of the software or in alignment with applicable retention requirements.
- Access Control — The version control system must support access control and should be configured appropriately.
Examples
Git is the most widely adopted distributed version control system and is the de facto standard for software development in regulated and non-regulated environments alike.
- Tamper-Evident History — Every commit is identified by a cryptographic SHA hash derived from its content and its parent commits, making silent tampering detectable. Branch protection rules on the default and release branches block force-pushes and history rewrites, so published history cannot be altered; where a secret must be purged, the rewrite is performed as an authorised, logged exception rather than an everyday operation.
- Verified Committers — Git supports GPG and SSH commit signing natively. Hosting platforms such as GitHub and GitLab can be configured to require signed commits on protected branches.
- Access Control — Enforced at the hosting platform level via branch protection rules, required reviewers, and role-based repository permissions.
Subversion (SVN) is a centralised version control system still found in some legacy financial services environments.
- Tamper-Evident History — SVN maintains a sequential, server-side revision history. Once committed, revisions cannot be altered without administrator access to the repository backend, and such backend actions are logged and attributable.
- Verified Committers — SVN records the authenticated username against each commit. Commit signing is not natively supported; identity relies on server authentication (e.g. LDAP, Kerberos).
- Access Control — Controlled server-side via path-based authorisation, allowing fine-grained read/write permissions per directory or branch.