# Seguridad en Software Empresarial: 10 Practicas que Debes Exigir a tu Proveedor
La mayoria de las empresas que contratan desarrollo de software preguntan sobre plazos, costos y tecnologia. Muy pocas preguntan sobre seguridad antes de firmar el contrato. Y cuando el incidente ocurre —una filtracion de datos, un acceso no autorizado, un ransomware que cifra la base de datos— ya es demasiado tarde para renegociar clausulas.
En México, la Ley Federal de Protección de Datos Personales en Posesion de los Particulares (LFPDPPP) establece responsabilidades claras para las empresas que manejan datos de terceros. Si tu proveedor de software no implementa las medidas de seguridad adecuadas, las consecuencias legales y reputacionales recaen sobre ti.
Este artículo te entrega un checklist práctico de las 10 practicas de seguridad que debes exigir —y verificar— antes y durante cualquier proyecto de desarrollo de software.
---
Tabla de Contenidos
- Por que la seguridad debe estar en el contrato
- OWASP Top 10: el estandar mínimo
- Las 10 practicas obligatorias
- LFPDPPP: lo que implica para tu software
- Penetration testing: cuando y como exigirlo
- Checklist de cumplimiento
- FAQ
---
Por Que la Seguridad Debe Estar en el Contrato
Un proveedor de software puede entregar un sistema funcional, bonito y a tiempo, y que al mismo tiempo sea una vulnerabilidad de seguridad activa. La razon es simple: la seguridad agrega tiempo y costo al desarrollo. Si no se especifica contractualmente, muchos proveedores la omiten para cumplir con plazos y presupuestos.
Las clausulas de seguridad que deben estar en tu contrato incluyen:
- Estandares de desarrollo seguros que el proveedor se compromete a seguir
- Responsabilidad ante incidentes causados por vulnerabilidades del código entregado
- Pruebas de seguridad obligatorias antes de cada entrega a producción
- Derecho a auditoria: la posibilidad de contratar un tercero para revisar el código o la infraestructura
Si tu proveedor se niega a incluir estas clausulas, eso es una senal de alerta significativa.
---
OWASP Top 10: El Estandar Minimo
El Open Web Application Security Project (OWASP) publica periodicamente la lista de los diez riesgos de seguridad mas criticos en aplicaciones web. La edicion mas reciente incluye:
- Control de acceso roto: usuarios que pueden acceder a recursos o funciones que no les corresponden
- Fallos criptograficos: datos sensibles transmitidos o almacenados sin cifrado adecuado
- Inyeccion: SQL injection, command injection y similares
- Diseño inseguro: arquitectura que no considera amenazas desde el diseño
- Mala configuración de seguridad: sistemas con configuraciones por defecto, puertos expuestos o permisos excesivos
- Componentes vulnerables y desactualizados: librerias de terceros con vulnerabilidades conocidas sin parchar
- Fallos de identificacion y autenticación: contrasenas debiles, sesiones sin caducidad, falta de MFA
- Fallos en la integridad del software y los datos: pipelines de CI/CD sin validación de integridad
- Fallos en el registro y monitoreo de seguridad: incidentes que no se detectan porque no hay logs
- Falsificacion de solicitudes del lado del servidor (SSRF): el servidor realiza solicitudes a recursos internos no autorizados
Tu proveedor debe conocer esta lista y ser capaz de explicar como la aborda en su proceso de desarrollo.
---
Las 10 Practicas Obligatorias
1. Modelado de amenazas desde el diseño
La seguridad no se agrega al final del proyecto. Un buen proveedor realiza un ejercicio de modelado de amenazas (threat modeling) en la fase de diseño para identificar puntos de riesgo antes de escribir una sola linea de código.
2. Cifrado en transito y en reposo
Todos los datos sensibles deben estar cifrados. En transito: TLS 1.2 o superior en todas las comunicaciones. En reposo: cifrado de columnas sensibles en base de datos (datos personales, contrasenas con hash bcrypt o Argon2, numeros de tarjeta si aplica con PCI DSS).
3. Autenticacion robusta y control de acceso por roles
El sistema debe implementar autenticación multifactor (MFA) para accesos administrativos y, de preferencia, para todos los usuarios. El control de acceso basado en roles (RBAC) debe garantizar que cada usuario vea y pueda hacer exactamente lo que le corresponde, ni mas ni menos.
4. Gestion segura de secretos
Las contrasenas, claves de API y credenciales de base de datos nunca deben estar en el código fuente (hardcoded). Deben gestionarse mediante un vault de secretos (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) o al menos variables de entorno correctamente gestionadas.
5. Revision de código con enfoque en seguridad (SAST)
El Static Application Security Testing analiza el código fuente en busca de vulnerabilidades antes de que se ejecute. Herramientas como SonarQube, Checkmarx o Semgrep deben integrarse en el pipeline de CI/CD para que ningun código llegue a producción sin pasar esta validación.
6. Análisis de composicion de software (SCA)
El 70-80% del código de una aplicación moderna proviene de librerias de terceros (open source). Las vulnerabilidades en estas dependencias son una de las fuentes de ataque mas comunes. Tu proveedor debe tener un proceso para monitorear y actualizar las dependencias con vulnerabilidades conocidas (CVEs).
7. Pruebas de penetracion periodicas
Un pentest es una simulacion de ataque realizada por profesionales para encontrar vulnerabilidades que las herramientas automaticas no detectan. Se recomienda al menos una vez al ano para sistemas criticos, y obligatoriamente antes del lanzamiento inicial de una aplicación que maneja datos personales o financieros.
8. Gestion de vulnerabilidades con SLA definidos
Cuando se encuentra una vulnerabilidad (por pentest, por reporte de usuario o por monitoreo), debe haber un proceso claro de clasificacion por severidad (critica, alta, media, baja) y un SLA de remediacion: las criticas no deben permanecer abiertas más de 48-72 horas.
9. Logs de auditoria y monitoreo de seguridad
Toda accion critica del sistema debe quedar registrada: quien accedio, que cambio, desde que IP, a que hora. Estos logs deben estar protegidos contra modificacion, centralizados en un SIEM o al menos en un sistema de log management, y conservados por el período que marque la regulacion aplicable.
10. Plan de respuesta a incidentes
Tu proveedor debe entregarte, como parte del proyecto, un plan de respuesta a incidentes que incluya: como se detecta un incidente, quien se notifica (incluyendo autoridades si aplica bajo LFPDPPP), como se contiene, como se remedia y como se documenta para fines legales.
---
LFPDPPP: Lo que Implica para tu Software
La Ley Federal de Protección de Datos Personales en Posesion de los Particulares (LFPDPPP) establece que toda empresa que recopile, use o almacene datos personales de ciudadanos mexicanos debe implementar medidas de seguridad administrativas, fisicas y tecnicas.
En el contexto de software empresarial, esto implica:
- Aviso de privacidad: el sistema debe mostrar y registrar el consentimiento del titular para el tratamiento de sus datos
- Minimo de datos: solo recopilar los datos estrictamente necesarios para la finalidad declarada
- Transferencia de datos: si el sistema comparte datos con terceros (APIs externas, proveedores de nube), debe estar documentado y contar con contrato de confidencialidad
- Derechos ARCO: el sistema debe permitir al titular acceder, rectificar, cancelar u oponerse al tratamiento de sus datos
- Notificacion de brechas: en caso de incidente de seguridad que exponga datos personales, la empresa tiene obligacion de notificar al INAI y a los afectados
El incumplimiento puede derivar en multas de hasta 320,000 días de salario mínimo vigente, mas las responsabilidades civiles correspondientes.
---
Penetration Testing: Cuando y Como Exigirlo
Un pentest profesional debe realizarse:
- Antes del lanzamiento de cualquier aplicación que maneje datos personales, financieros o criticos de negocio
- Despues de cambios mayores en la arquitectura o en modulos criticos
- Anualmente como practica de mantenimiento de seguridad
- Ante un incidente de seguridad para identificar el vector de ataque y vulnerabilidades residuales
Al contratar un pentest, exige:
- Metodologia documentada (OWASP WSTG, PTES o similar)
- Alcance claramente definido (black box, grey box o white box)
- Reporte ejecutivo para la dirección y reporte técnico para el equipo de desarrollo
- Sesion de hallazgos con propuestas de remediacion
- Pentest de verificación (retest) incluido en el alcance
---
Checklist de Cumplimiento
Antes de firmar con un proveedor de software, verifica:
- [ ] El proveedor conoce y aplica OWASP Top 10
- [ ] Tienen proceso de SAST integrado en CI/CD
- [ ] Realizan análisis de dependencias (SCA) periodicamente
- [ ] Usan gestion de secretos (no hardcoding de credenciales)
- [ ] Implementan TLS en todas las comunicaciones
- [ ] Ofrecen autenticación MFA para accesos criticos
- [ ] Tienen SLA de remediacion de vulnerabilidades documentado
- [ ] Incluyen logs de auditoria en el sistema entregado
- [ ] Contemplan cumplimiento LFPDPPP en el diseño
- [ ] Pueden presentar resultados de pentest de proyectos anteriores (bajo NDA)
---
FAQ
¿Cuanto cuesta incluir estas practicas de seguridad en un proyecto de software?
La seguridad bien integrada desde el diseño agrega entre un 15% y un 25% al costo de desarrollo. Pero el costo de remediar vulnerabilidades en producción —sin contar el impacto de un incidente real— suele ser 10 a 100 veces mayor. Es una inversion, no un gasto.
¿Que diferencia hay entre un scan de vulnerabilidades y un pentest?
Un scan automático encuentra vulnerabilidades conocidas mediante herramientas. Un pentest es realizado por un profesional que usa los hallazgos del scan como punto de partida, pero además intenta encadenar vulnerabilidades, buscar logica de negocio insegura y explotar vectores que las herramientas no detectan. Son complementarios, no sustitutos.
¿Debo exigir estas practicas también a proveedores de software SaaS?
Si. Cuando contratas un SaaS que procesara datos de tu empresa o de tus clientes, debes solicitar el reporte SOC 2 Type II del proveedor, su politica de seguridad de la información y su proceso de notificación de incidentes. La responsabilidad ante tus clientes no se transfiere por usar un SaaS.
¿La certificación ISO 27001 de un proveedor es suficiente garantía?
La ISO 27001 certifica que el proveedor tiene un Sistema de Gestion de Seguridad de la Información (SGSI) implementado. Es una buena senal, pero no garantiza que el código que producen sea seguro. Exige además evidencia de SAST, gestion de vulnerabilidades y resultados de pentests.
---
Siguiente Paso
En iTechDev desarrollamos software empresarial con practicas de seguridad integradas desde la primera linea de código. Somos partners de Microsoft y AWS con más de 8 años de experiencia y 100+ proyectos entregados a empresas en México.
Si quieres evaluar la seguridad de tu software actual o iniciar un proyecto con las practicas correctas desde el principio, agenda una sesion de evaluación sin costo.
Habla con nuestro equipo: meet.itechdev.com.mx/itechdev/consulta