Hoe toon ik wijzigingsbeheer aan vanuit GitHub voor SOC 2 of ISO 27001?
het heygrc team
Groten deels ja, als de instellingen kloppen. Een pull-request-workflow registreert al wat er is gewijzigd (de diff), wie het heeft beoordeeld en goedgekeurd, wat er voor de merge is uitgevoerd (de checks) en wanneer het is samengevoegd (de merge commit). SOC 2 CC8.1 en ISO 27001 A.8.32 willen beide dat wijzigingen geautoriseerd, getest, goedgekeurd en traceerbaar zijn, en een goed beheerde repository levert het grootste deel hiervan aan zonder extra tooling. Wat het niet gratis biedt, is het afdwingingsverhaal (bewijs dat goedkeuringen niet overgeslagen kunnen worden) en de koppeling tussen elke wijziging en de controle die het raakt. Die voeg je zelf toe.
Laat branch protection het autorisatiedeel afhandelen
Wijzigingsbeheer draait om twee vragen: is elke wijziging geautoriseerd en kun je dat aantonen. De pull request toont het voorbeeld; branch protection toont de regel. Vereis pull requests met minstens één goedkeuring (twee waar scheiding van taken belangrijk is), vereis de checks waar je op vertrouwt en vereis beoordeling door code-eigenaren voor de paden die ertoe doen. Een auditor die CC8.1 of A.8.32 steekt, vraagt hoe je weet dat een niet-beoordeelde wijziging niet in main kan komen: de protection-instellingen tonen de regel zoals die vandaag staat, elke goedkeuring is een voorbeeld van de regel die standhoudt, en als de regel binnen de auditperiode is gewijzigd, toont de repository-auditlog (regelset- en protection-wijzigingen) wanneer dat is gebeurd.
Maak van elke pull request een wijzigingsrecord
De PR-body legt uit waarom, de diff toont wat, de check-runs tonen dat het is getest, de goedkeuring toont dat een tweede persoon het heeft geaccepteerd en de merge commit toont wanneer de wijziging is samengevoegd. Wanneer de wijziging daadwerkelijk is uitgerold, is een deploy-record (een release, een omgeving, een deploy-run), wat wijzigingsbeheer als een eigen stap behandelt, niet iets wat de merge aantoont. Houd pull requests klein genoeg dat een review een echte review is, koppel het ticket of de issue voor de zakelijke reden en push niet rechtstreeks naar de beveiligde branch, zelfs als dat kan, want dat is de route om de review heen die je van iedereen eist. Een opgeruimde geschiedenis is geen ijdelheid: het is de populatie waar een auditor uit steekt.
Weet wat GitHub niet aantoont
Drie hiaten. Force-push kan de geschiedenis herschrijven op refs die niet beveiligd zijn en admins kunnen sommige beveiligingen omzeilen, dus het afdwingingsverhaal heeft randgevallen; benoem deze eerlijk in plaats van te overdreven. Bewaring heeft ook randgevallen: verwijder de repository en de pull-request-records verdwijnen mee, en de eigen logs van GitHub (de org-auditlog, Actions-logs) verlopen na een beperkte, afhankelijk van het plan, periode, dus exporteer wat je auditvenster nodig heeft voordat ze verdwijnen. En niets in het pull-request-record zelf koppelt een wijziging aan het framework: CC8.1 labelt geen diff en A.8.32 commentarieert niet op een pull request. Die koppeling is wat een per-PR compliance review toevoegt (heygrc post bevindingen die de clausule noemen), waardoor de controle-naar-wijziging-trail ontstaat op dezelfde plek waar de wijziging al staat.
# Standaard reviewers voor de hele repo* @acme/devs+ /security/ @acme/securityMet branch protection die review door code-eigenaren vereist, worden wijzigingen onder security/ doorgestuurd naar het security-team voor goedkeuring. Beveilig het CODEOWNERS-bestand zelf op dezelfde manier, anders kan de regel worden verzwakt in een gewone pull request. Autorisatie voor de risicovolle paden, vastgelegd in een bestand dat een auditor kan lezen.
Gerelateerd