Zum Hauptinhalt springen
CENEDRIL WIKI
EN
Annex A · Technologische Kontrolle

A.8.4 — Zugriff auf den Quellcode

Aktualisiert am 3 Min. Geprüft von: Cenedril-Redaktion
A.8.4 ISO 27001ISO 27002BSI CON.8

Quellcode ist geistiges Eigentum, Betriebsgeheimnis und Sicherheitsrisiko zugleich. Wer den Code lesen kann, kennt die Schwachstellen. Wer ihn ändern kann, kontrolliert die Software. A.8.4 fordert eine klare Zugriffskontrolle für Quellcode, Entwicklungswerkzeuge und Softwarebibliotheken — differenziert nach Lese- und Schreibrechten.

Die Kontrolle schützt drei Güter gleichzeitig: die Vertraulichkeit des geistigen Eigentums, die Integrität des Codes (keine unbefugten Änderungen) und die Nachvollziehbarkeit aller Zugriffe.

Was verlangt die Norm?

  • Lese- und Schreibzugriff differenzieren. Nur privilegiertes Personal erhält Schreibzugriff; breiterer Lesezugriff kann erlaubt sein, wenn geschäftlich sinnvoll.
  • Zentrale Verwaltung. Quellcode wird in einem zentralen Versionskontrollsystem gespeichert, über das Zugriffe gesteuert und überwacht werden.
  • Änderungskontrolle. Updates am Code folgen einem definierten Verfahren (Branch-Strategie, Pull Requests, Code Reviews).
  • Protokollierung. Alle Zugriffe und Änderungen werden protokolliert und sind nachvollziehbar.
  • Integritätsschutz bei Veröffentlichung. Wenn Code veröffentlicht wird, sichern digitale Signaturen die Integrität.

In der Praxis

Repository-Zugriffskonzept definieren. Für jedes Repository festlegen, wer Lese- und wer Schreibzugriff hat. In GitHub, GitLab oder Bitbucket lassen sich Teams und Berechtigungsstufen direkt abbilden. Die Zuordnung sollte regelmäßig mit dem HR-System abgeglichen werden.

Branch Protection Rules aktivieren. Der Main-Branch ist geschützt: kein direkter Push, mindestens ein Review erforderlich, CI-Pipeline muss erfolgreich durchlaufen. Das verhindert sowohl versehentliche als auch böswillige Änderungen am produktiven Code.

Code-Review als Sicherheitsmaßnahme etablieren. Jede Änderung wird von mindestens einer zweiten Person geprüft, bevor sie in den Main-Branch fließt. Code Reviews sind gleichzeitig Qualitätssicherung und Sicherheitskontrolle — und liefern einen dokumentierten Audit-Trail.

Geheimnisse aus dem Code fernhalten. API-Keys, Passwörter und Zertifikate gehören in einen Secrets Manager, nie in den Quellcode. Tools wie GitLeaks oder TruffleHog scannen Repositories automatisch auf eingebettete Geheimnisse.

Typische Audit-Nachweise

Auditoren erwarten bei A.8.4 typischerweise diese Nachweise:

  • Repository-Zugriffskonzept — dokumentierte Lese-/Schreibrechte pro Repository (→ Zugriffskontrollrichtlinie im Starter Kit)
  • Branch Protection Rules — Screenshot oder Export der Schutzregeln für den Main-Branch
  • Code-Review-Statistik — Nachweis, dass Änderungen durch Reviews gehen
  • Audit-Logs — Protokolle der Zugriffe und Änderungen im Versionskontrollsystem
  • Secret-Scanning-Ergebnisse — Nachweis, dass Repositories auf eingebettete Geheimnisse geprüft werden

KPI

Anteil der Quellcode-Repositories mit durchgesetzten Zugriffskontrollen

Gemessen als Prozentsatz: Wie viele deiner Repositories haben definierte Zugriffsrechte, aktivierte Branch Protection und erzwungene Code Reviews? Ziel: 100%.

Ergänzende KPIs:

  • Anteil der Commits, die über Pull Requests mit Review eingehen (Ziel: über 95%)
  • Anzahl der erkannten Geheimnisse in Repositories pro Quartal (Ziel: 0)
  • Mittlere Review-Zeit für Pull Requests (Indikator für Prozessqualität)

BSI IT-Grundschutz

A.8.4 mappt auf die BSI-Bausteine für Softwareentwicklung und Berechtigungsmanagement:

  • CON.8 (Software-Entwicklung) — verlangt Versionskontrolle, Zugriffsschutz für den Quellcode, sichere Entwicklungsumgebungen und Code-Review-Verfahren.
  • ORP.4 (Identitäts- und Berechtigungsmanagement) — übergreifende Anforderungen an die Zugriffskontrolle, die auch für Code-Repositories gelten.

Verwandte Kontrollen

Quellen

Häufig gestellte Fragen

Gilt A.8.4 auch für Unternehmen, die keine eigene Software entwickeln?

Ja, wenn die Organisation Quellcode besitzt oder verwaltet — etwa Skripte, Konfigurationsdateien als Code (Infrastructure as Code) oder angepasste Open-Source-Projekte. Auch Low-Code-Plattformen können darunter fallen, wenn exportierbarer Code erzeugt wird.

Müssen wir zwischen Lese- und Schreibzugriff auf Repositories unterscheiden?

Die Norm empfiehlt diese Unterscheidung ausdrücklich. Lesezugriff auf den gesamten Code kann breiter gewährt werden (Inner Source), während Schreibzugriff auf die jeweiligen Maintainer und Reviewer beschränkt sein sollte.

Wie schützen wir Quellcode bei ausgelagerter Entwicklung?

Durch vertragliche Regelungen (NDA, IP-Klauseln), Code-Escrow-Vereinbarungen und technische Maßnahmen wie eingeschränkten Repository-Zugang. Bei besonders sensiblem Code kann die Entwicklung in einer kontrollierten Umgebung stattfinden, aus der kein Code extrahiert werden kann.