El control número dieciséis de los CIS aplica a un grupo específico pero cada vez más amplio: las organizaciones que desarrollan software —o que lo mandan hacer a la medida—. Tu aplicación web, tu portal de clientes, tu sistema interno, esa herramienta que un proveedor construyó para ti: todo ese código es una superficie de ataque, y si tiene fallas de seguridad, es una puerta que tú mismo fabricaste. El Control 16 pide construir la seguridad dentro del software, no intentar remendarla cuando ya está en producción.
Por qué el software propio es un riesgo especial
El software comercial lo revisan y parchan sus fabricantes; el software que tú desarrollas o encargas, lo tienes que asegurar tú. Y las fallas de seguridad en aplicaciones —campos que no validan lo que reciben, errores que exponen datos, controles de acceso mal hechos— son una vía de ataque clásica y devastadora, porque a menudo esas aplicaciones son la cara pública de la empresa o guardan lo más valioso. Una aplicación insegura no es un riesgo abstracto: es un formulario en internet esperando a que alguien meta algo malicioso que el código no supo rechazar.
Qué pide en la práctica
- Seguridad desde el diseño: considerar la seguridad en todo el ciclo de desarrollo, no como un parche final. Es más barato y efectivo construirla que remendarla.
- Prácticas de codificación segura: validar todo lo que entra, manejar bien los errores, no exponer datos, seguir estándares reconocidos.
- Gestionar los componentes de terceros: el software moderno se arma con muchas librerías externas, y una vulnerable te hereda su vulnerabilidad. Hay que saber qué usas y mantenerlo al día.
- Probar la seguridad: revisar el código y ponerlo a prueba antes y durante su vida útil, algo que se cruza con las pruebas de penetración.
El aterrizaje honesto
Si tu empresa no desarrolla software, este control te toca de rebote pero te toca: cuando encargas una aplicación a un tercero, la seguridad de ese código es tu problema aunque no lo escribas tú, y deberías exigirla como parte del encargo. Y si desarrollas, la lección de fondo es que la seguridad remendada al final siempre sale más cara y peor que la construida desde el principio —arreglar una falla en producción cuesta mucho más que evitarla en el diseño—. El software es poder, y como todo poder, viene con la responsabilidad de no convertirlo en la puerta por la que te entran.
Preguntas frecuentes
help Mi empresa no programa, ¿este control me aplica?
Te aplica de forma indirecta si encargas software a la medida a un tercero. La seguridad de ese código sigue siendo tu riesgo, porque es tu aplicación y guarda tus datos, aunque no la escribas tú. Deberías exigir prácticas de desarrollo seguro como parte del encargo y verificarlas. Si no desarrollas ni encargas software, este control es de baja prioridad para ti frente a los fundacionales.
help ¿Por qué es un riesgo el software de terceros dentro de mi aplicación?
Porque las aplicaciones modernas se construyen usando muchas librerías y componentes externos, y si uno de ellos tiene una vulnerabilidad, tu aplicación la hereda. Ha habido incidentes grandes por fallas en componentes muy usados. Por eso hay que saber qué componentes empleas (inventariarlos) y mantenerlos actualizados, igual que el resto del software. Una dependencia vulnerable es una puerta abierta en código que ni siquiera escribiste.
help ¿Es más caro hacer software seguro desde el inicio?
Al contrario a largo plazo. Construir la seguridad desde el diseño cuesta algo de esfuerzo inicial, pero remendar una falla descubierta en producción cuesta mucho más: rehacer trabajo, posibles brechas, daño de reputación. La seguridad integrada en el desarrollo es más barata y efectiva que la añadida al final a las carreras. El ahorro de "no preocuparse por seguridad ahora" se paga con creces después.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →