8.4 Access to source code
Who may read or change source code, software libraries and development tools is to be properly managed. Purpose: stop unauthorized functionality being introduced, prevent accidental or malicious changes and keep valuable intellectual property confidential. Guidance: strictly control access to source code and related items such as designs, specifications and verification and validation plans, and to development tooling including compilers, build and integration tools, and test platforms and environments. For source code, control its central storage, preferably in a source code management system. Read and write access can differ by role: read access may be broad within the organization while write access goes only to privileged staff or designated owners; shared code components should be read from a central repository; open source or third-party repositories may be widely readable but write access stays restricted. To reduce the chance of corrupting programs, consider managing access to source code and source libraries through established procedures; granting read and write access by business need, managed against the risk of alteration or misuse; updating code and related items, and granting access, only under change control (8.32) and after proper authorization; giving developers access through developer tools that control their actions and authorizations rather than directly to the repository; keeping program listings somewhere secure with managed access; and keeping an audit log of all access and changes to source code. If code is to be published, consider added integrity assurance such as a digital signature. Other information: poorly controlled access lets code be altered or lets unauthorized people retrieve development environment data such as production data copies or configuration details.
Source: ISO/IEC 27002:2022, 8.4. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Source code management system configuration showing repository permissions with write access limited to designated owners or privileged staff · Identity provider / directory
- Audit logs of repository access and code changes · SIEM / log platform
periodic reviewEvidence produced at each review
- Branch protection or merge rules requiring authorized review before changes are accepted, tied to change control · Source control / CI pipeline
- Access request and approval records for repository write access · Identity provider / directory
governing documentDocuments that govern the control
- Access controls on build, integration and test tooling and on designs and specifications · Policy repository / GRC workspace
- Code signing or other integrity mechanisms for published code · Policy repository / GRC workspace
First move
Common gaps auditors find
- All developers have write and admin rights on every repository
- Changes can be pushed directly to main branches without review
- Secrets or production data copies are stored in repositories accessible to many people
- Leavers retain access to hosted repositories through personal accounts
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet8.3 Information access restriction · 8.5 Secure authentication