Compliance as code to koncepcja, zgodnie z którą zobowiązanie dotyczące zgodności powinno być wyrażone i sprawdzane tam, gdzie faktycznie istnieje system, czyli w repozytorium i potoku CI/CD, a nie jedynie w dokumencie polityki, który auditor sprawdza raz w roku. Wykorzystuje ona podejście, które sprawdziło się w przypadku testów i infrastruktury: bierze coś, co dawniej było manualne i okresowe, i czyni to zdefiniowanym i ciągłym.
Trzy rzeczy, które są do tego niezbędne
Po pierwsze, zobowiązanie musi być sformułowane w sposób, który można zweryfikować. "Poprawa naszego stanu bezpieczeństwa" nie jest weryfikowalna; "zmiana roli uprzywilejowanej musi zostać zarejestrowana, zgodnie z ISO 27001:2022 A.8.15" już tak. Po drugie, sprawdzenie musi odbywać się tam, gdzie zachodzą zmiany, czyli w pull request, a nie w oddzielnym narzędziu, którego nikt nie używa. Po trzecie, gdy coś zostanie zasygnalizowane, musi jasno wskazywać, która kontrola i dlaczego, aby inżynier mógł działać bez konieczności stawania się ekspertem ds. zgodności.
Większość zespołów ma już pierwszy składnik ukryty w swoich frameworkach, a drugi w CI. Zwykle brakuje warstwy tłumaczącej, która łączy konkretną zmianę kodu z konkretną kontrolą, której dotyczy.
Dlaczego diff jest odpowiednią jednostką
Kontrola nie ulega pogorszeniu według harmonogramu. Pogarsza się w momencie, gdy ktoś poszerza rolę, obniża ustawienia szyfrowania lub usuwa wpis w logach. Każda z tych czynności to diff. Jeśli sprawdzisz zgodność na poziomie diff, wykryjesz pogorszenie w momencie jego wprowadzenia, gdy autor wciąż ma kontekst, aby tanio je naprawić.
To ten sam powód, dla którego testy uruchamia się przy każdej zmianie, a nie raz na kwartał: koszt regresji rośnie wraz z czasem między jej wprowadzeniem a wykryciem.
Rola heygrc
heygrc został zaprojektowany jako ta warstwa tłumacząca: analizuje każdy pull request w odniesieniu do frameworków wybranych przez Twoją firmę i identyfikuje konkretną kontrolę, której dotyczy zmiana, dodając komentarz z dołączonym klauzulą. Nie ma na celu zastąpienia Twojego frameworka, audytora ani osądu inżynierskiego; celem jest uczynienie kontroli widoczną na poziomie diff, aby decyzja była podejmowana świadomie.