No desarrollamos software. ¿Necesitamos seguridad del código igualmente?
La pregunta más frecuente de las pymes, respondida con honestidad: quien solo usa software que otros operan no tiene nada que escanear. Quien aloja por su cuenta aplicaciones compradas tiene dependencias y configuraciones que envejecen. Y quien tiene scripts, integraciones y pequeñas herramientas en un repositorio lleva tiempo desarrollando, aunque no lo llame así.
Una pregunta legítima
Surge en casi toda primera conversación: fabricamos máquinas, transportamos mercancías, somos un despacho. Compramos software, no lo escribimos. ¿Para qué seguridad del código? La pregunta merece una respuesta precisa, no una respuesta comercial. Nuestra página sobre seguridad del código da la versión corta. Aquí va la larga, en tres niveles, porque la verdad depende de lo que realmente corre en la empresa, no de si se ve a sí misma como casa de software.
Nivel uno: todo corre en terceros
Si cada aplicación de la empresa es un servicio que opera un proveedor, contabilidad, correo, CRM y archivos desde la nube, sin que exista en ningún sitio un servidor o un repositorio propio, la respuesta es sencillamente no. No hay código que podamos conectar, y no vamos a inventarlo. La seguridad de esos servicios recae en sus proveedores, y los riesgos de la empresa están en otro lugar: en credenciales que ya circulan, en cuentas que se siguen usando tras una filtración.
Para ese caso, nuestra monitorización de la dark web es la puerta de entrada adecuada, y lo decimos en la conversación antes de redactar una oferta. Un análisis de código para una empresa sin código sería facturación sin utilidad.
Nivel dos: software comprado en servidores propios
El caso más frecuente en las pymes es otro. El ERP corre en el servidor de la empresa. El sistema de gestión de almacén se implantó hace seis años y desde entonces se ha adaptado dos veces. La tienda online es un producto estándar con algunas extensiones. Nadie de la casa ha escrito una línea de nada de eso, y sin embargo cada uno de esos sistemas se compone de piezas que envejecen: bibliotecas de código abierto de las que se conocen fallos, y configuraciones con valores por defecto que ya nadie revisa.
Justo esa es la parte del escaneo que funciona sin desarrollo propio. El repaso completo contrasta todas las dependencias con las vulnerabilidades conocidas y comprueba la configuración en busca de valores por defecto inseguros. Que la aplicación se haya comprado o escrito no cambia nada para la biblioteca que lleva dentro. Y según el artículo 30 del BSIG, operar sistemas comprados también cuenta como mantenimiento cuyas vulnerabilidades hay que gestionar; qué evidencias genera eso está en nuestro artículo sobre cómo demostrar la conformidad NIS2 en el día a día.
Nivel tres: el código que nadie llama código
Casi toda empresa que dice no desarrollar tiene un repositorio en algún sitio. Dentro: el script que por la noche empuja las exportaciones a contabilidad. La integración entre tienda y almacén que construyó un antiguo compañero. La herramienta interna con la que ventas genera ofertas. Unas cuantas automatizaciones, un conector, una extensión para el ERP. Eso es desarrollo, aunque nunca se haya llamado así.
Y esas piezas tienen una propiedad que las hace más peligrosas que el propio ERP: rara vez se escribieron pensando en la seguridad. Por experiencia, justo ahí están las credenciales escritas en el código, porque el script solo corre internamente, y las entradas sin comprobar, porque solo lo usa un compañero. El control inmediato encuentra ambas cosas en cuanto están en un repositorio conectado. Por qué un secreto subido una vez tiene que rotarse lo explicamos en nuestro artículo sobre secretos en el código.
Cómo encontrar tu propio nivel
La pregunta que hay que hacerse no es si se emplea a desarrolladores. Es: ¿hay en la empresa un servidor en el que corre una aplicación que instalamos nosotros? ¿Y hay en algún sitio un repositorio, una carpeta de scripts o una herramienta que alguien construyó para nosotros? Dos noes significan nivel uno. Un sí significa que el análisis de código gratuito tiene algo que revisar: conexión, escaneo del inventario, hallazgo priorizado, en tu propio entorno si lo prefieres, sin compromiso. El hallazgo dirá después con honestidad si ha merecido la pena.
Preguntas frecuentes
Solo usamos servicios en la nube. ¿Qué íbamos a escanear?
Nada. Sin repositorio propio y sin aplicación operada por vosotros no hay código que conectar. Para vosotros, la monitorización de la dark web es la puerta de entrada adecuada, porque el riesgo está en las credenciales, no en el código.
Nuestro ERP lo entregó el fabricante. ¿Por qué íbamos a escanearlo?
Porque el fabricante no actualiza las bibliotecas que lleva dentro en vuestro servidor ni comprueba la configuración por vosotros. Esas dos cosas envejecen, y esas dos cosas son justo lo que comprueba el repaso completo, sin que nadie escriba una línea.
Nuestros scripts son solo internos. ¿No es inofensivo?
Interno es el argumento con el que las credenciales acaban en los scripts. Un atacante que ya está en la red lee primero los scripts internos, porque ahí se guardan las llaves de todo lo demás. Si los scripts están en un repositorio, el escaneo los encuentra.