ISO 27001 A.8.4: Access to source code
What This Control Requires
Read and write access to source code, development tools and software libraries shall be appropriately managed.
In Plain Language
Your source code is both intellectual property and a potential attack roadmap. If someone with bad intentions gets read access, they can study your logic for vulnerabilities. If they get write access, they can introduce backdoors directly. Either scenario is a nightmare.
Read and write access need different treatment. Developers typically need broad read access for collaboration, but write access to production branches should be tightly controlled. Not everyone needs access to everything - restrict by project and role.
This is not just about the code files themselves. Your development environment, build systems, deployment pipelines, configuration management, and dependency libraries all need the same level of access discipline. A compromised build pipeline can be just as damaging as compromised source code.
How to Implement
Set up role-based permissions on all source code repositories using platforms like GitHub, GitLab, or Bitbucket. Define clear access tiers: read-only for reviewers and auditors, write access for active developers on relevant projects, maintainer access for team leads managing branches and merges, and admin access for repository administrators only.
Configure branch protection on main and production branches. Block direct pushes. Require pull requests with code review before any merge. Enforce minimum reviewer approvals - two reviewers for security-sensitive code. Require CI/CD checks to pass before merging. Use signed commits to verify contributor identity.
Lock down your development infrastructure. Restrict who can modify CI/CD pipeline configurations. Protect secrets management systems (API keys, credentials used in builds) with the same rigour as production secrets. Enable audit logging on all build and deployment activities. Use hardened build environments.
Control your software dependencies. Maintain a list of approved libraries. Use private package registries or mirrors so you control what comes in. Run dependency scanning for known vulnerabilities. Pin dependencies and check integrity hashes to prevent supply chain attacks. Require approval for new third-party dependencies.
Review source code access rights regularly. Revoke access immediately when developers change roles or leave. Audit access logs for unusual patterns like bulk downloads or late-night activity. Make sure former contractors have zero residual access.
Guard against unauthorised disclosure. Deploy DLP controls on code repositories. Ban personal accounts on organisational repos. Monitor for your code appearing on public repositories like GitHub. Cover source code handling in your acceptable use policy and NDAs.
Evidence Your Auditor Will Request
- Source code repository access control configuration and permissions
- Branch protection rules showing code review and merge requirements
- CI/CD pipeline access controls and audit logs
- Source code access review records showing periodic verification
- Software dependency management and approval records
Common Mistakes
- All developers have unrestricted access to all repositories regardless of project assignment
- No branch protection rules allowing direct pushes to production branches
- Former developers retain access to source code repositories after departure
- Build pipeline secrets are not properly protected
- No monitoring for source code appearing in unauthorized public repositories
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| SOC 2 | CC6.1 | Partial overlap |
| SOC 2 | CC8.1 | Related |
| NIS2 | Art.21(2)(e) | Partial overlap |
Frequently Asked Questions
Should we restrict read access to source code or only write access?
How do we prevent source code leaks?
Track ISO 27001 compliance in one place
AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.
Start Free Assessment