Los clientes de GitLab han descubierto que el uso de GitLab como su plataforma para DevSecOps ha simplificado el proceso de la auditoría SOC 2. En este artículo, analizaremos el marco SOC 2 y las funcionalidades de GitLab que ayudan a los clientes con su auditoría SOC 2.
Introducción a SOC 2
System and Organization Controls 2 (Controles del Sistema y la Organización 2) o SOC 2 es un estándar de cumplimiento voluntario que define cómo las organizaciones deben administrar los datos de los clientes. El informe de la auditoría SOC 2 permite a las empresas dar fe de la confiabilidad del software que ofrece a los clientes comerciales.
Desarrollado por la Association of International Certified Professional Accountants (AICPA), el SOC 2 se centra en cinco criterios de servicios de confianza (TSC):
- Seguridad: proteger los datos de los clientes de vulnerabilidades y accesos no autorizados
- Disponibilidad: garantizar que los sistemas sean tolerantes a fallas y que funcionen bajo cargas altas para cumplir con los acuerdos de nivel de servicio de disponibilidad
- Integridad de procesamiento: garantizar que los sistemas funcionen según lo previsto sin vulnerabilidades, errores o fallas
- Confidencialidad: proteger la información confidencial, como el código fuente de la aplicación, los nombres de usuario y las contraseñas, la información de la tarjeta de crédito, etc., de modo que solo las personas que necesiten acceso para hacer su trabajo tengan acceso a ella
- Privacidad: proteger la información de identificación personal (PII) confidencial frente a usuarios no autorizados
La seguridad es el único criterio que se exige en todas las auditorías SOC 2. Los demás criterios se pueden agregar a la auditoría en los casos en que se consideren esenciales para los servicios que se prestan.
Criterio de servicio de confianza de seguridad
El criterio de seguridad hace referencia no solo a la seguridad de los servidores y sistemas físicos, sino también a la de las aplicaciones. Las vulnerabilidades de software pueden exponer una aplicación a atacantes y poner en riesgo los datos de los clientes, pero esta es un área en la que GitLab puede ayudar.
GitLab proporciona diferentes tipos de análisis de seguridad para identificar posibles vulnerabilidades en las aplicaciones que crea una empresa, como los siguientes:
- Pruebas estáticas de seguridad de las aplicaciones (SAST): analiza el código fuente en busca de posibles errores y vulnerabilidades, como código inseguro que pueda provocar la ejecución involuntaria de código
- Análisis de dependencias: identifica vulnerabilidades de seguridad en las dependencias de software de una aplicación
- Análisis de contenedores: identifica vulnerabilidades de seguridad en las dependencias del sistema operativo de una aplicación en contenedores
- Pruebas dinámicas de seguridad de las aplicaciones (DAST): identifica vulnerabilidades de seguridad en una aplicación web en ejecución que podrían hacerla susceptible a un ataque
- Análisis de infraestructura como código (IaC): analiza archivos de configuración de infraestructura como código, incluyendo Terraform, Ansible, AWS CloudFormation y Kubernetes, para detectar vulnerabilidades de seguridad
GitLab también proporciona un informe de vulnerabilidades que muestra todas las vulnerabilidades conocidas, según los análisis anteriores, en la aplicación actual. Además, GitLab ofrece una lista de materiales de software (SBOM) en formato estándar CycloneDX JSON, que muestra todas las dependencias a nivel de software y de sistema operativo, así como las vulnerabilidades conocidas de cada una de ellas.
Realizar análisis de vulnerabilidades periódicos y contar con informes sólidos de vulnerabilidades ayuda a cumplir con tres criterios de seguridad:
- CC7.1 – Para cumplir con sus objetivos, la entidad utiliza procedimientos de detección y supervisión a fin de identificar (1) cambios en las configuraciones que pueden resultar en la introducción de nuevas vulnerabilidades y (2) susceptibilidades a vulnerabilidades recién descubiertas.
- CC4.1 – Principio 16 de COSO: la entidad selecciona, desarrolla y realiza evaluaciones continuas y/o separadas para determinar si los componentes del control interno están presentes y en funcionamiento.
- CC4.2 – Principio 17 de COSO: la entidad evalúa y comunica de manera oportuna las deficiencias de control interno a las partes responsables de tomar medidas correctivas, incluida la alta gerencia y la junta directiva, según corresponda.
Un componente fundamental de los análisis de seguridad es la gobernanza y el cumplimiento. GitLab proporciona funcionalidades para garantizar que los análisis se realicen de manera periódica y que los equipos de desarrollo de software no puedan eludirlos. Estas funcionalidades incluyen lo siguiente:
- Controles de acceso basados en roles para limitar quién puede realizar cambios en los ajustes de configuración a nivel de proyecto
- Políticas de ejecución de análisis para exigir que los análisis se ejecuten en todos los repositorios de código
- Políticas de aprobación de solicitudes de fusión para garantizar que los resultados de los análisis las revisen y aprueben las partes interesadas en seguridad correspondientes a fin de que las vulnerabilidades recién encontradas no se introduzcan en el software implementado
- Informes de cumplimiento para mostrar cualquier cambio en las configuraciones de GitLab que pueda violar los procesos de seguridad implementados
Con estas configuraciones, las organizaciones pueden demostrar que la seguridad del software es una prioridad absoluta para sus aplicaciones y que se aplican prácticas de seguridad.
Criterios de servicios de confianza de disponibilidad e integridad del procesamiento
GitLab también puede ayudar a aplicar los criterios de servicios de confianza de disponibilidad e integridad del procesamiento. Estos criterios se centran en la calidad y el rendimiento de la aplicación en sí. Para respaldar estos criterios, GitLab proporciona lo siguiente:
- Los resultados de las pruebas unitarias y los cambios en la cobertura del código en forma de informes de cobertura de código, que garantizan que el código fuente sea validado por un conjunto de pruebas
- Calidad del código, que analiza la calidad y la complejidad del código fuente para facilitar la legibilidad y el mantenimiento
Si bien las prácticas de desarrollo de software anteriores se utilizan al principio del ciclo de desarrollo de software para garantizar un código probado de alta calidad, GitLab también ofrece plantillas para varios tipos de pruebas automatizadas en una aplicación en ejecución, con el fin de garantizar que funcione como se espera. Estas pruebas incluyen lo siguiente:
- Pruebas de rendimiento del navegador: miden el tiempo de carga de los sitios web durante el ciclo de vida del desarrollo para probar el impacto de cualquier cambio de código en el rendimiento del navegador
- Pruebas de rendimiento de carga: miden el rendimiento del sistema del back-end de una aplicación durante el ciclo de vida del desarrollo para probar el impacto de cualquier cambio de código en el rendimiento
- Fuzzing guiado por cobertura: envía datos inesperados, inválidos o aleatorios a una aplicación y luego la supervisa en busca de comportamientos inestables y fallas
- Fuzzing de la API web: envía datos inesperados, inválidos o aleatorios a los puntos de conexión de la API para detectar errores y problemas de seguridad
Al centrarse en prácticas sólidas de DevSecOps con GitLab para crear aplicaciones seguras y de alta calidad, las organizaciones pueden aprobar con mayor facilidad la auditoría SOC 2 y así dar fe de la seguridad de los datos de los clientes.
Más información: fortalezca su postura de ciberseguridad con los principios de Secure by Design.