ISO 27001 A.8.4: Control access to source code and development tools

What A.8.4 requires in practice

A.8.4 asks for appropriate management of who may view and change source code, development tools and software libraries. Three assets are named, and both kinds of access matter: reading exposes the code and what it reveals, while writing can change what the organisation ships or runs.

In practice an organisation needs to know who and what, including build accounts and automated pipelines, can read, change or administer each repository, tool and library collection. Access should reflect each role's need, and changes to that access should be controlled and traceable. Third parties such as suppliers and contractors are covered when they touch the same material.

Outputs include a defined access arrangement, evidence that it is applied and records showing how it is maintained. The control says appropriately, so the strength of management follows the risk: a tool that builds production software deserves more care than a prototype. Branch protection or peer review are methods Sterling's teams often use, not stated requirements.

Separate reading, changing and controlling the repository

Different activities require different permissions. A reviewer may need to read code, a developer may propose changes and a smaller group may control approval settings or release-related access. A person who can change repository protections can potentially affect the value of the review process itself.

Map the relevant code and associated material. Designs, build tools, libraries and integration settings can influence the resulting software. Protecting one central repository while leaving another route to change the build process uncontrolled creates an incomplete picture. Consider automation identities and integration credentials as well as named developers.

Make authorised change the normal working route

Use an arrangement that records contributions and applies the relevant review and approval rules. The specific workflow should suit the organisation and its risks. A source-control tool can support this, but installing the tool does not determine who can bypass review, rewrite important history or alter permission settings.

Keep access aligned with business need and changes in responsibility. Temporary project staff and suppliers should not retain broad permissions merely because their accounts remain active. Review external contributions and shared libraries according to their role in the software. Public availability of a component does not mean unrestricted modification of the version used by the organisation is appropriate.

Why source code access matters to the business

For a software business, the code is the product and often the main intellectual asset. Unrestricted read access invites theft or accidental exposure, while unrestricted write access lets an error, or a deliberate act, reach customers. A compromised developer account or build tool can insert harmful changes into software that clients then trust. Customers increasingly ask suppliers how code and build systems are protected, and procurement questionnaires reflect that. Good control also helps ordinary engineering: changes can be traced, mistakes undone and responsibilities shown. When incidents occur, a clear access record narrows the investigation and supports open communication with affected clients, which protects both revenue and reputation.

How to implement A.8.4

Treat repositories, build tools and software libraries as one controlled estate, because a weakness in any one of them can affect what you release.

1. List the repositories, development tools and package sources in use, including those run by suppliers.
2. Decide which roles need to read, which need to write and which administer, for each item.
3. Give automated accounts a defined purpose and the smallest write rights that let them do the job.
4. Route changes to protected code through an approval path, and keep the history of who changed what and when.
5. Agree who may approve access to each repository, and remove it promptly when people or suppliers finish work or change role, and include development tools in the leaver routine.
6. Sample actual permissions and change paths on a regular cycle, and follow up any difference from the approved arrangement.
7. Keep a record of the exceptions you approve, such as a supplier needing temporary write access, with the reason and the date access ends.

Illustrative software example: a supplier remains a repository administrator

Illustrative manufacturing example: a build account with write access

A hypothetical manufacturer maintains an internal application for production scheduling. An automated build process needs to retrieve approved code, but its credential also permits changes across several repositories. Nobody notices because the account is not assigned to a human developer.

The team identifies the account's purpose, grants only the required capability and assigns an accountable owner. A controlled test confirms that the build can retrieve its inputs while an unneeded write action is denied. The organisation also establishes how the credential is protected and replaced. The example illustrates access to code through automation, not merely through a developer's login.

Preserve traceability without exposing the code unnecessarily

Records of relevant access and change can support investigation and assurance. Determine what is needed to establish who performed an action, what changed and which approval applied. Protect the records and the code itself; an audit evidence package should not become an uncontrolled copy of valuable intellectual property.

Where source code is intentionally published, confidentiality expectations may differ, but integrity still matters. The organisation needs an appropriate way to distinguish authorised releases or contributions from altered material. Choose measures according to the publication and distribution model rather than assuming public code needs no control.

Evidence and tests for the real change paths

Common nonconformities with A.8.4

Source-code findings often involve access that grew during a busy project and was never trimmed.

• Former contractors still listed as repository administrators.
• Every developer able to push directly to the main production branch, with no review step.
• Build or deployment accounts holding write rights far beyond their task.
• Third-party libraries or private package sources writable by anyone with a general login.
• No review of repository permissions since the project team changed, and no record of who approved access given to an outside supplier.