El software es un elemento del sistema que ni se estropea ni envejece. Eso significa que las posibles causas de fallo vendrán o bien de un fallo del hardware (sobre el que se ejecuta o de los periféricos que usa) o por un defecto en su desarrollo que hace que este no se comporte como se espera en función de las especificaciones en una situación particular. Para el caso de los fallos del hardware se emplean técnicas de tolerancia a fallos que principalmente se basan en redundancias de los componentes críticos y en las que no entraremos.
La segunda fuente de fallos es más difícil de tratar y se basa en reducir al máximo posible, puesto que es prácticamente imposible erradicarlo al 100%, los defectos en el software. Es importante tener en mente que estamos asumiendo que la lógica especificada es correcta y que los problemas vienen de defectos que hacen que el software no siga la lógica definida. Si tenemos problemas en cuanto a la lógica del sistema (especificaciones de lo que debe hacer) nos encontramos en un caso de errores de diseño, los cuales deberían haberse detectado y subsanado en las etapas de diseño.
Aunque el uso de una única técnica de análisis no permite localizar todos los defectos de un sistema, en las siguientes secciones vamos a centrarnos en el análisis estático, ya que es una técnica que por sí misma es capaz de encontrar un número elevado de defectos en el software siendo una técnica relativamente sencilla de aplicar, por lo cual presenta un gran valor y es recomendada independientemente del nivel de seguridad.
¿Qué es el análisis de código estático?
El análisis de código estático consta de una serie de comprobaciones automatizadas que se realizan en el código fuente. Una herramienta de análisis estático escanea el código en busca de errores y vulnerabilidades comunes conocidas, como fugas de memoria o desbordamientos de búfer. El análisis también puede hacer cumplir las reglas de codificación.
Cuando la seguridad es una prioridad, las herramientas especializadas en pruebas estáticas de seguridad de aplicaciones (SAST) pueden comprobar los fallos de seguridad conocidos. Dado que el análisis estático se realiza en el código fuente, sin ejecutar el programa, puede ejecutarse al principio del proceso de CI/CD o directamente desde su IDE antes de confirmar los cambios.
Al igual que todas las formas de pruebas automatizadas, el análisis de código estático garantiza que las comprobaciones se realicen de forma coherente y proporciona feedback rápido sobre los últimos cambios. Las herramientas de análisis estático integradas en su IDE ofrecen feedback inmediato y específico para que pueda solucionar los problemas sobre la marcha.
Sin embargo, el análisis estático solo puede identificar los casos en los que se rompen las reglas programadas; no puede encontrar todos los fallos únicamente leyendo el código fuente.
En ese sentido, el análisis de código estático es un valioso complemento de las revisiones de código, ya que pone de manifiesto los problemas conocidos y libera tiempo para tareas más interesantes, como la revisión del diseño y el enfoque general.
El análisis estático del código forma parte del arsenal de comprobaciones automatizadas que puede utilizar para mantener la calidad del código y debe usarse en combinación con otras formas de análisis dinámico (que ejecuta su código para comprobar los problemas conocidos) y las pruebas automatizadas.
¿Cómo abordar el análisis estático de código?
Para abordar de forma más clara el análisis de código es necesario clasificar las características del código software en Factores de Salud, que serán diferentes según los estándares que se apliquen.
De forma genérica podemos agrupar las características del código en:
Confiabilidad: Se trata de evitar comportamientos inesperados. Es necesario controlar todos los casos posibles y no realizar operaciones que provoquen resultados indeterminados.
Rendimiento: Los recursos no son ilimitados. Hay ocasiones en las que tendemos a pensar que todo se soluciona asignando más recursos, pero es conveniente un uso eficiente de los recursos existentes.
Seguridad: La información debe estar suficientemente compartimentada, cada usuario debe poder acceder solo a aquello para lo que tiene permiso.
Mantenimiento: Cualquier cambio que haya que abordar será tanto más traumático cuanto más complejo y peor documentado sea el código.
Los factores como la confiabilidad, rendimiento y seguridad buscan evitar riesgos en el entorno productivo, mientras que la mantenibilidad y factores similares pretenden dar una idea del coste de propiedad del software.
Hay que tener también en cuenta que cada lenguaje de programación presenta sus particularidades y buenas prácticas. Éstas se traducen en reglas que se asignan a los factores de salud mencionados. Así, no es lo mismo analizar código Cobol que Java, y aunque pueden compartir algunas reglas, otras serán específicas del lenguaje.
Por otra parte, habría que decidir la conveniencia de acudir al análisis manual o al automatizado. Los criterios para elegir uno u otro vienen condicionados por aspectos como:
- La tecnología que se pretende analizar
- El tipo de licenciamiento.
- El establecimiento de prioridades, es decir la necesidad de una mayor profundidad en el análisis frente a un mayor tiempo de respuesta.
Cuando se prestan servicios de análisis manual de código no es necesario disponer de ninguna herramienta, aunque sí de un profundo conocimiento:
- Del lenguaje y sus buenas prácticas.
- Del entorno y el contexto del cliente.
Finalmente, es necesario tener en cuenta que, aunque el análisis sea automatizado, el resultado está sujeto a interpretación. Algunas reglas en algunas herramientas causan falsos positivos o pueden no ser aplicables en ciertos ámbitos.
0 comentarios