Code Review (Revisión de Código): una visión integral y práctica

Parte 1 Fundamentos

El Code Review sirve como un punto de control esencial en el ciclo de vida del desarrollo de software, ayudando a detectar y corregir vulnerabilidades de seguridad antes de la liberación del software.

En esta serie de artículos se aborda la práctica del Code Review (Revisión de Código), en tres partes con la intención de abordar:

• Parte 1 Fundamentos: se explora la práctica del Code Review desde una perspectiva general tocando temas como: Definición, Importancia e Implementación.
• Parte 2 Caso práctico: se analiza un API desarrollada en Java utilizando herramientas open source así como haciendo uso de OWASP como marco de referencia.
• Parte 3 Mejores prácticas: se muestran las mejores prácticas así como recomendaciones generales.

Los elementos mostrados como parte de los ejemplos no representan un esquema nivel producción, estos han sido simplificados con la finalidad de facilitar el entendimiento de los conceptos presentados.

Las definiciones y conceptos manejados en el presente documento son expresados de forma informal para facilitar su entendimiento sin perder por ello rigor o veracidad.

Introducción

Vulnerabilidad Debilidad en un sistema, procedimiento o control interno que puede ser explotada por amenazas para comprometer la seguridad.

SCA (Software Composition Analysis) Análisis de composición de software. Identifica componentes de terceros (como librerías open source) en el código, detectando vulnerabilidades conocidas, licencias inseguras o dependencias obsoletas.

SAST (Static Application Security Testing) Análisis estático de seguridad de aplicaciones. Examina el código fuente o compilado sin ejecutarlo, para detectar vulnerabilidades como inyecciones, errores de validación o exposición de secretos.

El Code Review (Revisión de Código) es una técnica de análisis del código fuente de una aplicación, con el fin de detectar vulnerabilidades de seguridad, errores de lógica, configuraciones inseguras y desviaciones de estándares de codificación segura.

Algunos de los beneficios de implementar un Code Review son:

• Al identificar vulnerabilidades en las primeras etapas del desarrollo, los desarrolladores pueden corregirlas rápidamente, previniendo así posibles ataques.
• Las revisiones de código seguro ayudan a mantener la calidad del código, ya que promueven buenas prácticas de codificación.
• Cuando los desarrolladores participan regularmente en las revisiones de código, son más conscientes de las implicaciones de seguridad de su código.

Implementación

Realizar un Code Review no es una actividad única, sino un proceso continuo que de forma general se puede conformar por las siguientes etapas:

1. Especificación
2. Ejecución
3. Remediación y seguimiento

1 Especificación

En esta etapa se definen los lineamientos y el alcance del Code Review, estableciendo entre otras cosas:

a). Marcos de referencia

b). Procedimientos y políticas internas

c). Actores y responsabilidades

d). Herramientas

a) Marcos de referencia.

Comprende todos aquellas normas y publicaciones que puedan ser utilizadas como guía para efectuar la práctica, se suele especificar en qué casos se puede utilizar así como las principales áreas de interés.

— Por ejemplo en esta parte se especifica si se usara OWASP Code Review Gide como referencia y que la estrategia de ramas a utilizar sera Gitflow.

b) Procedimientos internos.

Se en listan los procedimientos internos para la práctica que determinan cuándo se realizará y cuáles son los pasos a seguir.

— Por ejemplo en esta parte se especifica que el Code Review se realizara después de crear un Merge Request y una vez que el pipeline sea exitoso.

c) Herramientas.

Se definen las herramientas a ser utilizadas con la finalidad de llevar acabo los análisis estáticos del código.

— Por ejemplo en esta parte se especifica que se utilizara SonarQube para el análisis de code smell y cobertura en pruebas unitarias, Dependecy-Check para el análisis de composición SCA de software y SpotBugs para el análisis de seguridad estático SAST.

d) Actores y responsabilidades.

Se determina quienes participan en cada una de las acciones así como las responsabilidades.

— Por ejemplo en esta parte se especifica que el desarrollador creara un Merge Request y avisara a su líder técnico para que ambos lleven acabo el Code Review.

2 Ejecución

En esta etapa se basa en los lineamientos establecidos en la etapa anterior y suele esta conformada por las siguientes partes:

a) Proceso inicial.

b) Análisis automático.

c) Revisión entre pares.

a) Proceso inicial.

Este proceso está relacionado a la estrategia de ramas así como a las validaciones que establezcan los lineamientos.

— Por ejemplo este proceso seguiría el siguiente flujo:

• El desarrollador termina de codificar la funcionalidad.
• El desarrollador verifica que todas las pruebas unitarias pasen.
• El desarrollador ejecuta los análisis estáticos (SCA, SAST, Linter) de forma local.
• Genera un Merge Request de acuerdo a la estrategia de ramas.

b) Análisis automático

En función de la estrategia de ramas vigente, se ejecutan las validaciones que establezcan los lineamientos.

— Por ejemplo este proceso suele ser ejecutado por un pipeline el cual realiza las siguientes tareas de forma controlada:

• Ejecución de pruebas unitarias
• Análisis de composición de software SCA utilizando las herramientas especificadas en los lineamientos (Dependecy-Check).
• Análisis estático de seguridad SAST utilizando las herramientas especificadas en los lineamientos (SpotBugs).
• Análisis estático de código Linter utilizando las herramientas especificadas en los lineamientos (SonarQube).

c) Revisión entre pares

En esta etapa se reúnen los actores especificados en los lineamientos para tener una platica significativa en donde revisan los reportes de las herramientas así como el código modificado.

— Por ejemplo en esta parte se suelen llevar acabo las siguientes actividades:

• El desarrollador y líder técnico revisan que el pipeline sea exitoso y que los reportes de las herramientas no muestren problemas.
• El líder técnico verifica junto al desarrollador el código modificado con la finalidad de determinar si cumple con los estándares requeridos así como si se implemento la funcionalidad requerida.
• El líder técnico realiza comentarios con las observaciones encontradas para que el desarrollador pueda realizar las correcciones pertinentes.
• En función de los hallazgos y las correcciones se determina si dicho código puede o no ser integrado para faces posteriores (pruebas automatizadas y manuales).

3 Remediación y seguimiento

Terminada la revisión entre pares, se procede a clasificar los hallazgos que aún están presentes siguiendo los lineamientos vigentes, para acomodar el plan de acción.

a) Clasificación de los hallazgos

b) Planificación

c) Seguimiento

a) Clasificación de los hallazgos

En esta etapa con base en los lineamientos se clasifican los hallazgos en función de su severidad.

— Por ejemplo en esta etapa el líder técnico genera una lista con los hallazgos que no se han resuelto indicando la severidad del hallazgo y y la posible acción de mitigación.

b) Planificación

Terminada la clasificación de los hallazgos se determina cuando, como y quién realizará las acciones de mitigación así como la verificación de las mismas.

— Por ejemplo en esta etapa se agrupan los hallazgos de menor severidad y se integran al plan de mitigación de deuda técnica y los hallazgos de mayor severidad se integran al spring actual para ser atendido por los desarrolladores.

c) Seguimiento

Con base en el plan anterior mente creado se da seguimiento a la mitigación de los hallazgos.

— Por ejemplo El líder técnico junto con el equipo realiza una revisión del plan de mitigación de deuda técnica al inicio de cada spring para determinar que incorporar al spring.