Inżynierowie, którzy po raz pierwszy stykają się z SOC 2, często wyobrażają sobie to jako ogromny audyt kodu. W większości nie jest to prawda. SOC 2 to potwierdzenie zgodności z Trust Services Criteria, a większość tych kryteriów dotyczy polityk, procesów i dowodów, że kontrole działały w określonym okresie. Tylko część z nich zależy od tego, co robi Twój kod, a znajomość tej części sprawia, że cały proces staje się mniej tajemniczy.
Kryteria dotyczące kodu
Kryteria związane z kodem skupiają się w rodzinie CC6 (wspólne kryteria) dla logicznego dostępu: CC6.1 ograniczanie dostępu do tego, czego wymaga rola, CC6.6 ochrona przed zagrożeniami spoza granic systemu, CC6.7 ochrona danych w trakcie przesyłania i ich przemieszczania, a także CC7.2 dotyczące monitorowania oraz CC8.1 dotyczące zarządzania zmianami. Jeśli potrafisz rozumować, kto może uzyskać dostęp do czego, jak dane są chronione w trakcie przesyłania i co jest rejestrowane, rozumiesz większość powierzchni SOC 2 związanej z kodem.
Warto zauważyć, że wiele aspektów, które wydają się typowe dla SOC 2 w inżynierii (np. istnienie przeglądów kodu, zatwierdzanie zmian, przeglądy dostępu), to dowody, że proces działał, zebrane poza kodem. Sam kod dotyczy głównie rodziny CC6.
Wyjątki, które stają się ustaleniami
Audytor sprawdza próbki tych kontroli w określonym okresie i wydaje opinię. Pojedyncze pull request, które poszerza rolę IAM do symbolu wieloznacznego lub obniża minimalny poziom TLS, może spowodować wyjątek w tym okresie: kontrola mogła nie działać zgodnie z opisem dla tej zmiany. Jeśli zostanie to złapane na etapie PR, to wystarczy jednolinijkowa poprawka. Jeśli zostanie wykryte podczas audytu, to wymaga naprawy z dokumentacją.
Ta asymetria jest głównym argumentem za sprawdzaniem powierzchni CC6 na etapie diff, a nie odkrywaniem wyjątków miesiące później.