Traceability links a software change to evidence of what changed, who made it, when it happened, how it was reviewed, and what reached a deployed environment. It supports release preparation by connecting artifacts and versioning to the changes they contain, and it supports compliance by making change history provable. section 8.5 section 11.0
Git supplies a starting audit trail: its history records changes, committers, and timestamps. That record is not sufficient when an organization must establish that a GitHub identity belongs to a real employee, or when locally authored commit names and email addresses could be forged. Stronger identity controls make the trail more trustworthy. section 11.1 section 11.1.1
Build a traceable change path with connected controls:
- Authenticate contributors through GitHub; use two-factor authentication for stronger login assurance, and use an identity provider through SSO when enterprise identity linkage is required. section 11.1
- Require signed commits through branch protection. Configure Git with a GPG signing key and default commit signing, or use supported S/MIME or SSH signing approaches. section 11.1.1
- Use pull requests and branch policy to preserve required reviews and approvals, including evidence that the four-eyes principle was applied. section 11.2.2 section 11.4
- Associate deployments with released, tagged versions so an environment can lead back through a pull request and issue to the requirement and source changes. section 11.2.2
Tracing a production deployment backward
A deployed environment displays its current software version. Following that version reaches the Git tag created for the release, then the pull request that defined the change, then the issue holding its requirement. The pull request also retains the required approval, connecting deployment evidence to review evidence. section 11.2.2
Traceability and review controls work together but answer different questions. Traceability establishes the identity, history, and path of a change; the four-eyes principle establishes that another person reviewed it. SSO, signed commits, branch protection, CODEOWNERS, and mandatory workflows can standardize these controls across CI/CD practices. section 11.0 section 11.4
Figure 11.5 Deployments view
Use the deployments view to follow a deployed version to its release tag, pull request, requirement, and review approval. section 11.2.2
