In this ultimate how to implement guide to ISO 27001 Annex A 8.4 Access to Source Code, you will learn directly from an ISO 27001 Lead Auditor:
Table of contents
- 1. Enforce Strict RBAC on Version Control Systems
- 2. Implement Branch Protection Rules
- 3. Deploy Pre-Commit Secret Scanning
- 4. Restrict Access to CI/CD Configuration Files
- 5. Mandate GPG Signing for Commits
- 6. Secure Local Source Code Storage
- 7. Segregate Read vs. Write Permissions
- 8. Implement IP Allow-Listing for Repository Access
- 9. Establish a Private Dependency Proxy
- 10. Conduct Quarterly Access Revocation Reviews
- About the author
1. Enforce Strict RBAC on Version Control Systems
Control Requirement: Access to program source code must be restricted to authorised personnel only.
Required Implementation Step: Log into your repository host (GitHub, GitLab, Bitbucket). Audit the “Teams” or “Groups” configuration. Remove any “All Employees” groups from having default read access to private repositories. Explicitly assign developers only to the specific repositories required for their current project sprint.
Minimum Requirement: The principle of ‘Least Privilege’ applied to repo visibility; Sales and HR must have zero access.
2. Implement Branch Protection Rules
Control Requirement: Changes to source code must be controlled and authorised.
Required Implementation Step: Configure the `main` or `master` branch settings to “Block direct pushes”. Enable “Require pull request reviews before merging” and set the minimum number of reviewers to at least one senior developer.
Minimum Requirement: No single developer can push code to production without a documented peer review.
3. Deploy Pre-Commit Secret Scanning
Control Requirement: Source code must not contain sensitive information like credentials or keys.
Required Implementation Step: Install local pre-commit hooks using tools like `trufflehog` or `git-secrets` on all developer workstations. Configure the CI/CD pipeline to fail the build immediately if high-entropy strings (potential API keys) are detected in the commit history.
Minimum Requirement: Automated prevention of hard-coded passwords entering the version control history.
4. Restrict Access to CI/CD Configuration Files
Control Requirement: The build environment and its configuration must be protected.
Required Implementation Step: Locate your pipeline definition files (e.g., `.github/workflows`, `Jenkinsfile`, `.gitlab-ci.yml`). Apply a `CODEOWNERS` rule that restricts write access to these specific files to DevOps Leads only, preventing developers from modifying build steps to exfiltrate secrets.
Minimum Requirement: Developers can modify application code, but not the security rules of the build pipeline.
5. Mandate GPG Signing for Commits
Control Requirement: The integrity and authorship of source code changes must be verified.
Required Implementation Step: Require developers to generate GPG keys and upload the public key to the version control system. Configure the repository to “Require signed commits”. This cryptographically proves that the code came from a specific developer’s machine, not a spoofed account.
Minimum Requirement: Rejection of any commit that lacks a valid digital signature.
6. Secure Local Source Code Storage
Control Requirement: Source code must be protected when stored on development environments.
Required Implementation Step: Open your Mobile Device Management (MDM) or Group Policy settings. Verify that “Full Disk Encryption” (BitLocker or FileVault) is enforced on all endpoints that have `git clone` permissions. Disable USB mass storage write access on these machines to prevent code theft.
Minimum Requirement: If a developer’s laptop is stolen, the source code on the disk remains inaccessible.
7. Segregate Read vs. Write Permissions
Control Requirement: Access rights must be granular based on business need.
Required Implementation Step: Audit your Service Accounts used for build tools. Downgrade their permissions so they have “Read Only” access to the source code repository. They should only have “Write” access to the binary artifact repository (e.g., Artifactory, Docker Hub), not the source code itself.
Minimum Requirement: Build servers can pull code but cannot push changes back to the repository.
8. Implement IP Allow-Listing for Repository Access
Control Requirement: Access to source code should be restricted to trusted networks.
Required Implementation Step: Configure your Git host to accept connections only from the corporate VPN IP address or specific office static IPs. Block access from anonymous public proxies or unauthorised geographic regions.
Minimum Requirement: Source code cannot be cloned from a coffee shop without traversing the corporate VPN.
9. Establish a Private Dependency Proxy
Control Requirement: Protect against supply chain attacks and malicious libraries.
Required Implementation Step: Set up a local repository manager (like Nexus or JFrog). Configure development environments to pull libraries (npm, pip, maven) solely from this internal proxy, not directly from the public internet. Block direct access to `npmjs.com` or `pypi.org` at the firewall.
Minimum Requirement: Prevention of “Dependency Confusion” attacks by vetting external libraries before they enter the environment.
10. Conduct Quarterly Access Revocation Reviews
Control Requirement: Access rights must be reviewed and removed when no longer needed.
Required Implementation Step: Export the user list from your version control system. Manually cross-reference this against the HR “Leavers” list and the current project resource plan. Immediately revoke keys and access for any user not actively contributing to the codebase.
Minimum Requirement: Evidence of manual sign-off confirming that every user with access is still an active employee.
About the author
