Ciberseguridad para empresas de software: seguridad real, no checks de certificación

Un reporte SOC 2 no detiene un breach. Una pila de documentos de política no detiene un breach. La certificación ISO 27001 no detiene un breach. Son útiles para ventas, útiles para procurement, a veces útiles para el seguro. Ninguno es seguridad.

Las empresas que sufren breach en 2026 tienen certificaciones. También tienen endpoints de API expuestos con autorización rota, secretos JWT en archivos de environment commiteados a repos públicos, buckets S3 con políticas demasiado permisivas, y dependencias desactualizadas con RCEs conocidos. El pentester que encuentra estas cosas las encuentra en 4 horas. El auditor de compliance no las busca en absoluto.

Compliance es un outcome de papeleo. Seguridad es un outcome de ingeniería. Están relacionados pero no son lo mismo. Así hacemos el outcome de ingeniería.

El problema del teatro de compliance

La mayoría de las empresas de software con menos de 100 ingenieros no tiene un programa de seguridad. Tienen:

• Un reporte SOC 2 obtenido vía Vanta o Drata.
• Un folder de políticas en Notion.
• Un inbox “[email protected]” que nadie mira.
• Quizá Snyk en su repo principal.
• Un plan vago de “hacer un pentest antes de la próxima renovación”.

Esto está bien para vender a clientes mid-market. No está bien para mantener seguros los datos de los clientes. Hemos trabajado con empresas que pasaron auditorías SOC 2 Type II y tenían vulnerabilidades críticas que encontramos en la primera semana de un engagement de seguridad.

Los frameworks de compliance no son el problema. Son sensatos a nivel de diseño. El problema es que las empresas tratan la certificación como la meta, no el trabajo de ingeniería detrás de ella. Optimizan por “pasar la auditoría”, lo cual tiene casi cero overlap con “ser difícil de breachear”.

Cómo se ve la seguridad real es una práctica continua: el código se revisa por seguridad antes del merge, la infraestructura está hardenizada por default, los secretos se rotan automáticamente, las dependencias de terceros se escanean y parchan, y alguien está realmente intentando romper el sistema desde afuera de forma recurrente.

Pentesting: la realidad

Aclaremos qué es realmente penetration testing, porque la mayoría de las empresas que dicen haber tenido un pentest realmente no lo tuvieron.

Un pentest es un esfuerzo manual de un humano hábil para entrar a tu sistema usando las mismas técnicas que usaría un atacante. No es correr Burp Suite Scanner toda la noche y mandarte el CSV por email. No es Nessus exportando un reporte de CVEs en tus dependencias. Esos son scans de vulnerabilidad. Son útiles como inputs, pero no son pentests.

Un pentester real hace lo siguiente:

• Mapea tu superficie de ataque (APIs públicas, servicios expuestos, integraciones de terceros, roles de usuario).
• Prueba autenticación y manejo de sesiones (replay de tokens, manipulación de JWT, flujos de password reset).
• Prueba autorización (IDOR, escalación de privilegios, aislamiento de tenants en sistemas multi-tenant).
• Prueba lógica de negocio (race conditions en pagos, abuso de flujos de refund, workflows explotables).
• Prueba injection (SQL, NoSQL, command, template, SSRF).
• Revisa manejo de secretos y leakage de información (mensajes de error, endpoints de debug, source maps en producción).
• Escribe proof-of-concept exploits para cada hallazgo. No teórico “esto podría ser explotable” — PoCs funcionando.

El entregable no es una lista de CVEs. Es un reporte con hallazgos rankeados por severidad, cada uno con: pasos de reproducción, evidencia (screenshots, capturas de request/response, scripts), impacto de negocio, y guía de remediación. Hallazgos sin PoCs funcionando son ruido.

Corremos dos tipos de pentest:

• Black-box (nos dan una URL y una cuenta de test, nada más). Simula un atacante externo. Mejor para entender lo que ve un adversario real.
• Grey-box (nos dan diagramas de arquitectura, acceso al código fuente, documentación interna). Simula un atacante sofisticado con algo de información insider. Atrapa más, más rápido.

Para la mayoría de clientes, grey-box es mejor valor. El punto del pentesting es encontrar y arreglar vulnerabilidades, no probar que puedes esconderlas.

Precio: desde $8K para un engagement focalizado de 1 semana sobre una aplicación específica, hasta $25K para un assessment multi-semana cubriendo app + infraestructura cloud + red interna.

Hardening de cloud: las cosas aburridas que importan

La mayoría de los breaches no vienen de zero-days ingeniosos. Vienen de buckets S3 que nadie cerró, usuarios IAM con acceso admin que dejaron la empresa hace dos años, y snapshots de base de datos que “temporalmente” se volvieron públicos.

Nuestra pasada estándar de hardening de AWS cubre:

IAM e identidad:

• Root account bloqueada detrás de hardware MFA, nunca usada.
• Todos los usuarios humanos vía SSO (Okta, Google Workspace, AWS IAM Identity Center).
• Auth service-a-service vía roles IAM, nunca access keys long-lived.
• Políticas de least-privilege. Corremos IAM Access Analyzer y removemos cualquier cosa no usada activamente en 90 días.
• Sin acciones * en políticas a menos que haya una razón explícita documentada.

Manejo de secretos:

• AWS Secrets Manager o Parameter Store (encriptado). Nunca archivos .env en S3. Nunca secretos en environment variables en texto plano.
• Rotación automática para credenciales de base de datos y tokens API.
• Secretos sensibles (signing keys, encryption masters) en AWS KMS con políticas explícitas.

Segmentación de red:

• Subnets privadas para bases de datos y servicios internos. Sin RDS o Elasticache con endpoints públicos.
• Security groups cerrados a rangos de fuente específicos, no 0.0.0.0/0.
• VPC endpoints para S3, DynamoDB, ECR para mantener el tráfico fuera del internet público.

Protección de edge:

• WAF al frente de APIs públicas (AWS WAF o Cloudflare). Rate limiting en endpoints de auth.
• Protección DDoS (Shield Standard como mínimo, Advanced para targets de alto valor).
• TLS 1.3 forzado, ciphers débiles deshabilitados.

Logging y detección:

• CloudTrail habilitado en todas las cuentas, logs en un bucket S3 write-once en una cuenta de auditoría separada.
• GuardDuty habilitado en todas las regiones que usas.
• VPC Flow Logs en cuentas críticas.
• Alertas sobre uso de root account, cambios en políticas IAM, cambios en security groups a puertos de alto riesgo.

El output de una pasada de hardening es un environment remediado más un runbook. El runbook es la parte que la mayoría de firmas de seguridad no entrega — tu equipo tiene que poder mantener el sistema en ese estado, no solo visitarlo una vez.

Threat modeling en tiempo de diseño

El hallazgo de seguridad más barato es el que se atrapa en diseño, antes de escribir código.

Threat modeling es una conversación estructurada de 60-90 minutos con los ingenieros construyendo un feature nuevo. Usamos STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) como checklist, recorriendo:

• ¿Qué datos fluyen por el feature nuevo?
• ¿Qué fronteras de confianza cruza (user → API, service → service, app → tercero)?
• ¿Qué autenticación y autorización aplican en cada frontera?
• ¿Cuál es el radio de impacto si un solo componente se compromete?
• ¿Qué logging prueba abuso después del hecho?

Una sesión de threat modeling de 90 minutos al inicio de un feature típicamente previene 2-5 vulnerabilidades que se habrían enviado a producción. La matemática es abrumadoramente favorable.

Para clientes en retainer, corremos sesiones de threat modeling en cada feature nuevo significativo. Para engagements one-off, lo hacemos sobre las partes de mayor riesgo del sistema (auth, billing, multi-tenancy, cualquier cosa tocando PII de clientes).

Revisión de código segura: SAST + manual, en CI

Las herramientas de análisis estático (SAST) atrapan una clase específica de vulnerabilidades: patrones conocidos de código inseguro. Se pierden cualquier cosa que requiera entender contexto de negocio, pero son baratas y atrapan bugs reales.

Nuestro stack SAST estándar:

• Semgrep para reglas custom y los rule packs de OWASP / CWE. Corre en cada PR.
• GitHub Advanced Security si el cliente ya está en GitHub Enterprise. Mismo vendor, menos dolores de cabeza de integración.
• Snyk para vulnerabilidades de dependencias (SCA). Configurado para fallar builds en high/critical con un proceso de excepción documentado.
• TruffleHog o gitleaks para secretos commiteados. Configurado pre-receive en el repo si quieres ser estricto.

Las herramientas SAST sin revisión manual se vuelven ruido. La proporción signal-to-noise de una configuración bien afinada de Semgrep está alrededor de 1:3 — triagear 3 falsos positivos por cada hallazgo real. Eso es bastante bueno. Una configuración sin afinar es más como 1:30 y los ingenieros empiezan a ignorar las alertas por completo.

Para codebases de alto valor, hacemos una revisión manual trimestral del código nuevo. Miramos:

• Nueva lógica de autenticación / autorización.
• Cualquier código que maneje input proveído por el usuario que llegue a una base de datos, filesystem, o API externa.
• Cualquier código que maneje dinero o PII.
• Código de cripto (por favor, no escribas tu propia cripto).

La revisión toma 1-2 engineer-days por trimestre para la mayoría de clientes. Barato relativo al costo de un breach.

Herramientas que sí usamos

Stack de trabajo real, no una lista de marketing:

Pentest: Burp Suite Pro, OWASP ZAP, Nuclei, ffuf, sqlmap, scripts custom en Python para abuso de lógica de negocio, Caido para engagements más nuevos.

Seguridad cloud: AWS Security Hub, ScoutSuite, Prowler, CloudSploit. Para GCP, Cloud Security Command Center.

SAST/SCA: Semgrep, GitHub Advanced Security, Snyk, Dependabot, OSV-Scanner.

Secretos: TruffleHog, gitleaks, AWS Secrets Manager, HashiCorp Vault para clientes con necesidades más estrictas.

WAF/edge: Cloudflare WAF (nuestro default), AWS WAF para shops AWS-native.

Monitoreo/detección: GuardDuty, CloudTrail + Athena para queries, Datadog Security Monitoring para clientes más ricos, Wazuh open-source para los cost-conscious.

Container scanning: Trivy, Grype, ECR scanning habilitado.

Las herramientas están commoditizadas. El juicio sobre qué hallazgos importan, y el trabajo manual de probar que son reales, no.

Lo que cubre un retainer de seguridad

Para clientes que quieren un programa continuo en vez de engagements one-off, corremos un retainer de seguridad de $4,000/mes:

• Monitoreo y triaje continuos de SAST/SCA.
• Pentest externo trimestral (scope focalizado).
• Review mensual de config de cloud (drift desde baseline hardenizado).
• Threat modeling en features nuevos.
• On-call de respuesta a incidentes.
• Help desk para las preguntas de seguridad del equipo de ingeniería.
• Soporte para customer security questionnaires (te sorprendería cuánto tiempo de ingeniería se comen estos).

Para industrias reguladas (healthcare, fintech) o superficies de mayor riesgo, los retainers escalan desde ahí. Dimensionamos a riesgo, no a vanidad.

Lo que no hacemos

• No vendemos certificaciones. Te ayudamos a pasar la auditoría, pero te decimos al frente que la auditoría no es la meta de seguridad.
• No escribimos documentos de estrategia de seguridad de 200 páginas que nadie lee.
• No hacemos ventas basadas en FUD. Si tu perfil de riesgo no necesita un retainer de $10K/mes, te lo decimos. Un engagement focalizado de $8K una vez al año puede ser suficiente.
• No nos promocionamos como ex-NSA, ex-FBI, ex-cualquier-cosa. Nuestros pentesters son ingenieros activos con 8-12 años de experiencia en seguridad ofensiva que también pueden arreglar lo que encuentran.

Resumen de precios

• Pentest: desde $8K para web app focalizado, $15-25K para app + cloud + red.
• Engagement de hardening cloud: $10-20K, 3-4 semanas, incluye handoff de runbook.
• Sesión de threat modeling: $1.5K por feature/sistema, workshop de medio día.
• Retainer de seguridad: desde $4,000/mes. Escala por superficie y perfil de riesgo.

Conclusión

Los certificados de compliance son herramientas de venta. No son seguridad. Las empresas que no sufren breach en 2026 son las que hacen el trabajo de ingeniería poco glamoroso: pentestear la aplicación como lo haría un atacante, hardenizar la config de cloud, automatizar el patching de dependencias, hacer threat model de features nuevos, y revisar código con seguridad en mente.

Si quieres un programa de seguridad real — no solo el certificado — podemos arrancar un engagement la próxima semana. Discovery call es gratis.