Revisión de código fuente

“Si no se ha revisado la seguridad del código,
la probabilidad de que la aplicación tenga problemas
es prácticamente del 100%”.
Este es un mensaje contundente en las primeras páginas de
la guía de revisión de código de OWASP.
Una organización que no pone el código que utiliza
y desarrolla bajo revisión es irresponsable con sus activos
y los de sus clientes o usuarios.
Los problemas de seguridad de sus productos
pueden ser explotados por los ciberdelincuentes,
provocando fugas de datos o interrupciones en las operaciones
y las consiguientes multas y pérdida de clientes y reputación.
Para evitar todo esto,
es prudente acompañar el desarrollo de software desde el principio con
una revisión del código fuente.

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

La revisión de código fuente
(SCR, por sus siglas en inglés)
es el análisis del código fuente de una aplicación
para identificar fallas de seguridad o vulnerabilidades.
Estas aparecen en el ciclo de vida de desarrollo de software (SDLC)
y deben cerrarse o corregirse para reforzar la seguridad del código.
La revisión del código fuente puede tener lugar en cualquier punto del SDLC,
pero dentro de la cultura DevSecOps,
es más valioso utilizarlo desde las primeras fases.
Se trata de un procedimiento que puede realizarse de forma manual o automática.

Ahora tu pregunta puede ser:
¿Cómo funciona el proceso de revisión de código?

El proceso de revisión del código fuente

La revisión manual del código se lleva a cabo con gran atención al detalle.
Uno o varios analistas de seguridad examinan cada línea de código,
entendiendo lo que están evaluando, teniendo en cuenta su uso y contexto,
las intenciones del desarrollador y la lógica empresarial.
Por otro lado, la revisión automatizada
y segura del código fuente es un proceso en el que se examina
más código en menos tiempo pero en el que no se tienen en cuenta
los factores anteriores. Las herramientas trabajan con
un conjunto predefinido de reglas,
están restringidas a ciertos tipos de vulnerabilidades
y algunas padecen el defecto de reportar falsos positivos
(decir que algo es una vulnerabilidad cuando no lo es).
Entre los métodos más utilizados en la revisión de código
se encuentran las pruebas de seguridad de aplicaciones estáticas
(SAST)
y el análisis de composición de software
(SCA).
(En este artículo anterior del blog
se explica en qué se diferencia uno del otro).

¿Cómo realizar una revisión de código fuente?

La mejor opción para lograr una sólida revisión del código
es tomar las revisiones manuales y automatizadas
y fusionarlas para aprovechar sus funciones particulares.
Las herramientas automatizadas de revisión del código fuente,
con su evaluación rápida y “superficial” de la superficie de ataque,
facilitan que los analistas de seguridad se centren
en identificar vulnerabilidades más complejas y críticas para la empresa.
Los expertos, especialmente
los hackers éticos,
que aplican las buenas prácticas de revisión de código,
teniendo también en cuenta la perspectiva de los atacantes,
pueden evaluar el código para reconocer los problemas de seguridad
que más contribuyen a la exposición al riesgo del objetivo de la evaluación.
(Por ejemplo, en nuestro último reporte de State of Attacks,
compartimos que el 67,4% de la exposición total al riesgo
en los sistemas evaluados se notificó mediante el método manual).
Esto hace posible que la remediación de vulnerabilidades,
una acción que siempre debería estar conectada a la revisión del código,
pueda seguir una prioridad.
La idea es reducir al máximo el número
de vulnerabilidades que pasan a producción,
pero siempre reparando primero las más peligrosas.

Herramientas de revisión de código fuente

Para la implementación automatizada de los métodos anteriormente mencionados
que se utilizan habitualmente en la revisión del código,
es decir, SAST
y SCA,
hay herramientas disponibles que identifican rápidamente
las vulnerabilidades de seguridad conocidas.

Herramientas de pruebas de seguridad de aplicaciones estáticas (SAST)

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

Herramientas de análisis de la composición del software (SCA)

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

Revisión de código fuente vs. pruebas de seguridad de las aplicaciones

Las pruebas de seguridad de aplicaciones (AST)
son un concepto más amplio que la revisión del código fuente.
De hecho, esta última forma parte de la primera.
AST, aparte de la SAST y la SCA, incluyen métodos de evaluación
como las pruebas de seguridad de aplicaciones dinámicas
(DAST),
las pruebas de penetración manuales
(MPT)
y la ingeniería inversa
(RE).
Mientras que el SCR puede aplicarse
en cualquier fase del desarrollo de software, DAST y MPT,
por ejemplo, se emplean generalmente cuando la aplicación se puede
ejecutar para evaluar su comportamiento a través de vectores de ataque.

¿Por qué es necesaria una revisión de código fuente?

Un equipo de desarrollo exitoso,
comprometido con la seguridad de sus productos,
siempre tiene como pilar la revisión de código.
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 van realizando 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 estudios y lugares de trabajo.
E incluso los desarrolladores más experimentados,
debido a factores como el agotamiento o el descuido,
pueden cometer errores de codificación
y acabar generando vulnerabilidades como las enumeradas
en el Top 10 de OWASP
y el Top 25 de CWE.
Por razones como éstas,
el código fuente debe mantenerse bajo revisión
de expertos en seguridad constantemente.

Los mayores problemas de seguridad en la codificación

¿Por qué es importante la revisión de código fuente?
SCR identifica la ausencia de prácticas de codificación seguras,
la falta de controles de seguridad adecuados
y la infracción de estándares de cumplimiento
como PCI DSS
e HIPAA.
Los proveedores de revisión de código pueden encontrar, por ejemplo,
una validación inexistente o errónea de entradas
(verificar que cumplen unas características concretas)
procedentes de distintas fuentes que interactúan con la aplicación
(p. ej., usuarios, archivos, fuentes de datos).
Pueden descubrir que un desarrollador cometió el error
de dejar información confidencial
(p. ej., tokens, credenciales) dentro del código,
habiendo olvidado eliminarla después de haberla puesto
ahí sin justificación razonable.
Pueden ver que la información que sí necesita ser almacenada
y transferida no pasar por los algoritmos de cifrado adecuados.
Del mismo modo,
pueden descubrir 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 acaban dando acceso innecesario a cualquier usuario sin solicitar permiso.

Un problema importante que se descubre a menudo en la revisión de código
(con ayuda, por ejemplo, del método SCA)
son las vulnerabilidades de los componentes de software
de proveedores externos y de código abierto.
Hoy en día,
el desarrollo de aplicaciones depende en gran medida de dichos componentes,
que se importan de diversas fuentes
y sirven de soporte para lo que se pretende construir,
que a menudo resulta tener poca originalidad.
La dependencia también existe en algunos componentes frente a otros.
Así, al utilizar uno de ellos,
el desarrollador puede no ser consciente
de la relación de este con los demás.
Los ciberdelincuentes tienen entre sus objetivos deseados
estas dependencias y componentes para buscar vulnerabilidades que explotar.
Este es un problema tan frecuente que, de hecho, tal y como informamos
en el State of Attacks del 2022,
el problema de seguridad más común entre los sistemas evaluados fue
“Uso de software con vulnerabilidades conocidas,”
y el requisito cuya violación supuso la mayor exposición total fue
“Verificar componentes de terceros.”

Prácticas de codificación seguras durante la revisión de código

Los expertos y las herramientas responsables
de una revisión de código fuente se encargarán de verificar
si los desarrolladores de software siendo evaluados han empleado
o no prácticas de codificación segura.
Aunque tenemos dos artículos en el blog que tratan más a fondo
las prácticas de codificación segura
(es decir, “Go Over and Practice Secure Coding”
y “Secure Coding in Five Steps?“),
que te invitamos a leer,
aquí tienes algunas de esas prácticas que deberían ser siempre
un punto de referencia para el desarrollo y la revisión del código.

Específicamente,
asegúrate que tu software cumpla objetivos como los siguientes:

• Validar las entradas procedentes de fuentes no fiables
  y aceptar solo las que cumplan características específicas.
• Verificar la identidad de los usuarios o entidades
  que desean acceder a recursos privados y, en operaciones críticas,
  solicitar autenticación multifactor.
• Exigir a los usuarios que creen contraseñas de complejidad elevada.
• Restringir el acceso a recursos de alto valor
  solo a unos pocos usuarios autorizados.
• Dar a los usuarios acceso por defecto únicamente a los recursos necesarios
  para realizar determinadas tareas.
• Establecer tiempos de inactividad de sesión relativamente cortos.
• Utilice algoritmos de cifrado reconocidos, comprobados
  y actualizados para la información sensible en tránsito y en reposo.
• No poseer datos sensibles como comentarios dentro del código.
• No revelar información valiosa a los atacantes en mensajes de error
  resultantes de actividades inválidas.
• Todos los componentes elaborados por terceros
  deben estar actualizados a su última versión.

Para más información sobre prácticas de codificación segura,
también puedes consultar las recomendaciones de OWASP
para desarrolladores en su Code Review Guide.

¿Cuándo se debería implementar una revisión de código fuente?

La revisión de código forma parte de un enfoque preventivo,
que debería abordarse prioritariamente, en vez de tener un enfoque reactivo.
Aplicar este método desde las primeras líneas de código permite identificar
y corregir las vulnerabilidades antes de pasar a producción,
para no tener que estar parcheando la aplicación continuamente.
Mantenerse un paso adelante de los hackers maliciosos
y bloquear en el código cualquier posible entrada para usos indebidos,
incluso travesuras simples,
es sin duda una estrategia muy eficaz para reducir la probabilidad
de catástrofes causadas por ciberataques.

Otros beneficios de las revisiones de código fuente

La revisión de código fuente permite que el número de errores
o vulnerabilidades encontrados en las etapas finales del SDLC,
a través de procedimientos como MPT, sea menor.
Por lo tanto,
también se puede reducir el tiempo que los desarrolladores
tienen que dedicar a los procesos de remediación en estas etapas.
Solucionar un gran número de vulnerabilidades
poco antes de pasar a producción se convierte
en una piedra en el zapato para los desarrolladores.
Ten siempre en cuenta que es más fácil
y menos costoso hacer correcciones de código
en el entorno de desarrollo que en producción.
Con una revisión continua del código fuente,
estás más cerca de la causa del problema
y puedes solucionarlo inmediatamente,
evitando cualquier acumulación.

Gracias a una revisión temprana del código,
los desarrolladores pueden empezar a asumir el compromiso
no solo de subsanar los problemas de seguridad detectados en sus productos,
sino también de hacer que sus resultados sean mejores cada día.
Esto puede ser un proceso en cadena.
Ciertos grupos de desarrolladores,
con la ayuda de los equipos de seguridad y sus pruebas o revisiones,
pueden transmitir conocimientos,
inspirar a otros a mejorar sus prácticas y productividad
y realizar la transición hacia una mentalidad
en la que todos en la organización son responsables de la seguridad.
Esos errores de seguridad que tan a menudo dieron lugar
a vulnerabilidades pueden volverse menos frecuentes con el tiempo.

Las organizaciones que deciden implementar la revisión de código
en sus procesos de desarrollo de software
reconocen la responsabilidad de cumplir
con los estándares establecidos en sus industrias.
Buscan ofrecer productos y servicios que garanticen
la seguridad de sus operaciones, datos y otros recursos,
principalmente los de sus clientes o usuarios.
De esta forma, consiguen generar confianza
y reflejar compromiso y calidad.
Esto afecta su competitividad favorablemente
y les ayuda a mantener una reputación sólida.

¿Cómo elegir tu equipo de revisión de código fuente?

Aunque un equipo de desarrolladores
puede hacer sus propias revisiones de código,
por ejemplo cuando un desarrollador pide a un compañero
que revise su build para evitar errores lógicos o de estilo,
se recomienda que, en temas de seguridad,
participen expertos en la materia.
La revisión por parte de un agente externo puede garantizar
que se informará todas las fallas manteniendo una perspectiva imparcial.

Los principales elementos de una revisión de código
dentro de un buen equipo de ciberseguridad deberían
ser un grupo de expertos en seguridad ampliamente certificados
y herramientas automatizadas que muestren
bajos índices de falsos positivos.
Sus evaluaciones deberían poder realizarse en una amplia gama
de lenguajes de programación,
basarse en múltiples estándares internacionales de seguridad
e informar de los hallazgos en un único panel que priorice,
fomente y facilite la remediación.

Solución revisión de código fuente de Fluid Attacks

En Fluid Attacks,
ofrecemos nuestra solución de revisión de código fuente
como una evaluación exhaustiva y precisa del código fuente de tu software,
combinando procedimientos manuales
(por parte de nuestros hackers éticos certificados)
y automáticos basados en métodos como SAST
y SCA.
(En 2021,
nuestra herramienta SAST automatizada obtuvo una puntuación perfecta
en el OWASP Benchmark v.1.2. y, en 2022,
fue aprobada por la App Defense Alliance
para validar los requisitos de nivel 2 del marco de evaluación
de seguridad de aplicaciones en la nube de la Alliance.
También cabe destacar que se trata de una herramienta
de revisión de código abierto).
Con nosotros,
puedes aplicar la revisión de código desde
las primeras etapas de tu SDLC de forma continua.
Puedes resolver tus problemas de seguridad rápidamente
(priorizando aquellos que representan la mayor exposición al riesgo)
en favor de la productividad de tu equipo de desarrollo
y de la seguridad de tus productos.

Nuestro SCR soporta alrededor de 40 lenguajes de programación,
incluyendo C, C#, C++, HTML, Java, JavaScript, PHP, Python, Ruby y Swift.
Tenemos entre nuestros requisitos de revisión los que figuran
en más de 60 estándares de seguridad,
internacionales,
incluidos CERT, CVE, CWE, HIPAA, NIST, OWASP y PCI DSS.
Y nos ajustamos a los requisitos específicos de tu aplicación
y lógica de negocio, todos ellos en constante revisión y actualización.
Integramos nuestro agente CI
en tus pipelines CI/CD para romper el build
cuando hay incumplimientos de políticas y vulnerabilidades abiertas.
Y te informamos de todo en nuestra plataforma,
donde puedes comprender y analizar a fondo tus problemas de seguridad,
así como recibir recomendaciones y gestionar los procesos de remediación.
Además,
tus desarrolladores pueden tener a mano nuestra extensión IDE
para VS Code para un reconocimiento
más rápido de las líneas de código afectadas.
Todo esto forma parte de nuestro servicio
de Hacking Continuo
que también integra métodos de pruebas de seguridad
como DAST,
pruebas de penetración manuales
e ingeniería inversa.

No dudes en contactarnos
si deseas más información sobre nuestro servicio de revisión de código fuente
y otras soluciones de nuestro Hacking Continuo.
Pulsa aquí
para probar nuestro Plan Machine de Hacking Continuo
de forma gratuita durante 21 días.