Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.4 — Access to Source Code

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.4 ISO 27001ISO 27002BSI CON.8

A departing developer still has write access to the production branch two weeks after their last day. An intern clones the entire monorepo — including infrastructure-as-code with database credentials. A contractor pushes directly to main without code review. A.8.4 prevents these scenarios by requiring strict management of who can read and who can write source code.

Source code is intellectual property and, simultaneously, a map of your system’s inner workings. Unauthorized access can lead to intellectual property theft, insertion of backdoors or exposure of secrets embedded in the codebase.

What does the standard require?

  • Distinguish read and write access. Write access is restricted to authorized developers; broader read access may be permitted where appropriate.
  • Store code centrally. Source code is maintained in a central version control system with full audit trail.
  • Follow change control processes. Code changes follow a defined process — typically pull requests with mandatory review.
  • Log all access and changes. Every read, clone and write operation is logged.
  • Protect released code. When code is published or distributed, additional measures (digital signatures, checksums) ensure its integrity.

In practice

Enforce branch protection rules. Configure your Git hosting platform (GitHub, GitLab, Bitbucket) to require pull requests, mandatory reviewers and status checks before merging to protected branches. Direct pushes to main or production branches should be blocked.

Apply the principle of least privilege. Grant repository access per team, not organization-wide. Separate repositories by sensitivity — infrastructure code with secrets references in a restricted repo, application code in a broader one.

Automate access reviews. Use your Git platform’s API to export access lists regularly. Compare against the list of current team members and revoke access for anyone who has left or changed roles.

Sign commits and releases. GPG-signed commits prove authorship. Signed releases and checksums allow consumers of your software to verify integrity.

Typical audit evidence

Auditors typically expect the following evidence for A.8.4:

  • Repository access lists — who has read and write access to each repository (see Access Control Policy in the Starter Kit)
  • Branch protection configuration — evidence of mandatory reviews and merge restrictions
  • Access review records — documented periodic reviews of repository access
  • Audit logs — Git platform logs showing access and change history
  • Secrets scanning results — evidence that repositories are scanned for embedded credentials

KPI

Percentage of source code repositories with enforced access controls

Measured as a percentage: how many of your repositories have branch protection, access restrictions and audit logging enabled? Target: 100%.

Supplementary KPIs:

  • Number of repositories with organization-wide read access (target: zero for sensitive code)
  • Mean time between role change and access adjustment
  • Number of secrets detected in repository scans per quarter (target: decreasing)

BSI IT-Grundschutz

A.8.4 maps to BSI modules for access management and software development:

  • ORP.4 (Identity and Access Management) — access control requirements applicable to source code repositories.
  • CON.8 (Software Development) — requirements for secure handling of source code, version control and change management in the development process.

Sources

Frequently asked questions

Does A.8.4 apply if we do not develop software ourselves?

If you purchase or commission software, A.8.4 still applies to any source code, scripts or configuration-as-code you maintain internally. It also applies to code you receive from suppliers under escrow agreements.

Is read access to source code a security risk?

Yes. Source code often contains hardcoded credentials, API keys, internal architecture details and business logic that could be exploited. Even read-only access should be limited to people with a documented need.

What about open-source projects?

For open-source code you publish, the access control focus shifts to write access — who can merge changes. For open-source code you consume, A.8.4 focuses on integrity verification (checksums, signed releases).