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.