ISO 27001 A.8.4 - Access to Source Code

Requirement

“Read and write access to source code, development tools and software libraries shall be appropriately managed.”

Plain-language meaning

Source code, build tools, compilers, package repositories, CI/CD pipelines, and software libraries can directly change how systems behave. If an attacker or unauthorized insider can read or modify them, they can understand the system, bypass controls, insert malicious code, or compromise the build process.

This control is not only about Git repository permissions. It also covers development tools, build environments, libraries, macros, report programs, and any mechanism used to modify or generate executable behavior.

Why this matters

Source code can reveal sensitive architecture, business logic, security controls, credentials accidentally committed by developers, API patterns, and implementation weaknesses. Write access is even more sensitive because unauthorized changes can introduce backdoors, integrity failures, or availability problems.

Development tools deserve equivalent protection. A compromised compiler, build server, package source, or dependency can alter software even when the source repository looks clean.

Implementation guidance

1. Centralize and protect repositories

Source code should normally be stored in controlled repositories, not scattered across desktops, shared drives, production servers, or unmanaged developer machines.

Practical controls include:

• named user access;
• least privilege by repository and branch;
• separation between read, write, approve, merge, build, and release permissions;
• MFA for repository and CI/CD access;
• logging of repository access and changes;
• branch protection and pull request approval;
• removal of access after role change or departure.

2. Keep source code away from production systems

Production systems should not normally store or expose source code, build scripts, compilers, or development tooling. Production access should not become a shortcut to modify or recompile application behavior.

3. Protect development tools and libraries

Development tools and libraries should come from trusted sources and be protected from unauthorized modification. This includes compilers, build agents, CI/CD runners, dependency registries, package managers, library mirrors, and code signing tools.

4. Control code changes

Changes should be traceable from request to approval, review, test, merge, build, and release. Digital signatures, checksums, signed commits, protected branches, or release attestations can help detect unauthorized modification where justified.

5. Include macros and report programs

Macros, report builders, database scripts, stored procedures, and low-code components can change business logic or data output. They should not be ignored just because they are not in a traditional software repository.

Audit guidance

Auditors should verify:

• source code repository list;
• repository access permissions;
• branch protection and approval rules;
• change records and merge history;
• CI/CD and build tool access;
• dependency/library source controls;
• code signing, checksum, or integrity verification where applicable;
• evidence that source code is not stored on production systems without justification;
• controls for macros, database report programs, stored procedures, and scripts;
• access review and removal records.

Evidence examples

Strong evidence

• Repositories are centrally managed.
• Production systems do not expose source code or development tools without justification.
• Write access is limited and reviewed.
• Changes require review, test, and approval.
• Build tools and dependency sources are protected.
• Macros, reports, and database scripts are included in scope where relevant.

Weak evidence

• Developers keep local unmanaged source copies as the main record.
• Production servers contain source code and compilers by default.
• Repository write access is broad or inherited from generic groups.
• Direct pushes to protected branches are allowed.
• CI/CD administrators are not reviewed.
• Dependencies are pulled from untrusted or uncontrolled sources.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.2 Privileged Access Rights
• A.8.3 Information Access Restriction
• A.5.15 Access Control
• A.5.18 Access Rights
• A.5.28 Collection of Evidence
• Risk Assessment
• Statement of Applicability
• Source Code Access Register
• Development Tool and Library Integrity Checklist
• Source Code Change Control Checklist
• A.8.4 Audit Evidence Pack
• A.8.4 Audit Checklist

KB-ready summary

• Centralize source code in controlled repositories.
• Restrict read/write/merge/build/release permissions.
• Keep source code and development tools off production unless justified.
• Protect compilers, CI/CD, dependencies, and code signing.
• Include macros, report programs, scripts, and stored procedures where they affect system behavior.

Templates and checklists

• Source Code Access Register
• Development Tool and Library Integrity Checklist
• Source Code Change Control Checklist
• A.8.4 Audit Checklist