ISO 27001 A.8.4 Access to Source Code: Who Can Change What Ships?
ISO 27001:2022 A.8.4 explained: how to scope source code access, set repository tiers, and collect evidence that proves write access is controlled.
/Autenix/10 min read
A developer leaves on a Friday. HR closes the ticket, single sign-on (SSO) access is disabled, and everyone moves on. Three months later, an access review finds that their personal access token, which was never tied to SSO, still works, and it has write access to the repository that builds your production API. Whoever can push to your default branch can change production, so treat that list like a production access list.
What A.8.4 asks for
A.8.4 asks you to manage read and write access to source code, development tools, and software libraries appropriately. The goals are to:
- stop unauthorized functionality being introduced,
- prevent accidental or malicious changes,
- protect the confidentiality of code that has business value.
It is an Annex A control. You select it through risk treatment and record and justify that decision in your Statement of Applicability (SoA). Organizations that develop or customize software almost always find it applicable. ISO/IEC 27002 adds guidance, such as granting access by business need, routing updates through change control, and keeping a log of access and changes. That guidance is recommended, not mandatory.
Boundary: A.8.4 covers who can read and write. Whether a specific change was approved and tested belongs to A.8.32 Change management, and the quality of the code itself to A.8.28 Secure coding.
Depends on: A.5.15 Access control. A.8.4 applies your access control rules to code assets, so without those rules there is nothing to apply.
Decide your A.8.4 scope
"Source code" is wider than application repositories. Infrastructure as code (IaC), pipeline definitions, internal packages, and the CI/CD system that turns code into releases all carry the same risk: a change there changes what runs.
| Profile | What is in scope | How the access matrix changes | When to review scope |
|---|---|---|---|
| Small SaaS team, one Git host, no contractors | Product repos, IaC repo, CI configuration | Two tiers are usually enough; the same few people own most repos | When you add a second product, a contractor, or a new deployment target |
| Multi-team product company with contractors | Product repos, IaC, shared libraries, internal package registry, CI/CD system, outside collaborators | Full tiering; per-team ownership; separate rows for contractor access with expiry dates | When teams reorganize, a new registry or pipeline tool is adopted, or a contract starts or ends |
| Organization shipping signed software or using outsourced development | Everything above, plus release signing setup, build infrastructure, and supplier-held repositories | Adds rows for signing keys and supplier access; supplier access tied to contract terms (see A.8.30) | At each release-process change and each supplier onboarding or exit |
What to exclude, minimize, or deprioritize
- Archived repositories. Make them read-only and review them at a lower cadence. The risk is mainly confidentiality, not unauthorized change.
- Public open-source repositories. Read access is public by design, so concentrate only on write and maintainer access.
- Upstream third-party libraries. You can't control their source. Control your internal mirror or registry and who can publish to it.
- Personal sandboxes and experiments. Minimize these if they never deploy anywhere and hold no secrets or real data.
Exclusion is inappropriate when a repository deploys to production, contains credentials, or feeds a build that does. "It's just a sandbox" stops being true the moment a pipeline references it.
What good looks like for A.8.4
A. Artifact: repository access matrix
Adapt this to your environment. All values are illustrative.
| Tier | Examples | Read access | Write to protected branch | Admin | Merge rule | Non-human access | Access review |
|---|---|---|---|---|---|---|---|
| 1 – Critical | Production services, IaC, CI/CD pipeline definitions, release signing config | Engineers with a documented need | Through reviewed pull request only; direct push limited to a break-glass role, each use recorded | Two named owners | At least one approval from a code owner other than the author; required checks pass | Scoped, expiring tokens; each with named owner and purpose | Quarterly (illustrative) |
| 2 – Standard | Internal tools, non-production services, shared libraries not in Tier 1 builds | Engineering organization | Team members through pull request | Team lead plus platform team | At least one approval | Scoped tokens with named owner | Twice a year (illustrative) |
| 3 – Low | Archived repos, write side of public OSS, sandboxes | Organization or public | Maintainers only | Platform team | Per project | None or read-only | Annually, or on archive (illustrative) |
The matrix records your design. It does not prove implementation. That proof comes from configuration exports and access review records (see C).
B. Weak vs. effective
| Weak | Effective |
|---|---|
| "Access to source code is restricted to authorized personnel." | "Tier 1 changes reach the default branch only through a pull request approved by a code owner other than the author. Direct push is disabled except for a break-glass role, and each use is logged and reviewed within five working days (illustrative)." |
The weak version can't be tested. The effective version names the route, the exception, and the record an auditor can check.
C. Measures and evidence
| Measure | Why it matters | What sufficient looks like | Evidence that proves it |
|---|---|---|---|
| Repository tiering and ownership | Focuses strict controls where change risk is highest | Each repository that deploys to production has a tier and a named owner; untiered repos are flagged for triage | Design: Repository access matrix. Operational: repository inventory export from the Git host |
| Protected branch rules (Tier 1) | Makes peer review the route to production code rather than a convention | Direct push disabled; review required; admin bypass held by few named people and logged | Design: Repository access matrix. Operational: Branch protection configuration export; Audit log extract showing bypass events |
| Access reviews, human and non-human | Catches stale and excessive access, including tokens and deploy keys | Tier 1 reviewed quarterly, Tier 2 twice a year (illustrative); tokens, deploy keys, and CI accounts included; removals actioned | Operational: Access review record with removals and dates |
| Leaver and mover removal | Former staff and role-changers are a common source of stale write access | Git host access removed within the timeframe your leaver process sets for critical systems | Design: leaver procedure. Operational: Offboarding ticket matched against Audit log extract |
| Development tools and libraries | A pipeline or registry change can alter releases without touching application code | Write access to CI/CD definitions and internal package registry managed at Tier 1 level | Design: Repository access matrix rows for CI/CD and registry. Operational: registry permission export |
| Access and change logging | Supports investigation and shows exceptions were reviewed | Git host audit log retained per your logging policy (A.8.15); clone or download events monitored for Tier 1 where your platform records them | Operational: Audit log extract; logging configuration |
The example values are starting points, not requirements specified by ISO.
D. How to validate it yourself
- Leaver reconciliation. Inspect: Export Git host members, outside collaborators, and active tokens, and compare them with the last 90 days of HR leavers (illustrative window). Success: No leaver retains an account or a working token. Record: The reconciliation output, saved to the Access review record. Limit: This shows current state only. Check the Audit log extract to see whether access was used after departure.
- Protection drift check. Inspect: Export branch protection settings for all Tier 1 repositories, not a sample. Success: Direct push is disabled, review is required, and bypass is held only by named owners. Record: Branch protection configuration export, dated.
- Bypass sampling. Inspect: Pull the Audit log extract for Tier 1 default branches over the last quarter and find changes merged without an approved review. Success: Each one maps to a recorded break-glass use. Record: A sample list annotated with the matching records.
- Non-human access inventory. Inspect: List deploy keys, tokens, and integrations with write access. Success: Each has an owner, a purpose, and an expiry or review date. Record: The list, attached to the Access review record. Limit: This proves accountability exists. It does not prove each token's scope is minimal.
An independent reviewer adds value when you have many repositories, outsourced development, or need assurance that sampling missed nothing. It isn't required unless a contract or regulator says so.
Common A.8.4 implementation mistakes
- The access review covers people but not machines. Symptom: The quarterly review lists 60 engineers but none of the 40 deploy keys and CI tokens with write access. Why it matters: Machine credentials rarely leave with anyone and rarely expire. Fix: Add a non-human section to the review, with owner, purpose, and expiry for each credential.
- Branch protection is on, but admins are exempt and there are many of them. Symptom: The audit log shows routine direct pushes to Tier 1 branches by "admins." Why it matters: The protection exists on paper only. Fix: Reduce admins to named owners, require them to follow the same review route, and keep bypass for recorded break-glass use.
- The application is locked down, but the pipeline isn't. Symptom: Anyone with write access can edit the pipeline definition in the same repository, changing what gets built and deployed. Why it matters: The pipeline definition can change what ships even though the application code is reviewed. Fix: Require owner review for pipeline and infrastructure paths, using path-based ownership rules where your platform supports them.
- Contractor access outlives the contract. Symptom: Outside collaborators still appear on Tier 1 repositories months after the engagement ended. Why it matters: The access is no longer justified by any need, and nobody is reviewing it. Fix: Set an expiry date on contractor access that matches the contract end date, and check it in the leaver reconciliation.
If you have one afternoon
- Run the leaver reconciliation (check D1). Do: Export members, collaborators, and tokens, compare them with recent leavers, and revoke what you find. Output: The first entry in your Access review record.
- Tier your production-deploying repositories. Do: Start the repository access matrix with the repositories, IaC, and pipeline definitions that reach production, each with a named owner. Output: A first version of the matrix covering the repos that matter most.
- Export and fix Tier 1 branch protection (check D2). Do: Find any Tier 1 repository where direct push or admin bypass is unrestricted, and correct it. Output: A dated Branch protection configuration export showing the fixed state.
This won't complete A.8.4, but it closes the gaps most likely to matter and produces evidence you can build on.
How Autenix helps with A.8.4 Access to source code
Platform
Autenix Compliance is a continuous compliance platform for 35+ frameworks, including ISO 27001. Four of its listed features connect to the work above:
- Policy Generator has customizable policy templates with version control and change tracking. That fits keeping the repository access matrix as a versioned document.
- Risk Management has automated risk scoring and prioritization and control effectiveness monitoring. That supports the risk assessment that decides which repositories are Tier 1.
- Audit Readiness offers automated evidence collection, an audit trail with version history, and evidence export in an auditor-ready format. That supports the evidence named above. Which items can be collected automatically depends on the integrations you connect, so check that your Git host is covered.
- Continuous monitoring sends real-time alerts when a control drifts. That helps you notice gaps like tokens left out of reviews, unrestricted admin bypass, pipeline definitions anyone can edit, and contractor access past the contract end, between reviews.
The platform supports your documentation and evidence. It does not satisfy the control on its own.
Services
Autenix's Compliance as a Service delivers the platform as a managed service. Its Discover step maps your current systems, frameworks and gaps, which is the same ground as the leaver reconciliation and the branch protection check above. Setup, integrations and training are included. You still own the tier decisions, the branch rules, the review decisions and the repository settings themselves. The service is optional help with setting up and running the platform, and the two are designed to be used together.
Request an ISO 27001 demo to see how versioned policies, risk scoring and audit-ready evidence export fit around your afternoon checklist and validation steps.
Request an ISO 27001 demo