El mayor agujero de seguridad de una empresa no suele estar en su cortafuegos ni en un fallo en su infraestructura. Suele estar en algo mucho más mundano: la confianza ciega en el código de terceros.
El caso de Axios es el ejemplo perfecto. Una librería esencial para hacer peticiones HTTP, con millones de descargas semanales, se convierte de la noche a la mañana en un caballo de Troya. Basta con que un atacante secuestre las credenciales del que la mantiene para inyectar código malicioso en miles de servidores en cuestión de minutos.
Además, si tu sistema de despliegue ejecuta un comando de instalación en ese intervalo, acabas de darle acceso a ese troyano. Y lo peor es que lo has hecho tú mismo.
El síndrome de Diógenes digital
La industria del software, en parte, se ha vuelto muy perezosa. Nos hemos acostumbrado a importar paquetes para resolver problemas que, en algunos casos, se solucionarían con diez líneas de código.
Quieres formatear una fecha o validar un formulario e instalas una dependencia. Ese paquete depende de otros cinco, y esos cinco de otros veinte. Al final, tu proyecto termina con miles de archivos en una carpeta de dependencias escritos por personas que no conoces, que no cobran por mantener ese código y cuya seguridad no puedes controlar.
Básicamente, estás dejando la integridad de tu negocio en manos de desconocidos que programan en sus ratos libres.
La ilusión del control
Es una tontería pagar auditorías si luego, al subir a producción, tu sistema se baja código de internet a ciegas.
Protegerse de esto no es que tengas que comprar software más caro, sino de tener un mínimo de dos dedos de frente en tu arquitectura. Nada de dejar que tu entorno de producción se baje la última versión de una dependencia sin más. Si tu entorno local funcionó con una versión en concreto, a producción tiene que subir exactamente esa. Dejar rangos dinámicos en tu configuración es decirle a tu servidor que confíe a ciegas en cualquier actualización que salga hoy mismo. El archivo de bloqueo debería ser sagrado.
Por otro lado, una simple librería de utilidades no debería tener permisos para ejecutar comandos en tu máquina al instalarse. Por tanto, bloquea la ejecución de scripts de terceros en tus entornos de despliegue.
Pero lo más importante y aún más simple: Si un problema se puede resolver picando unas cuantas líneas de código, sacrifica ese ratito y hazlo tú mismo. No delegues eso a una dependencia externa. Escribe el maldito código. Menos código ajeno significa menos superficie de ataque.
El Open Source es una herramienta indispensable y una gran fuente de innovación, pero no lo veas como “código gratis”. Si vas a meter código de otro en tu servidor, el responsable final de lo que pase eres tú. Si no estás dispuesto a auditarlo, mejor no le abras la puerta.