La indispensable revisión manual de código

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 alguien más. Recibir retroalimentación de colegas o líderes siempre ayudará a mejorar nuestro rendimiento y la calidad de nuestros productos. Esto sin duda aplica para el 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.

La revisión de código es un proceso mediante el cual se evalúa sistemáticamente un código fuente para verificar su cumplimiento de 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 descuidado 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 de código seguro (el cual en ciberseguridad usamos junto con “revisión de código fuente” indistintamente). (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 involucra la seguridad, ya que una revisión sin atender a ella termina 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 a 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.

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 o de negocio. Las herramientas automatizadas no comprenden las intenciones humanas ni la lógica empresarial que hay detrás de un sistema en 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 empresariales dictan las respuestas o reacciones del software (p. ej., 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 sacan partido de su astucia. Por ejemplo, digamos que la lógica de una aplicación de transferencia de dinero no restringe los inputs del usuario de acuerdo con lo que podría haberse determinado en las reglas empresariales. En su lugar, permite la entrada de valores negativos, lo cual puede conducir a un procedimiento imprevisto como, imaginémonos algo, extraer dinero del, 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 funcionando en sus organizaciones es suficientemente. No han prestado atención a comentarios como los formulados en comunidades como OWASP, en los que se da a entender que 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.

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 solución derevisión de código fuente. Las personas encargadas de una revisión exhaustiva de código deberían 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. Deberían 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 deberían 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 simplemente una vez leyó un artículo sobre codificación segura.

Para llevar a cabo revisiones integrales y eficaces, los expertos deben estar en contexto, saber lo que están evaluando. Deben conocer y comprender ampliamente 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 deberían 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, según el 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 los 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 empresariales o de negocio, los revisores aprenderán primero acerca de la arquitectura y el estilo del código y, por tanto, de sus errores. En cuanto a los estándares, los revisores pueden manejar listas de requisitos de seguridad adaptados al diseño del software que no pueden pasarse por alto, como los siguientes: validación de inputs, 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.

En Fluid Attacks, te ofrecemos nuestra revisión de código seguro o revisión de código fuente (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.