How to Protect Your Code Without Slowing Your Developers Down
ISO 27001 Control 8.4 – Access to source code – is about making sure your source code, development tools and software libraries are treated as high-value assets, not just “stuff in GitHub”.
If access to source code is poorly controlled, you’re exposed to:
- malicious changes (backdoors, data exfiltration, logic changes)
- accidental damage (“quick fix in main” going badly wrong)
- leaks of intellectual property or customer-specific logic
- supply chain attacks through compromised libraries or build tooling
This control is essentially asking:
“Can you show that only the right people – using the right tools – can change source code, and that everything is traceable and protected?”
This guide turns ISO 27001 Control 8.4 into practical steps you can actually implement and evidence.
What ISO 27001 Control 8.4 Actually Expects
In plain English, ISO 27001 Control 8.4 – Access to source code expects you to:
- Store source code in a central, controlled repository
- Use proper version control where all changes are attributable to individuals
- Apply role-based access (who can read vs who can write vs who can administer)
- Control and monitor access to development tools and build systems
- Apply formal change control to code changes (linked to Control 8.32)
- Log and review who accessed and changed what, and when
- Protect any publicly released code so others can verify its integrity
An auditor will typically ask:
- “Where is your source code stored?”
- “Who can access which repositories, and how is that controlled?”
- “Show me how you’d detect an unauthorised or suspicious change.”
Step 1 – Centralise Source Code and Enforce Version Control
You can’t control what you can’t see.
Make ISO 27001 Control 8.4 much easier by:
- Using a central source code management system
- e.g. GitHub, GitLab, Bitbucket, Azure DevOps, on-prem Git, etc.
- All “real” code lives here – not in random file shares or local machines.
- Enforcing proper version control practice
- Every change goes through commits and merge/pull requests.
- Commit history is preserved; no rewriting history for production branches.
- Branching strategy documented (e.g. main/master, develop, feature branches).
- Stopping unmanaged code repositories
- No side-projects with customer or production code sitting in personal accounts.
- No ad-hoc ZIPs of code being passed around via email or chat.
This gives you a single place where access, logging and security controls can be applied consistently.
Step 2 – Define a Role-Based Access Model for Source Code
Control 8.4 is explicit about restricting access to source code based on need.
A simple, effective model is:
- Read-only access
- Many developers may need to read code across multiple repositories.
- Read access can often be broad, as long as you’re comfortable with IP exposure.
- Still protected by authentication and authorisation – not public.
- Write (contribute) access
- Limited to those who actually need to modify that codebase.
- Usually part of a specific team (e.g. product squad, platform team).
- Changes go through merge requests with peer review and approvals.
- Privileged / admin access
- Repository admins, CI/CD admins, security engineers with special responsibilities.
- Very small group, ideally with multi-factor authentication (MFA) enforced and monitored.
Good practices:
- Use groups / teams / roles, not individual ad-hoc permissions.
- Review access regularly (e.g. quarterly) and on joiners, movers, leavers.
- Remove access promptly when people leave or change roles.
The aim is to show that access is deliberate, not accidental, and tied to job responsibilities.
Step 3 – Protect Development Tools, Build Systems and Libraries
ISO 27001 Control 8.4 isn’t just about the code files. It also calls out development tools and associated artefacts.
You should:
- Restrict access to build and deployment tools
- Compilers, build servers (e.g. Jenkins, GitHub Actions, GitLab runners), packaging tools, deployment tools, test harnesses.
- Only authorised staff can modify build pipelines, runners or configuration.
- Secure third-party and open-source components
- Maintain central registries or repositories for libraries and packages (e.g. internal package feeds).
- Allow developers to use libraries freely but restrict who can publish/update internal packages.
- Apply Software Composition Analysis (SCA) to track vulnerabilities in dependencies.
- Harden the development environment
- Strong authentication (MFA) for repository and CI/CD access.
- Network restrictions for build agents where possible.
- No sharing of generic “build user” credentials.
Remember: if an attacker compromises your build pipeline, they don’t need access to your application servers – they can ship malicious code for you.
Step 4 – Integrate Access to Source Code with Change Management
Controls 8.4 (Access to source code) and 8.32 (Change management) work together.
Make sure:
- Changes to critical repositories follow your change process:
- Recorded as change requests / tickets.
- Risk-assessed where appropriate.
- Approved by the right roles.
- Tested in non-production environments (linking back to 8.29 & 8.31).
- Your change records link to commits/releases
- Ticket or change number referenced in commit messages or pull requests.
- Release tags in the repository reference specific changes.
- Emergency fixes still follow a controlled path
- Shortened approval route, but still logged and subject to post-implementation review.
This gives you an end-to-end story: “Here is the change request, here is the code change, here is when we deployed it, and here’s who authorised it.”
Step 5 – Logging, Monitoring and Audit of Source Code Access
Control 8.4 asks you to log and review access to source code.
At a practical level:
- Enable audit logging in your SCM platform
- Log: logins, permission changes, repo creation/deletion, branch protection changes, push/force-push events, merge events.
- Keep logs for a reasonable retention period aligned to your policy.
- Protect logs against tampering
- Centralise logs where possible (e.g. SIEM, log platform).
- Restrict who can delete or alter logs.
- Review logs periodically
- Spot-check for unusual patterns:
- Access from new locations
- Out-of-hours activity on sensitive repositories
- Large or unexpected bulk access (e.g. mass cloning or exporting)
- Spot-check for unusual patterns:
- Use alerts for critical events
- Changes to branch protection rules
- New admins being added
- Force-pushes to protected branches
You want to be able to say: “If someone tried to do something odd with our source code, we’d see it – and we can show you where.”
Step 6 – Managing Public and Open Source Code Securely
Control 8.4 also applies when you intend to release code publicly (e.g. open source, client SDKs).
To keep that safe:
- Separate public and private repositories
- Make sure sensitive or proprietary code never accidentally lands in a public repo.
- Consider pre-commit scanning for secrets (keys, passwords, tokens).
- Use digital signatures or integrity checks
- Sign releases (e.g. signed tags, signed packages) so users can verify authenticity.
- Document how customers or community users can verify releases.
- Review code before making it public
- Check for hard-coded secrets, internal URLs, debug endpoints, client data examples.
- Ensure licensing and copyright information are correct.
- Apply the same change discipline
- Even public projects should follow structured review, approval and tagging processes.
The goal is that public release is deliberate and controlled, not an accidental push of something internal.
Step 7 – Keep Permissions and Practices Under Regular Review
Finally, ISO 27001 Control 8.4 is not “set and forget”.
You should:
- Review access permissions regularly
- Scheduled reviews (e.g. quarterly) for key repositories and tooling.
- Remove stale accounts and unnecessary privileges.
- Tie into HR and joiners/movers/leavers
- Developers changing role or leaving should have repository and tool access adjusted quickly.
- Service accounts reviewed to ensure they’re still needed and properly protected.
- Train developers and engineers
- Why source code access matters from a security and IP point of view.
- Their responsibilities (e.g. no sharing of access tokens, using SSH keys or SSO correctly).
- How to report suspicious activity.
- Document your standards
- A short “Source Code Security Standard” or equivalent that sets out:
- Where code lives
- How access is granted and reviewed
- Branch protection and review requirements
- Logging and monitoring expectations
- A short “Source Code Security Standard” or equivalent that sets out:
This shows that source code security is part of your normal way of working, not an afterthought.
Quick Implementation Checklist for ISO 27001 Control 8.4
Use this as a fast sense-check:
- All source code is stored in a central source code management system (no unmanaged “side copies”).
- There is a documented standard for source code access and repository management.
- Access to source code is role-based, with clear distinction between read, write and admin rights.
- Access to build, deployment and development tools is restricted and logged.
- Changes to code follow your formal change management process (linked to Control 8.32).
- Audit logging is enabled for repositories and CI/CD tools, and logs are protected and reviewed.
- Public and open-source repositories are deliberately separated from internal ones and checked before publication.
- Permissions for developers, admins and service accounts are reviewed regularly and on joiners/movers/leavers.
- Developers receive awareness training on protecting source code and using tools securely.
- You can demonstrate, with real examples, who changed what, when, why and how it was authorised.
If you can show those things, you’ll be in a strong position for ISO 27001 Control 8.4 – and far better protected against both accidental damage and deliberate attacks on your codebase.
Explore the ISO 27001 Control Group Purposes