Les ingénieurs abordant un premier SOC 2 l'imaginent souvent comme un audit de code géant. Ce n'en est généralement pas un. SOC 2 est une attestation basée sur les Trust Services Criteria, et la majorité de ces critères portent sur les politiques, les processus et les preuves que les contrôles ont été appliqués sur une période donnée. Seule une partie est déterminée par ce que votre code fait, et savoir laquelle rend l'ensemble moins mystérieux.
Les critères qui concernent le code
Les critères liés au code se regroupent dans la famille CC6 des critères communs pour l'accès logique : CC6.1 (restriction de l'accès à ce dont un rôle a besoin), CC6.6 (protection contre les menaces extérieures au périmètre du système), CC6.7 (protection des données en transit et de leur mouvement), ainsi que CC7.2 pour la surveillance et CC8.1 pour la gestion des changements. Si vous pouvez raisonner sur qui peut accéder à quoi, comment les données sont protégées en transit et ce qui est journalisé, vous couvrez la majeure partie de la surface liée au code dans SOC 2.
Il est important de noter que beaucoup de ce qui semble lié à SOC 2 en ingénierie (l'existence de revues de code, les approbations de changements, les revues d'accès) constitue des preuves qu'un processus a été appliqué, recueillies en dehors du code. Le code lui-même concerne principalement la famille CC6.
Les exceptions qui deviennent des constats
Un auditeur échantillonne ces contrôles sur une période et rédige un avis. Une seule pull request qui élargit un rôle IAM à un joker ou abaisse un seuil TLS peut créer une exception dans cette période : le contrôle n'a peut-être pas fonctionné comme décrit pour ce changement. Détectée dans la PR, c'est une correction en une ligne. Détectée lors de l'audit, c'est une remédiation avec une traçabilité écrite.
Cette asymétrie est l'argument principal pour vérifier la surface CC6 au niveau du diff plutôt que de découvrir des exceptions des mois plus tard.