The team that could read it anyway.
A.8.4 is the ISO 27001:2022 control about who can read source code, the tools used to build it, and the private libraries it depends on, not just who can change it. Most access-control attention goes to write access and production data; read access to a repository gets treated as low-risk because reading code does not change anything. But the source itself is often the thing worth protecting: pricing logic, a fraud model, an unpatched vulnerability, a hardcoded assumption nobody meant to publish. The expectation is that read access to source, build tooling, and libraries is granted to the people and systems that need it, deliberately, the same way a write grant would be.
The shapes the same control failure takes.
A.8.4 rarely breaks with a change labelled 'grant access'. It breaks when a convenient regrant quietly widens who can read source. The recurring shapes:
A broad group replaces a scoped one
A repository's read grant moves from a narrow, purpose-built team to a wider one (contractors, all-engineering) to unblock a single person faster, and everyone else already in the wider group inherits the read access too.
Repository visibility widens
A repository's visibility setting changes from private to internal or public, so the default audience for the source becomes every member of the organization, or the public, instead of the team that owns it.
Source ships inside a published artifact
A build or release process bakes the full repository checkout, source maps, or debug symbols into an image or bundle that reaches a less trusted or more public destination than the source repository itself.
A pipeline log prints the source back
A CI step starts echoing full file contents or a complete diff into a job log that a wider audience than the repository's own collaborators can view.
A library credential grants the same reach as a repo grant
A token or credential that gates read access to a private package or internal library lands in a broadly shared config or client, extending the same width of access the library's own repository permissions were set up to limit.
An access grant that widened by swapping one team for a broader one.
A contractor needs to read the payments-core service's source to review how it calls their integration. The repository already has a narrow team scoped for exactly this kind of external read access, but adding the contractor to it means a separate request to whoever owns that team, and the contractor is also already a member of the company's general contractors team from onboarding. The fast path is granting that wider team the read permission directly instead.
resource "github_team_repository" "payments_core_read" {- team_id = data.github_team.payments_core_readers.id+ team_id = data.github_team.contractors.id repository = "payments-core" permission = "pull"The read grant on payments-core's source moved from a team purpose-built for exactly this kind of external read access to the general contractors team used for onboarding and other grants. The diff does not show who belongs to either team, so it cannot show whether this widened the actual read population; what it shows is a single-purpose grant replaced by a general-purpose one, which is the shape worth checking before merge. A.8.4 expects read access to source code to be managed at the population that needs it, so confirm the contractors team's current membership and what else it already has read access to, and prefer adding the one contractor to the scoped team instead.
Auditors ask who can read, not only who can write.
In an ISO 27001 audit, A.8.4 usually comes up as a question about the read side of access: which teams, systems, and third parties can read a given repository's source, build pipeline, or private libraries, and whether that population matches a documented need. A common way to evidence it is pulling the current collaborator and team-permission list for a sensitive repository and comparing it against who the business says should have it, which is exactly what a quietly widened team grant or a visibility change would fail. The grant usually looks like a small, reasonable favor at the time it ships, which is why the pull request is the cheap place to catch it.
A review, not your repository settings.
heygrc flags changes that widen who can read source code, build tooling, or a private library and cites A.8.4 so the grant gets scoped in the pull request. It does not manage your repository permissions or run an access review. It catches the moment a change widens the read audience, at the diff.