Access to source code

What the requirement asks

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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Source code access is a business decision with security consequences. The guidance asks for the repository, the permission, the review and the separation of duties.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep source code management system configuration showing repository permissions with write access limited to designated owners or privileged staff and one live sample together.

Evidence an assessor asks for

• Source code protectionSource code management system configuration showing repository permissions with write access limited to designated owners or privileged staff
• Source code protectionBranch protection or merge rules requiring authorized review before changes are accepted, tied to change control
• Source code protectionAccess request and approval records for repository write access
• Source code protectionAudit logs of repository access and code changes
• Source code protectionAccess controls on build, integration and test tooling and on designs and specifications
• Source code protectionCode signing or other integrity mechanisms for published code

The question an assessor will ask

An assessor will ask for source code management system configuration showing repository permissions with write access limited to designated owners or privileged staff, then trace it to the system it protects. For A.8.4 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• 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

Before the next audit

Before the next audit, check one live sample for this gap: all developers have write and admin rights on every repository.