Una auditoría de código o SAST, es como se denomina comúnmente en castellano a la práctica de validar una garantía de requisitos de seguridad de una aplicación o sistema revisando su código. Al revisar la seguridad y los riesgos de una aplicación o sistema, desde este enfoque interno, apoyándote en la lectura del propio código que lo sustenta y la revisión de su arquitectura, llevas a cabo el descubrimiento de sus debilidades y vulnerabilidades, que tienen base en un diseño inseguro o malas practicas en el código. Este es el proceso principal llevado a cabo dentro de la gestión o consultoría en desarrollo seguro de software.
También puede hacerse referencia a una auditoría de código con los siguientes términos: Análisis de código estático, revisión de código o en inglés Static Application Security Testing (SAST).
pu3d35 l33R 3st0? pRu3b4 Letra hacker
Proceso de auditoría de código
Este proceso se realiza principalmente revisando y leyendo el código. Esté habitualmente se presenta en forma de código fuente original, aunque también se puede realizar a partir de ejecutables, mediante ingeniería inversa o software especializado.
A veces se la llama revisión de código, pero es frecuentemente que este término se emplee en control de calidad y en control de seguridad se use la palabra auditoría.
Necesito auditar la seguridad de mi código?
Necesitas unos requisitos mínimos de seguridad? la respuesta siempre es sí. Aunque concretamente una auditoría de código es adecuada al menos y especialmente en las siguientes dos situaciones.
Si desarrollas software
En desarrollo de software siempre hay que cumplir unos requisitos mínimos de seguridad, estos requisitos pueden variar mucho. Habrá que analizar los riesgos y el contexto de este software para estimar los requisitos de seguridad que debes ofrecer.
No es lo mismo escribir un sencillo script para un procedimiento interno en uno de los servidores de la empresa (que no digo que no implique riesgos), que desarrollar y vender una aplicación web a un tercero. En este segundo ejemplo, la aplicación estará expuesta a internet y será usada por miles de personas, como puedes imaginar los riesgos e implicaciones son otras.
Si haces uso de software propio
Cuando una organización hace uso de un software desarrollado o modificado de forma personalizada, debe interesarse especialmente por los requisitos de seguridad que este cumple y si ha tenido algún control sobre este aspecto. Ya que es muy habitual que por falta de tiempo esto no se haya realizado.
Cuando tu o tu organización hace uso de un producto software, es habitual pensar que este cumple unos requisitos mínimos de seguridad por el propio hecho de ser un «producto final». Aunque la realidad es muy diferente.
Riesgos
Incumplir requisitos de seguridad no es tan evidente como incumplir requisitos de calidad. Para los segundos un usuario medio de la aplicación puede detectar y dar feedback sobre parte de estos y usualmente los desarrolladores, arquitectos y testers tienen una apreciación de la calidad y un aseguramiento de esta inherente a su trabajo. No ocurre igual con los requisitos de seguridad.
Aunque un agujero de seguridad pueda ser descubierto sin querer, lo habitual es que se descubran buscandolos mediante un uso malintencionado y no habitual de la aplicación. Mediante uso de herramientas y pruebas especializadas del ámbito de la ciberseguridad.
El software desarrollado ad hoc para una organización, es el lugar donde esta tendrá agujeros de seguridad con mayor probabilidad. Esto se debe al sencillo hecho de que estos serán sus componentes software menos probados y validados por la industria, al usarse por ellos en exclusiva.
En qué momento hacerla?
Es común desarrollar software primero y después solicitar una auditoría. Esto puede ser muy improductivo puesto que los resultados de una auditoría de código consisten en una serie de vulnerabilidades encontradas y las modificaciones u acciones necesarias para corregirlas.
Esta corrección tardía puede pasar por usar otra versión de una librería o incluso sustituirla, cambiar un concepto asumido en fase de diseño, modificar la manera en la que se implementa la lógica de un proceso, etc… Es decir, habitualmente implica un tiempo mucho mayor que si se hubiera detectado y reconducido la situación antes.
Es mejor realizar varias auditorías a realizar una sola. También es mejor hacer como mínimo una a medio desarrollo y una en la finalización. Lo anterior lo explicare en otro post que abarcara el desarrollo seguro de software completo. En el que además se estableceremos otros hitos como el análisis de riesgos previo al desarrollo y el análisis de requisitos de seguridad durante la fase de diseño, unos requisitos claros que la aplicación deberá cumplir y que guiarán al equipo de desarrollo.
Conclusiones
Todo desarrollo de software que requiera cierto nivel de madurez debe gestionar sus posibles vulnerabilidades al igual que toda organización que haga uso de este debe valorar sus riesgos. Para esto tenemos entre otras herramientas las auditorías de código o estáticas (SAST) que son las que ocupan con su descripción este articulo.
Este tipo de práctica que forma parte de la gestión de la seguridad informática o ciberseguridad se complementa como comentaba con tantas otras como el análisis de riesgos, creación de políticas de seguridad, descubrimiento de vulnerabilidades, pentesting, auditorías dinámicas (DAST), etc…
Espero haber aclarado las posibles dudas sobre que es una auditoría de código a nivel conceptual. Si no es así por favor escribeme y comenta e iré mejorando el post. Tengo pensado escribir más sobre detalle técnico y aspectos concretos de estas.
Referencias y recursos para profundizar más en el tema
- Llevar a cabo la fase de revisión del código: https://auditoriadecodigo.com/realizando-una-auditoria-de-codigo-segunda-parte/
- Excelente introducción a la auditoría de código en español: https://securityinside.info/auditoria-de-codigo-algo-necesario-pero-que-nunca-hacemos-parte-1
- Introducción a la auditoría de código en Ingles: https://www.owasp.org/index.php/Code_Review_Introduction
- Proyecto y fundación referente a nivel mundial sobre auditorías de código y su documentación en detalle: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
- Entrada de Wikipedia sobre SAST en general, no tanto de ciberseguridad como de control de calidad: https://en.wikipedia.org/wiki/Static_program_analysis
