Seguridad que se mide. No que se declara.
Un pentest viejo, tickets que dicen «cerrado» y escáneres que nadie lee no son seguridad: son una sensación. Armamos los controles adentro de tu empresa —en cada cambio de código, en cada aviso público, en toda la historia de tus repositorios— y los dejamos andando con tu equipo.
Cada control prueba que funciona: si no puede mostrar que detecta un caso plantado, no cuenta como control.
quién lo
miró?
El problema
Casi ninguna empresa está sin seguridad. Lo que falta es saber si lo que tiene funciona. En seguridad el miedo vende solo; acá se vende una medición.
«El pentest está cerrado»
Lo dice el ticket, de hace años. Nadie volvió a mirar el código para ver si el arreglo sigue ahí.
«Tenemos alertas»
Prendidas a medias, y avisando a un canal donde se pierden entre otros cien mensajes.
«Nos enteramos por redes»
La vulnerabilidad de la semana llega por un posteo, no por un sistema. Y nadie sabe si te afecta.
«Todo es urgente»
Decenas de tickets con prioridad máxima. Cuando todo es urgente, la prioridad ya no ordena nada.
«Tenemos backup»
En la misma cuenta que lo que respalda. Quien puede borrar los datos puede borrar el respaldo.
El primero es el más engañoso: un ticket cerrado no es una medición, es una opinión de hace años.
Cuatro capas, cada una con su momento
Ninguna alcanza sola. Cada una cubre lo que la anterior no ve, y cada una corre cuando tiene sentido que corra.
1 · Portón en cada commit
Reglas deterministas en CI. Lo que viola una regla no se mergea. Barato, rápido y sin opinión.
2 · Revisión de cada PR
Un agente en contexto separado, con un checklist, antes de que una persona apruebe.
3 · Auditoría del servicio
El estándar OWASP ASVS sobre el repositorio entero, con vigencia: si la superficie cambió, se vuelve a auditar.
4 · Matriz de permisos
El usuario A pide lo del usuario B, en un entorno de prueba. La única que prueba la clase entera de fallas de autorización.
La IA está en las capas 2 y 3, como herramienta del equipo y nunca como aprobador: lo que propone, lo aprueba una persona. Si alguien te vende una IA que te asegura sola, preguntale quién aprueba lo que propone.
Vigilancia: del aviso público a tu ticket
Cuando sale una vulnerabilidad, la pregunta no es si es grave. Es si corre en tu producción. Un script lee las fuentes primarias y cruza cada aviso con lo que de verdad está desplegado: runtimes, imágenes y dependencias.
Aviso
Cruce
Ticket
Qué se atiende primero
Corregir lo que no se puede explotar consume el tiempo que falta para lo que sí. Cinco preguntas, en orden; la primera que da «no» corta, y cada respuesta lleva cómo se midió.
¿Está en producción?
En lo que está desplegado, no en la rama de alguien.
¿En el proceso expuesto?
Servidor, navegador, línea de comandos o solo al compilar.
¿Se llega a la función?
Que la librería esté no alcanza: el código tiene que usarla.
¿Se cumplen?
La configuración y las opciones que el aviso exige.
¿Y qué tiene que encadenar?
Internet, un usuario logueado o alguien de adentro.
Lo que pasa las cinco va primero. Lo que no, se documenta con su medición, y vuelve a la cola si algo cambia.
Secretos: toda la historia, no solo hoy
Una clave que se borró en el commit siguiente sigue en el repositorio. Se barre la historia completa, y el resultado no copia nunca un valor.
| Lo habitual | Con este método | |
|---|---|---|
| Alcance | El código de la rama principal | Toda la historia de todos los repositorios |
| Prueba | «No encontró nada» | Un secreto plantado tiene que aparecer, o el barrido no vale |
| Resultado | Una lista larga, sin orden | Cada hallazgo con dónde está, si sigue vivo y qué hacer |
| Valores | Copiados en el informe | Redactados: el informe no se vuelve otra filtración |
| Después | Una vez, y se archiva | Diario, avisando solo lo nuevo |
Un comando que falló no significa «no hay»: significa «no pude ver». Confundir las dos es la forma más común de declarar seguro algo que nadie miró.
Qué avisa, a quién
Un detector sin destino es lo mismo que no tenerlo. Cada fuente tiene su canal, y cada canal tiene alguien que lo lee.
Todo prendido, nada leído
- Detectores activados a medias, sin destino
- Alertas mezcladas con el ruido de la operación
- El informe de seguridad en el mismo canal que el resto del equipo
Cada aviso llega a quien decide
- Un canal por tipo de aviso, con su umbral
- Lo urgente interrumpe; lo demás espera su revisión
- Lo que es mapa de ataque no circula fuera de quien lo necesita
Una regla que protege del propio sistema: el modelo que lee una alerta no escribe. El ticket lo arma un paso aparte con datos estructurados, para que un texto malicioso en un aviso no se convierta en una orden.
Que un administrador comprometido no pueda borrarlo todo
El ataque de nube más dañino no rompe nada: usa una cuenta legítima para borrar datos y respaldos. Se diseña para que esa cadena no funcione.
Copia inmutable, en otra cuenta
El respaldo sobrevive aunque se pierda la cuenta de producción entera.
Políticas que niegan el borrado
Ni un administrador puede apagar la recuperación ni borrar respaldos, salvo un acceso de emergencia controlado.
Sesiones cortas
Los permisos de administrador duran lo que dura la tarea, y no viven en la computadora de todos los días.
Las medidas se ordenan por costo y efecto, y la que suena primera no siempre es la que va primero: una protección que un administrador apaga con un comando solo vale junto con la política que se lo impide.
Las reglas que sostienen todo lo demás
Alguien de afuera mirando tu seguridad tiene que estar bajo más control que nadie. Se responde con reglas, no con confianza.
Autor no es aprobador
Ningún cambio entra sin que una persona de tu lado lo apruebe. Tampoco los que propone la IA.
El plan de infraestructura se lee entero
Un cambio chico puede arrastrar un reemplazo grande. Se lee el plan, no el diff, y se respalda antes.
El código manda, no el ticket
Un hallazgo está cerrado cuando el código lo demuestra, no cuando alguien lo marcó.
Accesos nominales, de solo lectura
Por defecto, solo lectura. Se apaga el usuario y todo sigue andando.
El caso · una fintech de 4 años
Una plataforma financiera sin CISO, con un equipo chico y mucho código heredado. Una persona apalancada en IA trabajando adentro:
Salió de dos meses de trabajo en una plataforma real, errores incluidos, no de una demo. Lo que se compra no es una lista de hallazgos: es un sistema que los sigue encontrando cuando quien lo armó ya no está mirando.
Caso de referencia anonimizado, el mismo de brain.placedium.com: sin nombre de cliente, sin hallazgos, sin datos de terceros. Las cifras están redondeadas hacia abajo.
Para quién es
No hace falta tener un equipo de seguridad. Hace falta querer saber, con datos, cómo estás.
Movés dinero o datos sensibles
Fintech, pagos, salud o cualquier negocio donde un error de seguridad deja de ser anecdótico.
No tenés CISO
Y la seguridad la reparte un equipo que además tiene que entregar el producto.
Tenés una auditoría con hallazgos abiertos
Y no sabés cuáles siguen vivos en el código de hoy.
Tuviste un susto
Y querés que el próximo lo detecte un sistema, no un posteo.
Tu equipo ya programa con IA
Y querés que la misma velocidad venga con revisión, no con más riesgo.
El directorio pregunta «¿estamos bien?»
Y nadie puede contestar con una medición en la mano.
Si lo que falta es alguien que dirija la tecnología entera, no solo la seguridad, eso es CTO fraccional.
Cómo arranca
Primero se mide dónde estás. Las capas se suman de la más barata a la más cara.
Qué corre y qué se mira
Qué está desplegado, qué se escanea y a dónde avisa.
Medida, no estimada
Cada dato con el comando que lo produjo, para poder repetirlo.
De la más barata a la más cara
Primero lo gratis que ya tenías apagado.
Andando sola
Fuera de la computadora de nadie, con su canal y su umbral.
Tu equipo la opera
Las reglas, los scripts y la documentación quedan de tu lado.
Si el relevamiento muestra que lo urgente es otra cosa, se dice ahí, y la línea base es tuya igual.
Empresas y proyectos en los que participé
Más de 25 años en fintech, banca, retail, medios, streaming y gobierno: las empresas donde trabajé, y los proyectos y clientes que pasaron por mis equipos.
Los nombres son de sus dueños; los círculos son iniciales, no logos. En azul, las empresas donde trabajé; alrededor, proyectos y clientes.
Vigilar.
Traspasar.
«Un ticket cerrado no es una medición. El código que corre, sí.»
Hablemos. Una línea base.
Contanos qué tenés y qué te preocupa. Una conversación corta alcanza para saber por dónde empezar a medir.