Sucht man nach SOC 2 in Pull Requests, findet man meist Prozess-Checklisten: Genehmigungen erforderlich, Statusprüfungen und signierte Commits. Diese Einstellungen sind wichtig. Sie sind Belege dafür, dass ein Change-Management-Prozess existiert. CC8.1 (Common Criteria Change Management) betrifft auch, ob die Kontrolle für eine bestimmte Änderung angewendet wurde: Wurde die Änderung so genehmigt, wie es Ihre Richtlinie vorsieht, oder hat ein Hotfix, ein Bot oder ein Notfallpfad einen erforderlichen Schritt übersprungen?
Dieser Leitfaden betrachtet die Pull-Request-Ebene. Er erklärt nicht erneut Typ I versus Typ II (siehe /guides/how-to-pass-soc-2-as-a-startup) und ordnet nicht die gesamte CC6-Zugriffsfamilie zu (siehe /guides/what-soc-2-actually-checks-in-your-repo). Er konzentriert sich auf das Change Management im Moment, in dem ein Pull Request gemergt wird.
Branch Protection ist notwendig, aber nicht ausreichend
Die Anforderung einer genehmigenden Überprüfung und eines grünen CI-Checks ist die übliche Basis. Prüfer untersuchen, ob dieser Prozess während des Beobachtungszeitraums angewendet wurde. Ein Repository mit aktivierter Protection kann dennoch Ausnahmen erzeugen, wenn jemand mit Admin-Rechten überspringt, wenn ein Deployment-Pfad die geschützte Branch umgeht oder wenn ein Automatisierungskonto ohne die in Ihrer Richtlinie geforderte menschliche Genehmigung mergen kann.
Der codebezogene Hinweis ist nicht immer im Anwendungscode zu finden. Oft liegt er in Workflow-Dateien, CODEOWNERS, Deployment-Skripten oder einer einzeiligen Änderung, wer genehmigen darf. Diese Änderungen landen dennoch als Pull Requests.
Praktisches Beispiel: Notfallpfad, der die erforderliche Genehmigung überspringt
Der Bereitschaftsdienst wird alarmiert. Ein Entwickler erstellt einen Pull Request, der einen workflow_dispatch-Job mit continue-on-error und einem Pfad hinzufügt, der die Produktion aus einer persönlichen Fork mit einem langlebigen Token bereitstellt, dokumentiert als "break-glass". Ein zweiter Pull Request am selben Tag ändert CODEOWNERS, sodass dieser Pfad nicht mehr die Genehmigung des Plattform-Teams erfordert. Beide Pull Requests wirken wie operative Wartung. Der Anwendungscode kann sich dabei überhaupt nicht ändern.
Was CC8.1 interessiert, ist, ob Änderungen an der Produktion weiterhin den autorisierten Change-Prozess durchlaufen. Ein Break-Glass-Pfad, der dauerhaft die erforderlichen Genehmigungen schwächt, ist eine Kontrolländerung und keine bloße Bequemlichkeit. Während eines Typ-II-Zeitraums, wenn der Prüfer Deployments prüft, die diesen Pfad ohne die dokumentierte Genehmigung genutzt haben, müssen Sie eine Ausnahme erklären. Die Diffs der Workflows und CODEOWNERS während der Überprüfung zu erkennen, ist günstiger, als sie sechs Monate später erklären zu müssen.
Zusammenhang mit dem Beobachtungszeitraum (ohne erneute Erklärung des Audits)
Bei Typ II prüft der Prüfer, ob die Kontrollen über einen Zeitraum hinweg angewendet wurden. Eine einzelne übersprungene Genehmigung innerhalb dieses Zeitraums kann zu einer geprüften Ausnahme werden, selbst wenn der Rest des Jahres einwandfrei war. Deshalb ist die Change-Management-Hygiene während des Zeitraums keine Bürokratie um ihrer selbst willen, sondern der Weg, um die Meinung zu vermeiden, für die Sie Monate lang vorbereitet haben. Details zu Bereitschaft, Scope und Prüferauswahl bleiben im Leitfaden zum SOC-2-Prozess für Startups.
Eine Compliance-Prüfung in Pull Requests, die CC8.1 bei einer geschwächten Genehmigungsstufe nennt, genehmigt nicht den Notfall. Sie macht die Prozessänderung sichtbar, während der Pull Request noch offen ist.
Die Rolle von heygrc und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, Pull Requests gegen die von Ihnen ausgewählten Frameworks zu prüfen, einschließlich SOC 2, wenn aktiviert, und Kriterien wie CC8.1 zu benennen, wenn eine Änderung das Change Management zu schwächen scheint (Genehmigungsstufen, erforderliche Prüfungen, Berechtigung zur Bereitstellung). Es führt nicht Ihr Audit durch, sammelt keine IdP- oder HR-Nachweise oder stellt keine Meinung aus.
Behalten Sie Ihren Code-Qualitätsprüfer. CC8.1 betrifft die Prozessintegrität der Änderung, nicht ob der Hotfix elegant war.