Busca comprobaciones de cumplimiento en pull requests y la mayoría de los resultados se refieren a las comprobaciones de estado obligatorias de GitHub: asegurarse de que la suite de pruebas y el linter están en verde antes de hacer un merge. Eso es real y útil, pero no es de lo que trata esta página. Una comprobación de cumplimiento es una pregunta diferente hecha al mismo pull request: ¿este cambio afecta a algún control por el que tu empresa está auditada, en SOC 2, ISO 27001, el GDPR u otro marco al que estés sujeto?
Esa pregunta rara vez tiene un responsable en la revisión de código. La corrección y la seguridad tienen comprobaciones bien definidas; si un cambio afecta a un control por el que estás auditado es una lectura separada, y es la que añade una comprobación de cumplimiento en el pull request. Vale la pena ser preciso sobre qué es y qué no es esa comprobación.
Qué es y qué no es
Una comprobación de cumplimiento lee el diff, no los resultados de las pruebas. Mapea el cambio real al control específico que afecta y reporta ese control por su nombre, con un nivel de detalle que puedas verificar. No es un aprobado o suspendido en tu suite de pruebas, ni un umbral de cobertura, ni un documento de política que un auditor revisa una vez al año. Es una lectura por cambio para determinar si el pull request que tienes delante ha modificado algo que estás obligado a mantener.
El resultado que la hace útil es la cita. "Esto parece no conforme" es ruido. "Esto elimina el registro de auditoría para una acción privilegiada, que ISO 27001:2022 A.8.15 espera que mantengas" es algo con lo que un ingeniero puede actuar o discutir. Una comprobación de cumplimiento que no puede nombrar el control no vale la pena añadir.
Tres cambios relevantes para el control que se ocultan en pull requests rutinarios
Un acceso ampliado. Un pull request amplía un rol de IAM o abre una nueva ruta a un recurso. El código es correcto y puede ser perfectamente seguro, pero amplía quién puede acceder a datos protegidos, que es exactamente de lo que trata SOC 2 CC6.1 (controles de acceso lógico). Puede leerse como un cambio de configuración rutinario mientras el control que afecta pasa desapercibido.
Un registro de auditoría debilitado. Una limpieza elimina o recorta una línea de registro que resultaba ser el registro de una acción privilegiada. Nada se rompe, y puede leerse como una limpieza inofensiva, pero la evidencia que un auditor revisa bajo ISO 27001:2022 A.8.15 (registros) ahora ha desaparecido. El cambio que lo causó es el lugar más económico para detectarlo.
Un nuevo almacenamiento de datos personales sin límite. Una migración añade una tabla que comienza a recopilar datos personales sin límite de retención. Es código limpio y funcional, y te coloca silenciosamente en el lado equivocado del GDPR Art. 5(1)(e) (limitación del almacenamiento), que exige que los datos personales no se conserven más tiempo del necesario. Ninguno de estos tres es un error o una vulnerabilidad. Cada uno es un cambio relevante para el control que se oculta en un pull request rutinario.
Asesoramiento por defecto, bloqueo solo si lo eliges
Una comprobación de cumplimiento que bloquea cada merge por cualquier hallazgo entrena a la gente a ignorarla; una que nunca bloquea nada se pasa por alto. El valor por defecto útil es el asesoramiento: la comprobación publica el control y la cláusula como un comentario y un estado neutral, para que el hallazgo sea visible sin interrumpir el merge. La decisión de bloquear pertenece a tu política de protección de ramas, no a la herramienta.
Si un control omitido es realmente costoso, cualquier cosa que afecte al control de acceso, la criptografía o los datos personales, puedes exigir la comprobación mediante la protección de ramas en los repositorios o ramas protegidas donde más importa, y dejarla como asesoramiento en el resto. El mecanismo debe permitirte elegir la postura en lugar de imponerla en todo.
Cómo añadir una
Una comprobación de cumplimiento se ejecuta en el pull request de la misma manera que tus otras comprobaciones: se activa cuando se abre o actualiza un PR, lee el diff frente a los marcos de trabajo que has seleccionado y el contexto de tu empresa, y publica los controles que afecta un cambio con la cláusula adjunta. La parte difícil no es detectar que algo ha cambiado, sino nombrar exactamente qué control ha cambiado, correctamente, por eso los marcos a los que estás sujeto y tu propio contexto deben alimentar la comprobación.
heygrc está diseñado para ser esa comprobación como una GitHub App: instálalo, indícale tus marcos y contexto una vez, y revisará cada pull request en busca de impacto de cumplimiento, publicando un estado de Checks neutral más comentarios en línea para informar en lugar de bloquear, a menos que decidas exigirlo. El tutorial de configuración cubre la incorporación en tres minutos.