Revisión de código seguro

Definición de la revisión de código seguro

La revisión de código seguro es el examen del código fuente de una aplicación para identificar fallas o vulnerabilidades de seguridad. Estas aparecen en el ciclo de vida de desarrollo de software (SDLC) y deben cerrarse o corregirse para fortalecer la seguridad del código. La revisión de código seguro puede llevarse a cabo en cualquier punto del SDLC, pero dentro de la cultura DevSecOps, es más valioso usarla desde las primeras etapas. Este es un procedimiento que puede realizarse de forma manual o automática.

Revisión de código vs. Revisión de código seguro

Es crucial distinguir entre una revisión de código estándar y una revisión de código seguro.

La revisión de código seguro garantiza que la seguridad se trate como una característica central de la calidad del código, previniendo la introducción de debilidades que podrían comprometer los datos o la funcionalidad.

¿Cómo funciona la revisión de código seguro?

El enfoque más robusto para la revisión de código seguro es una combinación de revisiones manuales y automatizadas para aprovechar sus capacidades particulares. La revisión automatizada (como SAST) proporciona velocidad y amplitud, mientras que la revisión manual ofrece profundidad y precisión.

La revisión manual de código seguro se lleva a cabo con gran atención al detalle. Uno o más analistas de seguridad examinan el código, entendiendo lo que están evaluando, teniendo en cuenta su uso y contexto, las intenciones de los desarrolladores y la lógica de negocio.

Por otro lado, la revisión automatizada de código seguro es un proceso en el que se examina más código en menos tiempo, pero en el que no se consideran los factores anteriores. Las herramientas trabajan con un conjunto de reglas predefinido, están restringidas a ciertos tipos de vulnerabilidades y sufren, algunas más que otras, el defecto de reportar falsos positivos (i.e., decir que algo es una vulnerabilidad cuando no lo es).

Las herramientas automatizadas de revisión de código seguro, con su evaluación rápida e inicial, actúan como un asistente para el revisor humano, facilitando que los analistas de seguridad se concentren en identificar vulnerabilidades más complejas y críticas para el negocio.

Entre los métodos más utilizados en la revisión de código seguro automatizada se encuentran las pruebas de seguridad de aplicaciones estáticas (SAST) y el análisis de composición de software (SCA; entiende cómo uno difiere del otro en esta entrada del blog).

¿Cómo llevar a cabo una revisión de código seguro?

Una revisión de código seguro profesional sigue un proceso metódico para maximizar su impacto:

1. Planificación y definición del alcance

El proceso comienza definiendo el alcance. Dado que la revisión de código seguro consume tiempo, es esencial priorizar la revisión según el riesgo. Esto implica:

• Definir objetivos claros: ¿Qué tipos de vulnerabilidades estamos tratando de detectar (p. ej., cumplimiento con PCI DSS o fallas en una nueva característica de autenticación)?

• Recopilar contexto: Comprender la arquitectura de la aplicación, los requisitos de negocio y la funcionalidad; reunir modelos de amenazas y hallazgos de seguridad anteriores.

• Priorizar el código: Centrar la atención en activos críticos y funciones de alto riesgo como módulos de autenticación, procesamiento de pagos, controles de acceso y nuevas características.

2. Ejecución aumentada por herramientas

La revisión humana se apoya en tecnología para aumentar la eficiencia:

• Escaneo previo a la revisión: Ejecutar herramientas automatizadas (SAST/SCA) primero para detectar rápidamente problemas de seguridad conocidos en la línea base del código y en componentes de terceros.

• Clasificación: Usar los hallazgos automatizados para filtrar falsos positivos y guiar la investigación manual más profunda hacia rutas de código específicas y de alto riesgo.

• Técnicas de análisis manual: El revisor utiliza técnicas como el rastreo de rutas de código (siguiendo las rutas de ejecución) y el mapeo de límites de confianza (analizando puntos de control de seguridad) para aplicar su experiencia en la materia.

3. Profundización y validación de listas de chequeo

El núcleo de la revisión de código seguro implica una revisión detallada, línea por línea, con un enfoque en áreas que requieren comprensión contextual y de lógica empresarial. Durante esta fase, el revisor experto aprovecha listas de verificación de seguridad estandarizadas (a menudo basadas en OWASP, CWE o políticas internas) para garantizar un examen sistemático de categorías clave como validación de entradas, autenticación y control de acceso.

4. Informes, remediación y verificación

Los hallazgos se documentan con detalles precisos, incluyendo:

• Descripción de la vulnerabilidad: Una explicación clara de la falla y su mapeo de seguridad.

• Explotabilidad e impacto: Una evaluación del nivel de riesgo (utilizando un marco estandarizado) para ayudar en la priorización.

• Ubicación precisa: Nombre del archivo y número de línea, confirmado por validación humana.

• Prueba de concepto detallada: Proporcionando una demostración paso a paso de cómo se puede explotar la vulnerabilidad para facilitar la comprensión del desarrollador.

• Orientación para la remediación: Sugerencias de código seguro específicas para los desarrolladores.

Después de la remediación, se debe realizar una revisión de seguimiento (re-escaneo/re-prueba) para verificar que la solución eliminó con éxito la vulnerabilidad y no introdujo nuevos fallos.

La ventaja humana: lo que buscan los expertos

Los expertos en seguridad que aplican las mejores prácticas de revisión de código seguro, considerando también la perspectiva de los actores de amenazas, pueden evaluar el código para reconocer los problemas de seguridad que contribuyen más a la exposición al riesgo del objetivo de evaluación. Por ejemplo, en nuestro último informe anual sobre el Estado de los Ataques, compartimos que el 71% de la exposición total al riesgo en los sistemas evaluados fue reportada por el método manual.

La revisión de código seguro por expertos sobresale al encontrar problemas que están cegados por la lógica de negocio para las herramientas automatizadas. La revisión se centra en áreas críticas como las siguientes:

Flujos de lógica de negocio

El revisor analiza los procesos únicos de la aplicación buscando:

• Integridad del flujo de trabajo: Oportunidades para eludir transiciones de estado, pasos o validaciones en procesos de varios pasos.

• Condiciones de carrera: Vulnerabilidades basadas en tiempo en operaciones concurrentes donde múltiples usuarios interactúan con el mismo recurso.

• Límites de recursos: Asegurando que se implementen limitaciones de tasa y cuotas de recursos para prevenir denegaciones de servicio o agotamientos de recursos.

Autorización y control de acceso

El revisor verifica la corrección y completitud de la ejecución de seguridad:

• Ejecutar en el servidor: Verificando que todos los controles de acceso se apliquen en el servidor, no solo en el lado del cliente.

• Predeterminados a prueba de fallos: Asegurar que se utiliza una política de acceso de negación predeterminada.

• Prevención de IDOR: Verificando Referencias Directas Inseguras a Objetos donde un usuario puede manipular un parámetro (por ejemplo, un ID) para acceder a los datos de otro usuario o a recursos no autorizados.

Validación de entradas y codificación de salidas

Si bien SAST puede encontrar patrones básicos de inyección, el experto asegura la corrección contextual:

• Validación del lado del servidor: Se valida toda entrada de usuario y externa, independientemente de las verificaciones del lado del cliente.

• Validación de listas permitidas: Usar listas permitidas (aceptando solo entradas conocidas como buenas) en lugar de listas bloqueadas (rechazando entradas conocidas como malas) para mayor robustez.

• Codificación adecuada al contexto: Asegurando que los datos estén debidamente codificados (HTML, JavaScript, URL, SQL) antes de su salida para prevenir ataques de inyección como XSS o inyección SQL.

Cifrado y gestión de secretos

• Algoritmos fuertes y gestión de claves: Verificando el uso de algoritmos modernos y probados (por ejemplo, AES-256, RSA-2048+) y la generación, almacenamiento y rotación de claves seguras.

• Secretos codificados: Identificando dónde un desarrollador cometió el error de dejar información confidencial (por ejemplo, claves API, tokens, credenciales) dentro del código, incluyendo archivos de configuración.

Herramientas de revisión de código seguro

Para la implementación automatizada de la revisión de código seguro, existen herramientas correspondientes que identifican rápidamente vulnerabilidades de seguridad conocidas.

• Las herramientas SAST son programas que escanean automáticamente el código fuente o el código objeto de aplicaciones —mientras no se están ejecutando— para detectar vulnerabilidades que coincidan con las almacenadas en bases de datos.

• Las herramientas SCA son programas que escanean automáticamente aplicaciones para inventariar sus componentes de software de terceros y sus dependencias, e identificar vulnerabilidades en ellos que coincidan con las registradas en bases de datos.

Revisión de código seguro vs. pruebas de seguridad de aplicaciones

Las pruebas de seguridad de aplicaciones (AST) son un concepto más amplio que la revisión de código seguro. De hecho, esta última es parte de la primera. AST, además de SAST y SCA, implica métodos de evaluación como pruebas de seguridad de aplicaciones dinámicas (DAST), pruebas de penetración como servicio (PTaaS), y ingeniería inversa. Mientras que la revisión de código seguro se puede aplicar en cualquier etapa del desarrollo de software, DAST y PTaaS, por ejemplo, generalmente se emplean cuando la aplicación puede ejecutarse para evaluar su comportamiento a través de vectores de ataque.

La revisión de código seguro es un elemento fundamental que, cuando se combina con DAST (que verifica errores de ejecución y configuración) y PTaaS, garantiza un enfoque integral y de defensa en profundidad para la seguridad.

¿Cuándo deberías implementar la revisión de código seguro?

La revisión de código seguro es parte de un enfoque preventivo, que debe abordarse primero, en lugar de un enfoque reactivo. Aplicar este método tan pronto como se escriben las primeras líneas de código permite identificar y remediar vulnerabilidades antes de que entren en producción. Mantenerse un paso adelante de los hackers maliciosos y bloquear en el código cualquier posible entrada para usos indebidos, incluso simples travesuras, es sin duda una estrategia muy efectiva para reducir la probabilidad de catástrofes causadas por ciberataques.

Una estrategia holística implica dos estrategias de tiempo principales:

• Revisión continua: Implementar herramientas automatizadas en entornos de desarrollo integrados (IDEs) y durante pull requests es la manera más impactante de "desplazar la seguridad hacia la izquierda." Esto permite que los desarrolladores reciban retroalimentación casi en tiempo real y solucionen problemas cuando están más frescos en la mente.

• Revisión específica: Reservar una revisión exhaustiva de código manual para puntos estratégicos en el SDLC:

  • Inicio del proyecto: Evaluación de seguridad integral de una nueva base de código o una base de código legado.

  • Lanzamientos mayores: Antes de lanzamientos significativos de versiones para asegurar que los cambios a gran escala sean seguros.

  • Cambios de arquitectura: Cuando ocurren cambios fundamentales de diseño o tecnología.

  • Ciclos de cumplimiento: Revisiones extensas periódicas para requisitos regulatorios (PCI DSS, HIPAA, etc.).

¿Por qué es importante la revisión de código seguro?

Un equipo de desarrollo exitoso, comprometido con la seguridad de sus productos, siempre tiene la revisión de código seguro como pilar. Cualquier organización que desarrolle software debería tenerla entre sus prácticas constantes, desde las primeras etapas del SDLC, prestando atención a los pequeños cambios que los miembros de su equipo realizan gradualmente en el código.

La seguridad en general y las debilidades comunes en el software y su explotación no suelen enseñarse a los desarrolladores en sus academias y lugares de trabajo. E incluso los desarrolladores más experimentados, debido a factores como el agotamiento o la negligencia, pueden cometer errores de codificación y acabar generando vulnerabilidades como las enumeradas en la OWASP Top 10 y la CWE Top 25. Por razones como estas, el código fuente debería permanecer generalmente bajo revisión por expertos en seguridad.

Detección de vulnerabilidades en el código fuente y componentes

La revisión de código seguro identifica la ausencia de prácticas de codificación seguras, la falta de controles de seguridad apropiados y la violación de estándares de cumplimiento como PCI DSS y HIPAA. Los proveedores de revisión de código seguro pueden encontrar, por ejemplo, la ausencia o errores en la validación de entradas (verificación de que cumplan con características específicas) que provienen de diferentes fuentes que interactúan con la aplicación (por ejemplo, usuarios, archivos, flujos de datos). Pueden descubrir que un desarrollador cometió el error de dejar información confidencial (por ejemplo, tokens, credenciales) dentro del código, habiendo olvidado eliminarla después de haberla puesto allí sin una justificación razonable. Pueden ver que la información que necesita ser almacenada y transferida no pasa por algoritmos de cifrado adecuados. Del mismo modo, pueden encontrar que los procesos de autenticación de usuarios son bastante débiles, requiriendo, por ejemplo, contraseñas cortas con poca variedad en sus caracteres. Y que los controles de autorización son deficientes y terminan dando acceso innecesario a cualquier usuario sin solicitar permiso.

Un problema importante que a menudo se descubre con la revisión de código seguro, utilizando herramientas SCA, son las vulnerabilidades dentro de componentes de software de terceros y de código abierto. El desarrollo de aplicaciones hoy en día depende en gran medida de componentes de software de código abierto, que son importados de diversas fuentes y sirven como soporte para lo que se pretende construir, que a menudo resulta tener poca originalidad. También existe dependencia entre algunos componentes y otros. Así que al usar uno de ellos, por ejemplo, el desarrollador puede no estar al tanto de la relación{