La ciberseguridad para empresas de software no se parece a la de un banco o una fábrica. Tu activo principal es el código, tu infraestructura vive en la nube, tu equipo trabaja desde notebooks en cualquier lado y tus clientes te confían sus datos. Probablemente no tenés un equipo de seguridad, y no lo necesitás para hacer bien lo básico. Lo que necesitás son las prioridades correctas, en el orden correcto.
Esta guía es para startups y pymes de software. Repasa las 7 prioridades que evitan la mayoría de los incidentes reales, propone un plan de 30/60/90 días, separa qué automatizar y qué servicios de ciberseguridad conviene contratar afuera, y resume lo básico de compliance que te van a preguntar los clientes.
Por qué una empresa de software es un caso particular
Los atacantes apuntan a las empresas de software por dos motivos: los datos que guardás y el acceso que tenés a tus clientes. Un proveedor SaaS comprometido puede ser la puerta de entrada a cientos de clientes. Por eso las empresas grandes te mandan cuestionarios de seguridad antes de firmar, y por eso una sola key filtrada en un repo público puede terminar en un incidente que tenés que explicarle a cada cliente.
La buena noticia es que tu superficie de ataque es, en gran parte, visible para vos: tus repositorios, tus cuentas cloud, tu proveedor de identidad y tu pipeline de CI. La mayor parte del riesgo se reduce con configuración y automatización, no con hardware caro.
Las 7 prioridades de ciberseguridad para una empresa de software
1. Seguridad del código
Tu producto es tu mayor superficie de ataque. Las inyecciones, el control de acceso roto y la deserialización insegura siguen siendo las formas más comunes en que se vulneran aplicaciones, y todas se ven en el código. En el OWASP Top 10 2025 tenés las categorías, y en ejecución remota de código el peor escenario. El control práctico es análisis estático en cada pull request, idealmente AI SAST que razone sobre autorización, más revisión humana en los cambios sensibles.
2. Secretos
API keys, contraseñas de base de datos y credenciales cloud terminan en git mucho más seguido de lo que cualquiera admite. Borrar el archivo no saca el secreto del historial. Revisá el historial completo con un secret scanner, rotá todo lo que aparezca, mové los secretos a un gestor o a las variables de entorno cifradas de tu plataforma y bloqueá los commits nuevos que contengan secretos.
3. Dependencias y supply chain
La mayor parte de tu aplicación es código open source que no escribiste. Commiteá los lockfiles, corré software composition analysis de forma continua (los CVEs nuevos aparecen sin commits nuevos) y fijá versiones de las GitHub Actions de terceros y de las imágenes base. En SAST vs SCA explicamos por qué necesitás los dos, y un SBOM te permite responder rápido las preguntas de los clientes.
4. Control de accesos
- Single sign-on (SSO) en todas las herramientas que lo soporten, para que dar de baja a alguien sea un clic.
- Mínimo privilegio: acceso a la base de producción y de admin en la nube solo para las pocas personas que lo necesitan.
- Checklist de offboarding que se ejecuta el mismo día que alguien se va.
- Revisión trimestral de accesos a la organización de GitHub, al IAM de la nube y a los paneles de administración.
- Protección de la rama main: reviews obligatorias y nada de force push.
5. Backups
Un backup solo cuenta si lo podés restaurar. Tené backups automáticos de las bases de datos y del storage crítico, guardá al menos una copia en otra cuenta o proveedor que las credenciales de producción no puedan borrar, y hacé una prueba de restore con una frecuencia fija. Un ransomware o una migración que sale mal es un día muy distinto cuando sabés que el restore tarda 40 minutos.
6. MFA (autenticación multifactor)
Activá MFA en el mail, el proveedor de identidad, GitHub, las consolas cloud, el registrador de dominios, el procesador de pagos y el gestor de contraseñas. Para los admins, preferí métodos resistentes al phishing (passkeys o llaves de seguridad FIDO2). Forzalo a nivel organización en vez de depender de que cada persona lo active.
7. Respuesta a incidentes
No hace falta un plan de 40 páginas. Hace falta una página que responda: quién decide, quién habla con los clientes, cómo revocar credenciales rápido, dónde están los logs, a qué abogado llamar y qué obligaciones de notificación tenés. Hacé una vez por año un ejercicio de mesa (tabletop) de 60 minutos con un escenario realista, como una key de AWS filtrada o la notebook de alguien del equipo comprometida.
Plan de 30/60/90 días
Días 1 a 30: cerrar las puertas obvias
- Forzar MFA en todas las cuentas críticas.
- Inventario: repositorios, cuentas cloud, herramientas SaaS y quién tiene acceso de admin.
- Dar de baja a ex empleados y cuentas sin uso en todos lados.
- Escanear los repositorios principales buscando vulnerabilidades, dependencias vulnerables y secretos en el historial de git. Arreglar lo crítico y rotar las keys expuestas.
- Verificar que los backups existen y hacer una prueba de restore.
Días 31 a 60: hacerlo continuo
- Sumar chequeos de seguridad a los pull requests: SAST, SCA, secretos e infraestructura como código.
- Configurar protección de ramas y reviews obligatorias.
- Pasar a SSO donde se pueda y documentar el checklist de offboarding.
- Centralizar logs de autenticación, acciones de admin en la nube y accesos a producción.
- Escribir el plan de respuesta a incidentes de una página.
Días 61 a 90: poder demostrarlo
- Hacer el ejercicio de mesa.
- Escribir políticas cortas que reflejen lo que realmente hacen: accesos, secretos, backups, gestión de vulnerabilidades.
- Preparar respuestas estándar para los cuestionarios de seguridad de clientes.
- Decidir si hace falta un pentest externo ahora; en análisis de vulnerabilidades vs pentest te ayudamos a elegir.
- Decidir si ISO 27001 o SOC 2 entran en el roadmap, según lo que pidan los clientes.
Qué automatizar y qué servicios de ciberseguridad tercerizar
| Área | Automatizar | Tercerizar o pedir ayuda |
|---|---|---|
| Código y dependencias | SAST, SCA, detección de secretos y chequeos de IaC en cada cambio | Revisión manual periódica de los flujos críticos |
| Testing | Evaluación continua a nivel de código | Pentests, una vez por año o antes de lanzamientos grandes |
| Identidad | SSO, MFA obligatorio, alta y baja de usuarios | La configuración inicial si nadie del equipo lo hizo antes |
| Backups | Backups programados y alertas cuando fallan | Casi nunca hace falta |
| Respuesta a incidentes | Alertas ante actividad sospechosa | Un servicio de respuesta a incidentes contratado de antemano |
| Compliance | Recolección de evidencia | Asesoramiento legal y auditorías de certificación |
En el código es donde entra Nurbak. Conectás GitHub y escaneás un repositorio; su propio modelo de IA self-hosted analiza el código (el análisis no manda tu código a OpenAI ni a Anthropic) y reporta vulnerabilidades explotables con archivo y línea, CVEs de dependencias vía OSV con las versiones corregidas, configuraciones inseguras de GitHub Actions, Docker, Terraform y Kubernetes y secretos en el historial de git, con un score de 0 a 100 y explicaciones en lenguaje simple para quien no es especialista en seguridad. El escaneo gratis muestra completos los 3 hallazgos más importantes y los planes arrancan en USD 79/mes. Cubre la parte del código: no reemplaza un pentest, ni la seguridad de red, ni tu respuesta a incidentes. Arrancá con una auditoría de seguridad de código.
Si estás comparando proveedores de pentesting y servicios de ciberseguridad para empresas, nuestra guía de herramientas de pentesting explica qué cubre la automatización y qué sigue necesitando personas.
Cómo responder los cuestionarios de seguridad de clientes
Tarde o temprano un cliente grande te manda una planilla con decenas o cientos de preguntas de seguridad. Tomala como un checklist, no como un castigo. La mayoría de las preguntas se mapean a las prioridades de arriba: ¿forzás MFA?, ¿cómo gestionás los accesos?, ¿cómo manejás las vulnerabilidades en código y dependencias?, ¿cada cuánto hacés backups y probás restores?, ¿tenés plan de respuesta a incidentes?, ¿hacés pentests? Tené un único documento con respuestas honestas y reutilizables, y la evidencia que las respalda (capturas de configuración, reportes de escaneo, el plan de incidentes). Nunca respondas "sí" a algo que no hacés: el cuestionario muchas veces pasa a ser parte del contrato, y una respuesta falsa es un riesgo mucho mayor que un "todavía no, lo tenemos planificado para el próximo trimestre".
¿Cuánto cuesta?
No hay un número único honesto. Depende del tamaño del equipo, de la cantidad de repositorios y cuentas cloud, de si necesitás certificaciones y de cuánto tercerizás. Lo concreto: la mayor parte de los primeros 60 días cuesta más tiempo del equipo que plata, porque MFA, SSO, protección de ramas, backups y revisión de accesos son configuración. Las partidas grandes llegan después: herramientas de seguridad, pentests externos y, si las encarás, auditorías de certificación. Pedí presupuestos a proveedores con el alcance real de tus activos, no paquetes genéricos.
Compliance: lo básico
- GDPR (Unión Europea): aplica si procesás datos personales de personas en la UE, estés donde estés. Exige medidas de seguridad adecuadas y, para ciertas brechas, notificar a la autoridad de control dentro de las 72 horas. Las infracciones más graves pueden multarse con hasta 20 millones de euros o el 4% de la facturación anual global, lo que sea mayor.
- LGPD (Brasil): aplica a datos personales de personas en Brasil. Las multas pueden llegar al 2% de la facturación de la empresa en Brasil, con un tope de 50 millones de reales por infracción, y las aplica la ANPD.
- Leyes locales: cada país de Latinoamérica tiene su propia normativa de protección de datos (en Argentina, por ejemplo, la Ley 25.326). Asesorate legalmente en los mercados donde vendés.
- ISO/IEC 27001: estándar internacional para un sistema de gestión de seguridad de la información (SGSI). Se certifica con un organismo acreditado. La versión 2022 tiene 93 controles en el Anexo A.
- SOC 2: un informe de atestación bajo los Trust Services Criteria del AICPA, común con clientes de Estados Unidos. El Type I mira el diseño de los controles en un momento dado; el Type II prueba cómo funcionaron durante un período.
La buena noticia: las 7 prioridades de arriba se mapean directamente a controles de todos estos marcos. Hacer bien lo básico es la mayor parte de la preparación.
Errores comunes
- Comprar herramientas antes de resolver lo básico. Un SIEM no sirve de mucho si los admins no tienen MFA.
- La seguridad como evento anual. Un pentest por año no cubre código que se deploya todos los días. Integralo al flujo de DevSecOps.
- Políticas que nadie sigue. Escribí lo que hacés, y después hacé lo que escribiste.
- Sin responsable. Alguien del equipo tiene que tener la seguridad como responsabilidad explícita, aunque sea part-time.
Conclusión
La ciberseguridad para una empresa de software es, sobre todo, disciplina: MFA, mínimo privilegio, secretos limpios, dependencias al día, código seguro, backups probados y un plan para los días malos. Nada de eso requiere un equipo grande. Seguí el plan de 30/60/90 días, automatizá lo que tiene que correr siempre, tercerizá lo que necesita independencia y empezá por donde vive la mayor parte de tu riesgo: una auditoría de seguridad de tu código.