A.8.4
Access to source code
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control manages read and change access to source code, build tools, libraries, and pipelines according to business need. It focuses on preventing unauthorized functionality, malicious changes, and accidental modification while preserving traceability. Restrict disclosure of confidential source and govern intentional open source publication through an approved policy. Protect write access and secrets regardless of publication status, and deploy necessary source securely where the runtime requires it.
Key checkpoints
- Is access to the source code repository (configuration/version control system) granted on a least-privilege, business-need basis, with read and write permissions managed separately?
- Is repository access authenticated with individually identifiable accounts, and are access/commit/merge/permission-change events logged so they can be audited?
- Is original source code kept off operational systems unless it is genuinely required, and is access to development tools, libraries, and build pipeline credentials also controlled?
- Are source code changes applied through a review process (code review, merge approval), with unapproved direct changes blocked?
- When external developers or suppliers access source code, are the scope and duration limited and governed by contract/confidentiality undertakings?
- Are access rights reviewed periodically and revoked immediately on termination or role change?
Implementation guidance
- Manage source code centrally in an authorized configuration/version control system, and separate read/write permissions by role at the repository/branch level.
- Use individually identifiable accounts and risk-appropriate repository authentication. Even with SSO, verify MFA and authentication policy for high-risk access, and collect records that make access, commits, merges, and permission changes traceable.
- Deploy only required runtime artifacts and remove unnecessary repository metadata, development material, and secrets. Retain source needed by interpreted or other runtimes while restricting external access to non-public files and unauthorized changes; minimize access to build tools and pipeline credentials.
- Control changes with code review and merge approval and with protected-branch policies (such as no force-push), blocking unapproved direct changes.
- Apply secret scanning and pre-commit checks to prevent hardcoded credentials/keys from entering the source code.
- Limit external personnel to only the repositories they need, revoke access immediately when the access period ends or the contract expires, and review the permission list periodically.
Evidence
- Access permission list and role/permission configuration screens of the configuration management system
- Repository access/commit/merge/permission-change logs
- Code review and merge approval records, protected-branch policy settings
- Periodic review records and revocation history of source code access rights
- Access-control contracts/confidentiality undertakings for external developers and evidence of scoped access assignment
- Results of secret scanning / pre-commit checks
Nonconformity examples
- Least privilege is not applied, for example all developers hold admin/write access to the source code repository.
- A shared account is used to access the repository, so the author of a change cannot be traced.
- Unnecessary source/repository material or non-public runtime files lack access controls on production servers, permitting unauthorized viewing or changes.
- Direct changes to a protected branch (such as force-push) are possible without code review/merge approval.
- Repository access rights of leavers or role-changed staff are not revoked and remain active.
- Credentials/keys are committed into the source code in hardcoded form, and no check detects them.