Access to source code
Purpose
Properly manage read and write access to source code, development tools and software libraries.
How to meet this control
In short: Manage read/write access to source code and tools appropriately.
- Step 01Host all source in a managed platform such as GitHub, GitLab or Azure DevOps and restrict repository visibility to the teams that need it
- Step 02Turn on branch protection so the main branch requires pull requests, a passing build and at least one reviewer before merge
- Step 03Scope write access narrowly through teams, keeping most engineers at read or contributor level and limiting admin to a few owners
- Step 04Enable secret scanning and push protection so credentials committed to code are blocked or flagged automatically
- Step 05Require signed commits or signed tags for releases so code provenance can be verified
- Step 06Retain the full audit log of repository access, permission changes and merges
Tip: Branch protection, required reviews, and restricted repo access.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Strictly control access to source code, designs, build tools and test environments
- ›Keep source in a managed central repository, ideally a source code management system
- ›Set read versus write access by role, keeping write access narrow
- ›Manage program source libraries under documented procedures
- ›Update code and grant access only through change control and after authorisation
- ›Route developers through controlled tools rather than direct repository access
- ›Hold program listings securely and keep an audit log of all access and changes
- ›If publishing source code, add integrity controls such as digital signatures
Audit evidence to keep
- - Branch protection ruleset screenshot for the main branch
- - Repository access and team permission export showing read versus write split
- - Secret scanning or push protection configuration and a sample blocked-secret alert
- - Audit log of a permission change or a merged pull request with reviewer
- - Evidence of signed commits or release signing if used
Common mistakes
- - Approving access in chat with no retained record
- - Copying access from another user without checking least privilege
- - Reviewing access but not proving removals were completed
Owner, cadence, and proof
Assign one accountable owner for A.8.4. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.