Fondo
Obviamente, hay múltiples variables involucradas aquí, por lo que no hay una respuesta única para todos. Estas variables incluyen:
Políticas corporativas / corporativas existentes
Cualquier política que implique mandatos de seguridad (como el requisito de ejecutar el AV configurado por la compañía) puede hacer que esta decisión no sea un problema.
Variabilidad del entorno de "producción".
Si se trata de una aplicación que se está implementando en un entorno controlado O en un entorno limitado, es una buena idea duplicar ese entorno de producción para sus bancos de pruebas.
Sin embargo, si esta es una aplicación que se lanzará "en la naturaleza", entonces obviamente no hay forma de probar todas las configuraciones de producción posibles.
Entorno de desarrollo y prueba
Si hay un entorno y un equipo de prueba / control de calidad formales o incluso solo un servidor de compilación, entonces este es probablemente el mejor lugar para imitar el entorno de producción, no las máquinas de los desarrolladores.
Preocupaciones de seguridad
Este es un libro en sí mismo, pero las preocupaciones de seguridad pueden ser mayores que cualquiera de las compensaciones particulares a las máquinas de los desarrolladores. Esto depende de cosas como:
- Sensibilidad de los datos y / o código.
- Conectividad a redes externas / internet
- Media removible
- mucho mucho mas
Rendimiento de la máquina del desarrollador
Lo obvio aquí es el impacto en el rendimiento durante el desarrollo debido al impuesto de CPU y E / S introducido por el antivirus. Lo que no es tan obvio son los posibles impactos: - Tiempo de inactividad asociado con la contracción de un virus / troyano / malware y su posterior eliminación - Impacto en el rendimiento del virus / malware si no hay un software AV presente para detectar y notificar al usuario para que continúen para trabajar con el virus / malware presente.
Si está utilizando máquinas virtuales o tiene una imagen de desarrollo o tiene copias de seguridad periódicas, este potencial de tiempo de inactividad puede ser insignificante. Si el desarrollador va a tener que reinstalar y reconfigurar todo en su máquina desde cero (dependiendo de la gravedad del virus), el tiempo de inactividad podría ser una penalización severa.
Probabilidad de contracción
La probabilidad de que la máquina del desarrollador contraiga un virus / malware es un gran comodín / desconocido. Sin embargo, si está trabajando en una red cerrada y no trae muchos medios externos, el riesgo es obviamente mucho menor que si todas las máquinas están conectadas directamente a Internet.
Si el entorno de desarrollo es Mac OSX o Solaris o Linux, etc., entonces la probabilidad de contracción es mucho menor que en la plataforma Windows.
Además, si la naturaleza del desarrollo en sí aumenta la exposición de las máquinas de los desarrolladores al tráfico potencialmente inseguro, esto aumenta la probabilidad de contracción.
Recomendaciones
Según este estado de las variables anteriores (y probablemente más), existen varias opciones (para aumentar la seguridad, disminuir el orden de rendimiento):
- No hay software AV en absoluto
- Software de AV sin protección en tiempo real, pero análisis de virus programados fuera de horario
- Software AV con protección en tiempo real pero exclusiones en carpetas / tipos de archivos involucrados en el proceso de desarrollo
- Software AV con protección en tiempo real y sin exclusiones.
Obviamente, hay una serie de variaciones en estas cuatro opciones (como las que involucran el uso de máquinas virtuales), pero creo que esto cubre las principales opciones.
Uso personal
Por lo que vale, personalmente uso Symantec Corporate en el trabajo y Avast Free Edition en casa. Tengo habilitada la protección en tiempo real con las únicas exclusiones para mis carpetas / archivos vmdk de Virtual Machine. Realizo parte de mi desarrollo en el host y parte en el invitado. Hago C # y desarrollo nativo de C ++ para la plataforma Windows y encuentro que las penalizaciones de rendimiento son manejables.