Tiempo de leer: 8 minutos¿Su equipo de desarrollo está abrumado por la creciente cantidad de violaciones de su herramienta de análisis estático? ¿El alto nivel de ruido generado por su configuración actual de análisis estático ha desensibilizado al equipo a todas las alertas, incluidas las relacionadas con problemas que considera críticos?
Aquí hay 10 formas de actualizar su implementación de análisis estático existente, sin importar qué herramienta de análisis estático estás usando.
Verificar muchas reglas no es el secreto para lograr el mejor ROI con análisis estático. De hecho, en muchos casos ocurre lo contrario. El análisis estático en realidad ofrece mejores resultados si se enfoca en un conjunto de reglas mínimo pero significativo.
Cuando realiza un análisis estático, es como si tuviera un desarrollador experimentado que se colocara sobre el hombro de un desarrollador sin experiencia y le diera consejos mientras escribe código. Si el desarrollador experimentado está constantemente insistiendo en los problemas delicados en cada pocas líneas de código, el desarrollador menos experimentado pronto se sentirá abrumado y comenzará a filtrar todos los consejos, tanto buenos como malos. Sin embargo, si el desarrollador experimentado se centra en uno o dos problemas que sabe que pueden causar problemas graves, es mucho más probable que el desarrollador menos experimentado recuerde los consejos que se le dieron, comience a escribir un código mejor y realmente aprecie recibir este tipo de comentarios. .
Lo mismo ocurre con el análisis estático. Si lo mantiene manejable y significativo, terminará enseñando más a sus desarrolladores y haciendo que se resientan mucho menos con el proceso. ¿Preferiría tener un conjunto pequeño de reglas que se sigan o un conjunto grande que no? Si realmente no espera que los desarrolladores eliminen las violaciones de una regla tan pronto como se informen, es posible que desee considerar seriamente la desactivación de esa regla.
Si una regla en particular se viola repetidamente, ahora es una buena oportunidad para reevaluar si realmente desea continuar verificando esa regla. Un número excesivo de infracciones indica que los desarrolladores no están escribiendo código de la forma que exige la regla. Convencerlos de que cambien sus hábitos de codificación podría encontrar bastante resistencia.
¿Cómo se puede determinar si valdrá la pena el esfuerzo de presionar el tema? Primero, trate de recordar por qué comenzó a buscar ese problema en primer lugar. ¿Lo seleccionó porque le pareció una buena manera de abordar los problemas que está experimentando en el campo? ¿Como parte de sus esfuerzos de cumplimiento normativo? ¿O simplemente porque el proveedor lo habilitó de forma predeterminada? Los proveedores suelen proporcionar la referencia para cada regla en sus descripciones de reglas. La lectura de estas descripciones puede ayudarlo a determinar si la regla es realmente una buena opción para sus proyectos y objetivos.
A continuación, vea si hay una forma alternativa de lograr el resultado deseado. ¿Existe una regla alternativa que sea más específica? ¿Hay alguna forma de ajustar los parámetros de la regla para que no se active con tanta frecuencia? (Más sobre esto en el consejo n. ° 6). Incluso podría considerar escribir su propia regla que se ajuste mejor, o hacer que el proveedor cree una regla personalizada para usted.
Si aún está interesado en verificar esta regla después de volver a examinar sus beneficios y explorar sus alternativas, obtenga algunos comentarios de desarrollo sobre lo que implicaría seguir esta regla. Luego, puede usar estos comentarios para determinar si realmente vale la pena exigir a los desarrolladores que sigan esta regla. Si parece mucho trabajo por poco beneficio, continúe y desactive la regla.
En algunos casos, es posible que esté comprometido a seguir una regla, pero desee permitir exenciones en determinadas circunstancias. Por ejemplo, tal vez tenga una regla que requiera que se realice algún nivel adicional de validación en el código. Suponga que tiene un método determinado con código crítico para el rendimiento que se llama cientos de veces por minuto, y ya ha verificado que se realiza un nivel adecuado de validación antes de llamar a este método en particular. O bien, suponga que el análisis basado en flujo le advierte sobre un problema grave en una ruta que está 100% seguro de que no se puede seguir en la aplicación integrada. Aquí es donde las supresiones resultan útiles.
Las supresiones son ideales para situaciones en las que desea verificar algo, pero no le importan los problemas reportados en situaciones excepcionales. Con las supresiones, puede continuar verificando un problema crítico sin recibir mensajes repetidos sobre sus violaciones intencionales de las reglas. Si no desea recibir mensajes de error por cualquier infracción de una regla específica, le recomendamos que desactive la regla por completo (consulte el punto 1).
Por lo general, puede definir supresiones desde la GUI de la herramienta de análisis estático, un archivo de configuración o el código fuente en sí. Cuando las supresiones se definen en el código fuente:
Por lo general, puede suprimir las infracciones de una regla específica, varias reglas o todas las infracciones de una categoría específica. También puede eximir ciertas secciones de código de todo análisis estático (más sobre esto en el siguiente punto).
A veces simplemente no tiene sentido ejecutar un análisis estático en ciertos archivos, por ejemplo, archivos generados automáticamente o archivos heredados que no planea tocar. En estos casos, debe evitar que se analicen estos archivos. Esta es otra forma de asegurarse de que sus resultados no estén abarrotados de infracciones que no planea corregir.
Hay varias formas de hacer esto. Puede configurar filtros de ruta para excluir los archivos que no desea verificar o incluir solo los que sí desea verificar. O bien, puede configurar su herramienta para omitir archivos que contengan un comentario determinado, como un comentario que indique un código generado automáticamente.
Otras formas de enfocar su cuenta de cheques incluyen:
Con el análisis estático basado en patrones, los falsos positivos son violaciones de reglas que se informan erróneamente cuando el código realmente sigue la regla. Por ejemplo, si la regla dice que tiene un recurso no cerrado (como una conexión JDBC), cuando en realidad la conexión está cerrada, esto es un falso positivo. Si encuentra un problema como este en una regla que realmente desea seguir, la limpieza de primavera es un buen momento para informarlo finalmente a su proveedor.
Tenga en cuenta que si va por este camino, debe estar seguro de que está viendo un falso positivo real, en lugar de simplemente una regla que no le gusta. Los desarrolladores suelen llamar a un mensaje un "falso positivo" porque no les gusta la regla, o no sienten que se aplique en este caso. Dichos mensajes no son falsos positivos y su proveedor no podrá ayudarlo en estos casos.
Sin embargo, si puede reducir un caso de prueba simple que muestra cómo una regla en particular está recibiendo un mensaje falso, debería encontrar que la mayoría de los proveedores son muy útiles para solucionar el problema.
Otra forma de reducir el factor de ruido es personalizar los parámetros de las reglas. Por ejemplo, suponga que su equipo está desarrollando Android y está comprobando una regla de Android que dice "Asegúrese de que los widgets no se actualicen con demasiada frecuencia".
Con la configuración predeterminada, esta regla identifica el código que configura un widget para que se actualice más de 4 veces al día. Lo hace marcando el código que establece el elemento [android: updatePeriodMillis] en la etiqueta [appwidget-provider] en un número menor que 216,00,000.
Suponga que obtener información actualizada es fundamental para su aplicación, por lo que está dispuesto a sacrificar parte del consumo de batería por actualizaciones más frecuentes. En este caso, es posible que desee recibir una advertencia solo si las actualizaciones se realizan más de 8 veces al día. Para lograr esto, simplemente puede actualizar el parámetro de la regla “Tiempo máximo de actualización máximo en milisegundos” de 21,600,000 ms (6 horas) a 10,800,000 ms (3 horas).
Como se menciona en el consejo n. ° 2, si la regla no tiene los parámetros que necesita, puede escribir uno nuevo que sí los tenga, o hacer que su proveedor (o un consultor) escriba una regla personalizada para usted.
¿Está cansado de recordar que Security 123 es equivalente a su directriz ACME 3.1? ¿Que tanto Performance 987 como Performance 567 están relacionados con su directriz ACME 5.6? ¿Que a pesar de que su herramienta dice que Threads 123 es de gravedad 4, su organización considera que las violaciones de esa regla son un defecto muy severo?
Si es así, la limpieza de primavera es un buen momento para mapear el conjunto de reglas de análisis estático de su proveedor para que coincida con las distintas políticas definidas por su equipo y / u organización. La mayoría de las herramientas de análisis estático le permiten personalizar la gravedad de las reglas, los ID y los nombres, así como crear nuevas categorías de reglas, para que las reglas implementadas coincidan con precisión con el contenido de su propio documento de política de codificación.
Si su organización realiza un análisis estático como parte de un esfuerzo de cumplimiento, esto hará que sus informes sean mucho más fáciles.
Cada equipo tiene una política, esté o no definida formalmente. También puede codificar el proceso y hacerlo oficial. Después de todo, es mucho más fácil identificar y diagnosticar problemas con una política formalizada que con una no escrita.
Idealmente, desea que su póliza tenga una correlación directa con los problemas que está experimentando actualmente (y / o comprometido a prevenir). De esta manera, hay una buena razón detrás tanto de la política general como de las formas específicas en que se implementa.
Con estos objetivos en mente, la política debe aclarar:
Una vez que haya limpiado el desorden y esté en el punto en el que el equipo está acostumbrado a realizar análisis estáticos, se informan pocos problemas y esos problemas informados se limpian rápidamente, puede dar el siguiente paso y expandir el alcance de la comprobación.
Una forma de expandir el alcance de la verificación es agregar más reglas que son críticas para sus proyectos y objetivos. Para concentrarse en qué reglas agregar, considere:
Otra forma de aumentar el alcance de la verificación es verificar código adicional. Si inicialmente configuró su herramienta de análisis estático para omitir archivos heredados (por ejemplo, omitir los archivos que no se agregaron o modificaron después de la fecha de "corte" cuando comenzó el análisis estático), es posible que desee considerar retroceder esa fecha de corte o eliminar todo junto.
Cuanto más pueda automatizar el proceso de análisis estático, menos será una carga para los desarrolladores y los distraerá de las tareas más desafiantes que realmente disfrutan. Además, la automatización adicional lo ayudará a lograr resultados consistentes en todo el equipo y la organización.
Muchas organizaciones siguen un proceso automatizado de varios niveles. Cada día, a medida que el desarrollador trabaja en el código en el IDE, puede ejecutar análisis a pedido o configurar un análisis automatizado para que se ejecute continuamente en segundo plano (como lo hace el corrector ortográfico). Los desarrolladores limpian estas infracciones antes de agregar código nuevo o modificado al control de código fuente.
Luego, un proceso basado en servidor verifica dos veces que el código base verificado esté limpio. Este análisis se puede ejecutar como parte de una integración continua, todas las noches, etc. para asegurarse de que nada se escape. Con un proceso basado en servidor de este tipo, es importante evitar el antiguo paradigma de enviar correo electrónico a los desarrolladores. Parte de un flujo de trabajo eficaz consiste en distribuir los mensajes de error a la misma interfaz de usuario donde el desarrollador escribe el código. El correo electrónico obliga a pasos adicionales, lo que lleva a infracciones omitidas, pérdida de tiempo para encontrar la línea adecuada en el archivo y más resentimiento por parte de los codificadores que sienten que están haciendo algo más fuera de su proceso habitual.
Para optimizar aún más el flujo de trabajo a través de la automatización, considere:
Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.
