El costo de la inseguridad siempre lo pagó el mismo lado de la mesa
Durante décadas, el ciclo ha sido el mismo: un fabricante lanza software con decisiones de diseño inseguras —contraseñas por defecto, ausencia de autenticación multifactor, memoria sin protección, funciones administrativas expuestas sin costo adicional para asegurarlas— y el cliente que lo compra hereda el riesgo. El equipo de seguridad del comprador es quien parchea de urgencia, quien monitorea señales de compromiso, quien responde al incidente y quien explica a la junta directiva por qué una vulnerabilidad conocida desde hace meses terminó en una intrusión. El fabricante, mientras tanto, sigue vendiendo.
La Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) formalizó esta crítica en su iniciativa Secure by Design: la industria del software ha tenido, durante años, “el camino de menor resistencia” para lanzar productos rápido y trasladar el costo de la inseguridad al cliente, en lugar de invertir ese costo en el diseño. CISA lo plantea sin ambigüedad —citando también el planteamiento de la Estrategia Nacional de Ciberseguridad de EE. UU.— como un problema de incentivos mal alineados: el riesgo cibernético ha recaído desproporcionadamente sobre quienes menos capacidad tienen para gestionarlo (empresas pequeñas, hospitales, gobiernos locales) en vez de sobre los fabricantes de tecnología, que están mejor posicionados para prevenirlo desde el origen.
Para los equipos de seguridad y las áreas de compras en Colombia y la región, esto no es un debate regulatorio lejano. Es una herramienta práctica: un lenguaje común, ya validado por una agencia gubernamental y adoptado por decenas de fabricantes, que un comprador puede usar hoy mismo para exigir garantías concretas antes de firmar un contrato de software.
Qué es realmente Secure by Design y qué compromisos firman los fabricantes
Secure by Design es la iniciativa de CISA que establece tres principios rectores para quienes construyen software empresarial —on-premise, SaaS o servicios en la nube—:
- Tomar propiedad sobre los resultados de seguridad del cliente: el fabricante es responsable de las consecuencias de seguridad derivadas de sus decisiones de diseño, no solo el cliente que sufre el incidente.
- Practicar transparencia radical y rendición de cuentas: publicar registros CVE completos y a tiempo, mantener un Software Bill of Materials (SBOM) preciso y comunicar con honestidad el estado de seguridad de los productos.
- Construir estructura organizacional y liderazgo que traten la seguridad como un objetivo de negocio crítico, no como una función técnica aislada.
Sobre esos tres principios, CISA construyó el Secure by Design Pledge, un compromiso voluntario —no vinculante legalmente— que ya han firmado decenas de fabricantes de software empresarial, incluyendo nombres de peso en el mercado de infraestructura y seguridad. El pledge se organiza en siete metas concretas hacia las que los firmantes se comprometen a mostrar progreso medible en el plazo de un año, y a documentar públicamente cómo lo lograron:
- Aumentar el uso de autenticación multifactor (MFA) en sus productos, incluyendo formas resistentes a phishing como passkeys, sin costo adicional para el cliente.
- Reducir las contraseñas por defecto, es decir, contraseñas universales presentes de fábrica en múltiples instalaciones del mismo producto, un vector que sigue habilitando ataques masivos y automatizados.
- Reducir de forma medible la prevalencia de clases enteras de vulnerabilidad —no parchear una falla puntual, sino eliminar la clase de defecto que la genera (por ejemplo, mediante lenguajes de memoria segura o consultas parametrizadas que hacen estructuralmente imposible la inyección SQL).
- Aumentar la instalación de parches de seguridad por parte de los clientes, facilitando actualizaciones automáticas y reduciendo la fricción operativa de aplicar un parche.
- Publicar una política de divulgación de vulnerabilidades (VDP) que autorice a investigadores de seguridad externos a reportar hallazgos bajo un canal formal.
- Enriquecer los reportes de vulnerabilidades con más datos, incluyendo campos correctos de CWE (Common Weakness Enumeration) y CPE (Common Platform Enumeration) en cada registro CVE.
- Aumentar de forma medible la capacidad del cliente para reunir evidencia de intrusiones que afecten los productos del fabricante, es decir, poner a disposición logs de seguridad utilizables.
El punto que suele pasarse por alto: este pledge no pide “más seguridad” en abstracto. Pide que ciertas categorías de falla —las que llevan años apareciendo en los mismos reportes de explotación activa— dejen de ser posibles por diseño, y que las funciones mínimas para detectar un compromiso (MFA, SSO, logging) dejen de venderse como upgrade premium.
Secure by Demand: la contraparte dirigida a quien compra, no a quien fabrica
Si Secure by Design le habla al fabricante, Secure by Demand —la guía que CISA publicó junto con el FBI en agosto de 2024— le habla directamente al comprador. Su premisa es simple y es la que da nombre a este artículo: los fabricantes de software construyen lo que el mercado les exige. Si los compradores nunca exigen seguridad explícitamente durante el proceso de adquisición, la seguridad seguirá siendo una característica opcional que compite en la hoja de ruta contra funcionalidades que sí generan ingresos inmediatos.
La guía identifica un vacío específico en cómo las organizaciones hacen due diligence de sus proveedores: la mayoría de los procesos de compra evalúan la seguridad empresarial del fabricante (si cumple SOC 2, ISO 27001, si tiene un SOC propio) pero casi ninguno evalúa la seguridad del producto en sí —es decir, si el software que están a punto de comprar fue diseñado para minimizar defectos explotables. CISA es explícita en que existen muchos estándares de cumplimiento enfocados en seguridad empresarial, pero relativamente pocos enfocados en seguridad de producto. Esa es exactamente la brecha que Secure by Demand busca cerrar.
La guía propone integrar estas preguntas en tres momentos del ciclo de adquisición:
- Antes de la compra: plantear preguntas al fabricante candidato para entender su enfoque de seguridad de producto.
- Durante la negociación del contrato: incorporar los requisitos de seguridad de producto como cláusulas contractuales, no como buenas intenciones verbales.
- Después de la compra: evaluar de forma continua los resultados de seguridad del fabricante, no solo en la auditoría inicial.
El checklist de procurement: qué exigir antes de firmar
A partir de las preguntas que CISA y el FBI documentan en la guía Secure by Demand, un checklist operativo para el área de compras y el equipo de seguridad debería cubrir, como mínimo, estos frentes:
Autenticación segura por defecto
- ¿El producto ofrece single sign-on (SSO) basado en estándares sin costo adicional?
- Si el fabricante administra la autenticación, ¿habilita MFA —o formas resistentes a phishing como passkeys— por defecto y sin cargo extra?
- ¿El fabricante ha eliminado las contraseñas por defecto en sus productos? Si no, ¿tiene un plan documentado para reducirlas?
Historial de CVEs y capacidad de respuesta
- ¿El fabricante registra CVEs de forma oportuna y correcta, con campos CWE y CPE completos en cada registro?
- ¿Opera una política pública de divulgación de vulnerabilidades (VDP) que autorice pruebas de investigadores externos?
- ¿Ha firmado el Secure by Design Pledge de CISA? ¿Qué reportes de avance ha publicado sobre esos compromisos?
Logs de seguridad sin costo adicional
- ¿La versión base del producto incluye logs de seguridad, o son un módulo separado que hay que comprar aparte?
- Para proveedores de nube o SaaS: ¿retiene y pone a disposición del cliente logs de seguridad durante al menos varios meses, sin cargo adicional?
- ¿Esos logs cubren cambios de configuración, eventos de identidad (inicio de sesión, emisión de tokens), flujos de red y acceso a datos relevantes del negocio?
Eliminación de clases de vulnerabilidad
- ¿Qué clases de vulnerabilidad ha abordado el fabricante de forma sistemática en sus productos (inyección SQL, XSS, corrupción de memoria)?
- Para las que aún no ha resuelto, ¿existe una hoja de ruta pública —por ejemplo, un plan de migración a lenguajes de memoria segura— que muestre el camino y el plazo?
Cadena de suministro de software
- ¿El fabricante genera un SBOM en formato estándar y legible por máquina, disponible para el cliente?
- ¿Ese SBOM enumera todas las dependencias de terceros, incluyendo componentes open source?
- ¿Cómo evalúa la seguridad de los componentes open source que incorpora? ¿Tiene un proceso formal, como una oficina de programa open source (OSPO)?
Facilidad de parchar
- ¿El fabricante facilita la instalación de parches de seguridad? ¿Ofrece soporte de parches de forma amplia y actualizaciones automáticas habilitables?
Ninguna de estas preguntas exige acceso a información confidencial ni auditorías forenses del proveedor. Son preguntas de debida diligencia estándar, exactamente igual de razonables que pedir el último informe SOC 2 —solo que dirigidas al producto en lugar de a la operación interna del fabricante.
Por qué esto es más eficiente que reforzar solo los controles internos
Un equipo de seguridad puede invertir años reforzando su propio perímetro, su gestión de identidades y su capacidad de detección, y seguir siendo vulnerable si el software que compra viene con contraseñas universales de fábrica o sin capacidad de generar logs de auditoría. Los controles internos compensan el riesgo que introduce un tercero; no lo eliminan en el origen.
Secure by Demand plantea una palanca distinta: si suficientes compradores —especialmente compradores grandes, con poder de negociación real, como gobiernos, entidades financieras y grandes empresas— exigen las mismas garantías de forma consistente, el incentivo comercial del fabricante cambia. Dejar de tener MFA gratuita, o seguir vendiendo logging como add-on premium, empieza a costar contratos perdidos, no solo reputación. Eso mueve la aguja a nivel de toda la industria de una forma que ninguna auditoría individual, por rigurosa que sea, puede lograr por sí sola.
Para el mercado colombiano y latinoamericano, esto tiene una implicación directa: no hace falta esperar a que exista una regulación local equivalente para empezar a exigir esto. El lenguaje de Secure by Demand ya está disponible, ya fue validado por una agencia técnica con visibilidad sobre patrones reales de explotación, y puede incorporarse hoy a pliegos de licitación, RFPs y cláusulas contractuales sin necesidad de reinventar criterios desde cero. Las entidades públicas y las empresas reguladas —banca, energía, salud— tienen aquí una oportunidad concreta de anticiparse antes de que la exigencia se vuelva norma sectorial.
La postura de CIBER-TEC: seguridad debe sentarse en la mesa de compras, no solo auditar después
El error más costoso que vemos en procesos de adquisición de tecnología en la región es estructural: el equipo de seguridad entra al final del proceso, cuando el contrato ya está negociado y el presupuesto ya fue aprobado, para hacer una revisión que en la práctica solo puede documentar riesgos que ya no se pueden evitar. Para entonces, renegociar cláusulas de seguridad —logs incluidos, MFA sin costo, SBOM disponible— tiene una fricción política y contractual mucho mayor que haberlas incluido desde el RFP inicial.
La recomendación operativa es directa: el equipo de seguridad debe tener asiento formal en el comité de compras de tecnología, con autoridad para incluir el checklist de Secure by Demand como criterio de evaluación —no como nota al pie— desde la primera solicitud de propuesta. Eso significa puntuar a los proveedores por tener VDP público, por su historial real de CVEs, por ofrecer MFA sin cargo adicional y por mostrar una hoja de ruta de eliminación de clases de vulnerabilidad, con el mismo peso que hoy se le da al precio o al tiempo de implementación.
Un proveedor que no puede responder estas preguntas, o que las responde con evasivas, ya está comunicando algo relevante sobre cómo va a comportarse el día que aparezca la primera vulnerabilidad crítica en su producto. Esa señal vale más, en la etapa de compra, que cualquier cláusula de indemnización redactada después del incidente.