Revisión manual de código indispensable

Cuando nos empeñamos en crear productos en nuestro trabajo diario,
sea cual sea nuestra área, resulta una
y otra vez bastante beneficioso que antes de entregarlos,
antes de su presentación a los usuarios finales,
sean revisados por otra persona.
Recibir comentarios de colegas o líderes siempre ayudará
a mejorar nuestro rendimiento y la calidad de nuestros productos.
Esto sin duda se aplica al desarrollo de software.
Revisar el código que los desarrolladores construyen para dar forma,
por ejemplo, a aplicaciones web o móviles,
es un proceso fundamental para garantizar su alta calidad y seguridad.
En este artículo,
comparamos las revisiones de código automatizadas
y manuales y nos detenemos especialmente en el método manual.

¿Qué es la revisión de código?

La revisión de código es un proceso mediante
el cual se evalúa sistemáticamente un código fuente
para verificar su conformidad con estándares específicos.
Este cumplimiento permite que el producto de software
se mantenga con una cantidad reducida de fallas
o defectos (estará libre de estos muy de vez en cuando)
que muchas veces son el resultado de un enfoque improvisado
por parte de los desarrolladores.
La revisión de código puede centrarse en la arquitectura,
la funcionalidad y el estilo del software,
aunque también puede ocuparse de su seguridad.
De ahí el término revisión segura de código.
(Tómese como implícito el hecho de que,
cuando aquí hablamos simplemente de “revisión de código”,
nos referimos al análisis que implica la seguridad
ya que una revisión sin ella acaba siendo insuficiente).

La revisión de código se basa en estándares
y requisitos de codificación que, de hecho,
son los que los desarrolladores deben tener en cuenta desde el principio.
Los errores derivados de su incumplimiento,
por pequeños que sean,
pueden pasar una elevada factura
a la organización propietaria del código
y a las personas y entidades relacionadas,
especialmente cuando los delincuentes se aprovechan de ellos.
Hoy en día, principalmente dentro
del enfoque DevSecOps,
se recomienda que la revisión de código se realice al principio
del ciclo de desarrollo de software (SDLC)
antes de desplegar el software en producción.
La idea es que sea una operación constante para
que los problemas se notifiquen a los desarrolladores cuanto antes
y para evitar costos elevados en el futuro.

Revisión de código automatizado vs. manual

Tanto las personas expertas como las herramientas automatizadas
pueden realizar revisiones de código.
Actualmente, existe toda una serie de herramientas para la revisión de código.
Y aunque estas pueden variar en características como facilidad de uso,
apariencia y funciones, aquí hacemos una comparación en términos generales.
La revisión automatizada de código es menos costosa
y puede abarcar mucho más código en menos tiempo que la revisión manual.
De hecho, cuando se encarga a un revisor que lea
y revise el código manualmente, línea por línea,
normalmente solo se le asigna un fragmento
o segmento concreto de código.
En el caso de productos grandes, llevaría mucho tiempo
y esfuerzo revisar todo el código manualmente.
Así pues,
esta forma de revisión tiene generalmente menos alcance
que la realizada por máquinas inteligentes,
pero, como veremos, es un procedimiento indispensable dadas
las limitaciones de las herramientas.

Las herramientas automatizadas disponen de una base de datos de estándares
y requisitos predefinidos para la revisión de cumplimiento
y la detección de errores.
Las organizaciones que adquieren las herramientas pueden configurarlas
para que sigan unas normas concretas e ignoren otras
y para que funcionen según uno
o varios lenguajes de programación específicos.
La cuestión es que todo lo que queda fuera de las capacidades
predeterminadas de la herramienta escapa de su radar de detección.
Además, no todo lo que informa una herramienta
representa realmente un problema o falla en el código.
Nos referimos a estos dos últimos obstáculos
como falsos negativos (omisiones)
y falsos positivos (mentiras), respectivamente.
Evitar que estén presentes a la hora
de realizar informes de revisión de código está entonces
en manos de los expertos y de su trabajo manual.

Uno de los mayores defectos
de las herramientas de revisión de código es su incapacidad
para detectar los llamados defectos en la lógica empresarial.
Las herramientas automatizadas no comprenden
las intenciones humanas ni la lógica empresarial
que hay detrás de un sistema particular.
La lógica empresarial se refiere a la parte del software
que codifica las reglas empresariales
que determinan procesos como la creación,
modificación y almacenamiento de datos.
La lógica empresarial describe múltiples series de actividades
o pasos en los que se establecen relaciones entre
la interfaz del usuario final y la base de datos.
En la mayoría de los casos, los defectos de la lógica empresarial
son propios de la aplicación en cuestión y de su funcionalidad.
Son diversos y no siguen patrones de riesgo definidos
o similares para todos los casos.
Además, no se localizan en una línea de código específica,
sino que afectan a varias áreas de la totalidad de la arquitectura.

Las reglas de negocio dictan las respuestas o reacciones del software
(por ejemplo, acciones de prevención)
ante los distintos escenarios posibles.
Las vulnerabilidades en la lógica de negocio suelen significar
la incapacidad del software para detectar
y manejar correctamente algunos escenarios,
ciertos comportamientos extraños o inesperados de los usuarios
que los desarrolladores no tuvieron en cuenta o no previeron.
Ahí es donde los atacantes capitalizan su astucia.
Por ejemplo, digamos que la lógica
de una aplicación de transferencia de dinero no restringe
la entrada del usuario de acuerdo
con lo que podría haberse determinado en las reglas de negocio.
En su lugar, permite la entrada de valores negativos,
lo que puede conducir a un procedimiento imprevisto como,
imaginémonos algo, extraer dinero, en lugar de depositarlo,
al supuesto destinatario de la transferencia.
Este tipo de vulnerabilidades suelen calificarse
con una severidad muy alta debido
a los posibles impactos de su explotación.
La revisión manual de código tiene como tarea detectar
y notificar estos problemas de seguridad enormemente peligrosos.

Sin embargo, en términos generales,
más que considerar la sustitución
o el reemplazo de un método por otro,
deberíamos hablar de complementación.
Lo ideal sería utilizar ambos métodos, no solo uno.
La revisión automatizada de código, con su alcance y rapidez,
permite reducir el tiempo y el esfuerzo invertidos
en la revisión manual de código.
Permite al experto concentrarse en fragmentos de código
que pueden tener vulnerabilidades más complejas
y graves que las que puede identificar la máquina.
Por desgracia, hay muchos que, en su ignorancia,
siguen creyendo que una o varias herramientas automatizadas
que funcionan en sus organizaciones son suficientemente buenas.
No han prestado atención a comentarios formulados en comunidades
como OWASP:
la revisión manual de código debería ser un componente
del ciclo de vida seguro de una empresa,
ya que en muchos casos es tan buena, o mejor,
que otros métodos de detección de problemas de seguridad.

Centrados en la revisión manual de código

La revisión manual de código pueden realizarla colegas de los desarrolladores,
ingenieros superiores u otros profesionales,
incluidos proveedores externos como Fluid Attacks con
su revisión segura de código.
Las personas encargadas de una revisión exhaustiva de código
deben tener amplios conocimientos sobre desarrollo de software,
lenguajes de programación, prácticas de codificación segura,
estándares de seguridad,
requisitos
y vulnerabilidades,
entre otras cosas.
Deben ser capaces
de pensar y actuar como actores de amenazas
y tener la virtud de la paciencia y una vasta experiencia en revisiones.
Sin embargo, algunos revisores pueden estar empezando a adquirir experiencia
y no deben ser excluidos,
sino que simplemente pueden recibir asistencia
de otras personas más experimentadas.
Esta decisión, en cualquier caso,
puede variar en función de las necesidades
y características del código de la organización que solicita el servicio.
Ten en cuenta, como se comenta en
la Guía de revisión de código de OWASP,
por ejemplo,
que “un nuevo módulo de autenticación de inicio
de sesión único en una empresa multimillonaria no será revisado
de forma segura por una persona que una vez leyó
un artículo sobre codificación segura.”

Siempre es recomendable que una sola persona
no haga una revisión manual de código.
Lo que inicialmente escapó a los ojos del desarrollador,
en algunos casos, también puede eludir los ojos del revisor.
Aunque con la inclusión de una segunda persona también puede ocurrir lo mismo,
las probabilidades se reducirían sin duda.
Además,
el trabajo realizado por varias personas favorece
la creación de un entorno de colaboración entre los miembros
de los equipos de desarrollo y revisión.
La cooperación puede producirse cuando
el revisor no es visto como un vigilante,
sino como un asesor que influye positivamente en la eficacia
de los desarrolladores con comentarios pertinentes.
Los revisores deben pedir a los desarrolladores
que les envíen pequeños cambios
en el código para mejorar el flujo de trabajo.
Y pueden hacer las revisiones en ambientes aislados
de aquellos en los que puedan estar trabajando los desarrolladores
para que no actúen como obstáculos.

Para llevar a cabo revisiones integrales y eficaces,
los expertos deben estar en contexto, saber lo que están evaluando.
Deben conocer y comprender a grandes rasgos las funciones,
propósitos y características del software que van a evaluar,
incluidos los lenguajes de programación y las bibliotecas
y otros componentes utilizados y sus interacciones.
A partir de ahí, los revisores deben plantearse preguntas
como qué puede ocurrir si falla alguna operación del código.
Deben saber qué tipos de usuarios están permitidos
y cuáles son sus permisos.
Deben comprender qué tipos de datos se procesan y de qué manera,
y preguntarse qué ocurriría si se vieran expuestos.
Además, deben modelar las amenazas potenciales,
en parte reconociendo los agentes de amenaza y sus posibles propósitos,
y, dependiendo del tipo de software,
anticipar qué vulnerabilidades de seguridad pueden encontrar.

La cantidad de información que debe recopilarse
en una revisión de código dependerá del tamaño de la organización,
de las habilidades de los revisores
y de los riesgos potenciales del código.
Una buena forma de iniciar esta recopilación puede ser establecer contacto
y conversación con los desarrolladores de la aplicación
para recibir al menos alguna información básica.
Las herramientas automatizadas también entran en juego
para proporcionar datos generales antes
de aplicar la revisión manual en áreas específicas del código
(priorizadas, por ejemplo, por riesgo)
para evaluar el estilo, la interpretación y la seguridad.
Herramientas como los linters pueden incluso ser utilizadas
de antemano por los desarrolladores para obtener ayuda
en la identificación de errores sencillos de formato,
como errores tipográficos.

En la revisión de código, manteniendo como soporte
y guía los estándares establecidos o solicitados por la organización,
incluyendo, por supuesto, las reglas de negocio,
los revisores conocerán primero la arquitectura
y el estilo del código y, por tanto, sus errores.
En cuanto los estándares, los revisores pueden manejar listas
de requisitos de seguridad adaptadas al diseño del software
que no pueden pasarse por alto, como los siguientes:
validación de entradas, autenticación y gestión de contraseñas,
control de acceso y gestión de sesiones,
criptografía y protección de datos,
gestión de errores y registro,
configuración y control del sistema, entre otros.
Los revisores señalarán la superficie de ataque
y los posibles vectores de ataque,
los controles de seguridad implementados hasta el momento
(¿en qué medida se están protegiendo los activos y las operaciones?),
las vulnerabilidades presentes,
los riesgos estimados y los posibles impactos, etc.
La categorización y calificación de las vulnerabilidades
son bastante útiles ya que permiten su priorización
para la posterior remediación por parte del equipo de desarrolladores.

Por cada error o problema de seguridad detectado en el código,
los revisores deben recomendar una modificación
para cumplir los requisitos previamente definidos.
Si es necesario,
vuelven a establecer contacto con el equipo de desarrollo
para iniciar conversaciones
(p. ej., sobre la viabilidad de los cambios sugeridos)
o resolver dudas y dificultades.
Posteriormente, si es necesario,
los revisores proponen recomendaciones o soluciones alternativas
y definen excepciones para llegar a un acuerdo.
Tras las incorporaciones o modificaciones por parte de los desarrolladores,
puede tener lugar una nueva revisión para verificar
que han tenido en cuenta las sugerencias
y que su producto es ahora de mayor calidad y seguridad.

En Fluid Attacks,
te ofrecemos nuestra revisión de código seguro
(para más detalles, lee este artículo),
con revisión automatizada y manual de código,
dentro de un servicio integral llamado Hacking continuo.
Este servicio no se limita
a pruebas de seguridad de aplicaciones estáticas
y análisis de composición de software.
Más allá de la intervención de nuestras herramientas automatizadas
(te invitamos a utilizarlas gratuitamente durante 21 días),
las cuales también realizan
pruebas de seguridad de aplicaciones dinámicas,
empleamos métodos como las pruebas de penetración manuales
y la ingeniería inversa
con nuestros hackers éticos altamente certificados.
Para más información sobre cómo podemos ayudarte a evitar
que tu organización sea víctima de ciberataques,
no dudes en contactarnos.