Respuesta rápida (actualizada el 31-10-2026): CisoTeam reúne la seguridad de todos tus proyectos en un solo lugar: cada hallazgo con su severidad, la prueba de que existe y qué hacer, listo para entregar a tu agente para que lo arregle. Un hallazgo crítico o alto solo se marca como confirmado si viene con el comando que lo reproduce; si no, queda como sospecha. Las sospechas pesan menos en el score. El flujo es de cuatro pasos: firmar y verificar tu dominio con un registro TXT en DNS, enviar tus revisiones con una key por proyecto, ver el score por proyecto con los hallazgos ordenados por severidad, y copiar el fix para Claude Code, Codex u OpenCode con la regla del test que falla sin la corrección.
El problema: 200 hallazgos en un PDF que nadie arregla
Esta escena se repite en casi todas las empresas con producto propio.
Se instala un scanner. A la semana entrega un reporte con doscientas líneas, la mayoría marcadas en rojo. El equipo mira las primeras diez, ve que tres no aplican, y deja de mirar. A los dos meses aparece un hallazgo crítico en producción y el reporte sigue en una carpeta que nadie abre.
Los dos extremos fallan por la misma razón: el reporte no está ordenado por lo que de verdad importa.
- Por un lado, mezcla lo confirmado con lo dudoso. Un código que "podría" tener un problema pesa igual que uno que se acaba de reproducir.
- Por otro lado, termina el trabajo en una lista de recomendaciones. El developer recibe "actualiza esta dependencia" sin el contexto, sin el comando y sin la prueba de que el arreglo funcionó.
El escáner no es el problema. Lo que falta es el tramo entre "encontré algo" y "quedó arreglado".
Qué es CisoTeam
CisoTeam es el servicio que cubre ese tramo. Mantiene la seguridad de tus proyectos en un solo lugar y hace tres cosas por cada hallazgo: le pone severidad, le pone la prueba de que existe, y entrega el texto con qué hacer para que tu agente lo aplique.
Y pone una regla que casi ningún scanner pone: lo que no está probado se queda como sospecha, no como alarma.
Los cuatro pasos
1. Firma y verifica
Se firman términos y un NDA, y después se agrega un registro TXT en tu DNS. Solo se revisa lo que has demostrado que es tuyo. No es burocracia: es lo que impide que alguien use tu revisión contra un sitio que no controlas.
2. Envía tus revisiones
Cada proyecto tiene su propia key. Cualquier script o paso de integración continua puede enviar el reporte a la API: código, dependencias y configuración. No hay que instalar un agente en cada máquina ni cambiar la forma de trabajar del equipo.
3. Mira lo que importa
Un score por proyecto, tus áreas en rojo, amarillo o verde, los hallazgos ordenados por severidad y una línea de tiempo de qué cambió. El score es lo que permite comparar un mes con otro y ver si la deuda de seguridad sube o baja.
4. Arréglalo con tu agente
Cada hallazgo trae un texto para pegar en Claude Code, Codex u OpenCode: qué es, dónde está, por qué importa y la regla para agregar un test que falle sin la corrección.
Ese último punto es el que separa una corrección real de un parche que se rompe con el próximo cambio. No es solo "cambia esto": es "agrega el test que hoy falla, así nadie puede volver a romperlo".
Las reglas que hacen confiable el reporte
Confirmado significa reproducido
Un hallazgo crítico o alto marcado como confirmado trae el comando para reproducirlo. Sin ese comando, el servidor lo conserva como sospecha. No se infla la alarma para tener más hallazgos.
Las sospechas pesan menos
Algo visto en el código no es lo mismo que algo observado corriendo. El score y la severidad lo dicen: una sospecha no vale lo que vale una reproducción.
Fixed cuando deja de aparecer
Un hallazgo abierto se marca como corregido solo cuando una revisión completa ya no lo encuentra. Aceptar un riesgo es decisión tuya, y queda escrito el motivo.
Guardamos solo una huella
La key del proyecto se muestra una vez. Al rotarla, la anterior queda cortada de inmediato, y los reportes llegan con los secretos evidentes eliminados.
Solo lo que es tuyo
No se acepta nada hasta que verificas el dominio, y cada persona ve únicamente sus propios proyectos, aunque adivine un identificador.
Defensivo: para cerrar holes, no para abrirlos
Lo que se ejecuta detecta sin explotar tu sitio. Un trabajo ofensivo es otro contrato, con autorización firmada.
Cómo se ve en la práctica
Un ejemplo de la herramienta, con datos de muestra. El proyecto aparece con su score y sus áreas, y cada hallazgo con su estado:
- tienda.example.com, score 72. Áreas: webhooks, dependencias, cabeceras y secretos.
- Crítico, confirmado: "The payments webhook accepts requests without a signature". La prueba: "POST without a signature header, devuelve 200 cuando debería devolver 401". Y el botón para copiar el arreglo para tu agente.
- Medio, sospecha: "Session cookie without SameSite". La anotación: "Visto en el código. Todavía no está confirmado en ejecución".
Ese contraste es el producto. El webhook sin firma tiene una reproducción que cualquiera puede correr contra su propio entorno y ver el 200. La cookie sin SameSite está en el código, pero nadie la ha observado fallar. Uno se arregla hoy; el otro se anota y se mira mañana. Tratar los dos igual es lo que hace que un equipo deje de leer reportes.
Si prefieres que lo haga el equipo
CisoTeam también tiene una vía de servicio. El equipo audita tu infraestructura bajo contrato, con NDA y autorización firmados antes de que nadie toque nada, y la landing señala que eso es lo que exige la ley chilena 21.459. Recibes el informe con el plan de corrección.
CisoTeam es para antes
Hay una distinción que conviene tener clara: CisoTeam es para antes del incidente. Cuando el ataque ya está pasando, la respuesta es otra: War Room manda guardias de IA a tu servidor para contener el ataque y dejar la evidencia.
Y para el día a día del pipeline hay una pieza complementaria: npmsecure, el escáner open source de Personnn que audita proyectos npm, detecta malware en node_modules, expone secretos en el historial de git y bloquea typosquatting antes de instalar.
Lo que CisoTeam no hace
- No es un trabajo ofensivo. Detectar sin explotar es el diseño. Explotar es otro contrato y otro acuerdo.
- No revisa lo que no es tuyo. Sin el registro TXT en DNS, no entra.
- No decide por tu equipo. Entrega el arreglo propuesto y el test que lo fija; la decisión de aplicar y priorizar sigue siendo del equipo.
- No convierte sospechas en hechos. Lo que no se reproduce se queda como sospecha, y eso es intencional.
- No es una garantía de que no existirán hallazgos nuevos. El score y la línea de tiempo sirven para ver la tendencia, no para declararte limpio.
Fuentes
- Personnn CisoTeam, landing del producto (personnn.com/cisoteam, leída el 31-10-2026): un solo lugar con la seguridad de tus proyectos, cada hallazgo con severidad, prueba y qué hacer, listo para entregar al agente; regla de que lo no probado queda como sospecha y no como alarma; cuatro pasos (firmar y verificar con registro TXT en DNS revisando solo lo propio, enviar revisiones con key por proyecto reportando código, dependencias y configuración, ver score, áreas y línea de tiempo, y copiar el arreglo para Claude Code, Codex u OpenCode con la regla del test que falla sin la corrección); reglas de confirmado con comando de reproducción, sospechas que pesan menos, fixed cuando la revisión completa ya no lo encuentra, aceptación de riesgo con el motivo escrito, key mostrada una vez y rotada al instante, reportes con secretos eliminados, verificación de dominio y aislamiento por proyecto; perfil defensivo que detecta sin explotar y auditoría bajo contrato con NDA y autorización firmados; ejemplo de muestra con tienda.example.com, score 72, hallazgo crítico confirmado del webhook sin firma con su prueba y hallazgo medio como sospecha por cookie sin SameSite; redirección a War Room para incidentes en curso.
- Ley 21.459: la landing de CisoTeam la menciona como la ley chilena que exige NDA y autorización firmada antes de auditar infraestructura. El texto legal no fue verificado en esta revisión, por lo que la atribución queda en la landing.
- npmsecure, landing del proyecto (personnn.com/npmsecure, leída el 31-10-2026): escáner open source con licencia MIT para proyectos npm, que detecta malware en node_modules, expone secretos en el historial de git y archivos .env y bloquea typosquatting antes de instalar.
Próximo paso
- Crea tu cuenta en Personnn y revisa el primer proyecto con tu agente.
- Habla con el equipo: revisamos tus repositorios y qué conviene atacar primero.
- Conoce Personnn CisoTeam: score por proyecto, hallazgos con su prueba y el fix listo para tu agente. Si prefieres que el equipo lo audite bajo contrato, revisa servicios. Si ya estás bajo ataque, revisa Personnn War Room. Si quieres el control diario en tu pipeline de npm, revisa npmsecure. Si necesitas que la IA de tu agente no salga de tus máquinas, revisa Personnn Inference. Si necesitas correo para tu agente con traza, revisa Personnn Mail.
