How to Implement ISO 27001 Annex A 8.4 Access to Source Code

Implementing ISO 27001 Annex A 8.4 is the technical enforcement of Access to Source Code protocols to protect intellectual property and software integrity. This control mandates strict Role-Based Access Control (RBAC), branch protection rules, and cryptographic code signing to prevent unauthorised modifications and mitigate software supply chain attacks.

ISO 27001 Annex A Access to Source Code Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.4 by physically restricting and technically verifying who can read, write, and modify your organisation’s intellectual property. Effective control relies on rigorous Git configuration and identity management, not on uploading a policy document to a compliance portal.

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.

ISO 27001 Annex A 8.4 SaaS / GRC Platform Implementation Failure Checklist

Comparison of SaaS Compliance Claims vs. Real-World Source Code Security

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Access Restriction	GRC tool asks: “Do you use GitHub?” and marks the control as “Monitored”.	Fails if you have 50 “Outside Collaborators” from three years ago who still have full Admin rights to your core IP.
Branch Protection	SaaS platform checks if a policy exists in the document library.	Fails if a junior dev can force-push to `main` at 2 AM because the actual technical rule wasn’t enabled in settings.
Secret Scanning	Tool relies on a questionnaire: “Do you check for secrets?”	Fails if `AWS_ACCESS_KEY` is hardcoded in line 402 of `utils.js`. Only a pre-commit hook or scanner catches this, not a survey.
Code Signing	Ignored by most GRC dashboards as “too technical”.	Fails if an attacker spoofs a commit from your CTO. Without GPG signing, identity in Git is easily forged.
Local Encryption	Tool checks if “Antivirus” is installed.	Fails if the source code is on an unencrypted drive. Antivirus doesn’t stop physical theft of IP; full disk encryption does.
Dependency Management	Tool checks for “Software Bill of Materials” policy.	Fails if a developer types `npm install` and pulls a malicious typo-squatted package because you didn’t block public registry access.
Access Review	Automated email: “Do these users look okay?” (Manager clicks Yes).	Fails if the manager ignores the list. Real compliance requires a manual diff between Git users and HR payroll lists.

About the author