El paquete que instala el atacante

Respuesta rápida (actualizada el 09-11-2026): Dolor: una dependencia con nombre parecido, un script que corre al instalar o un secreto en el historial de git; nada de eso se ve en el Pull Request y el agente de IA quedó con permisos de más. Resultado: que el build se caiga antes de producción, con un reporte legible en un minuto. Antes de contratar nada: ¿quién decide en tu equipo y quién instala las dependencias? Hablemos

El equipo instala una dependencia como instala cualquier otra. El paquete se llama casi igual al que todos usan (typosquatting), trae un script que se ejecuta al instalar, o el secreto de producción quedó en el historial de git. Nada de eso se ve en el Pull Request, porque nadie miró. Y el agente de IA quedó con permisos para leer y escribir más de lo que debería.

Cuando eso se descubre, ya está en producción. Y lo peor no es el incidente: es que nadie sabe qué había instalado y cuándo.

El resultado que buscas no es "revisar más": es que el build se caiga antes de que el problema llegue a producción, con un reporte que se pueda leer en un minuto y una política que se aplique sola.

El volumen de ataques no es la medida del riesgo

SEK, en su reporte "Think Ahead" con datos de 2025 y publicado en rga.cl el 1 de julio de 2026, calcula 8,8 billones de intentos de ciberataque en Chile, y aclara que 5 billones son escaneos activos: máquinas que prueban rutas y se van.

Ese dato sirve para algo muy concreto: el volumen bruto no te dice nada sobre tu riesgo. Si todo se ve igual, nada se ve. Lo que importa es distinguir el escaneo que pasó del ataque que se quedó, y para eso hace falta instrumentación, no alarma.

Los cuatro puntos por donde se entra

1. La cadena de suministro. Un paquete con un nombre casi idéntico al verdadero, un script que corre en la instalación, o malware dentro de node_modules. npmsecure revisa node_modules de forma recursiva, identifica paquetes maliciosos y patrones sospechosos, y con --quarantine aísla en vez de borrar; además npmsecure install <paquete> verifica la seguridad antes de instalar, mirando la edad del paquete, el typosquatting y los metadatos del repositorio.

2. Los secretos. Una credencial en .env, una llave escrita a mano, un token que quedó en un commit de hace seis meses. npmsecure gitcheck --history expone lo que está en el historial y en los archivos .env, antes de que llegue a producción.

3. La configuración. npmsecure corrige seis valores por defecto inseguros de npm, entre ellos ignore-scripts, audit-level y save-exact, y con --dry-run muestra qué haría antes de hacerlo. npmsecure policy-check --init aplica políticas en tu pipeline de CI/CD.

4. Los agentes de IA. npmsecure agents audita las configuraciones MCP de Claude Code, Cursor y Windsurf y detecta permisos excesivos que exponen datos sensibles. Este es el punto que más ha crecido: el agente no tiene la culpa de leer de más, pero alguien tiene que definir qué puede leer.

Tres preguntas para calificar la decisión

Antes de contratar nada, responde esto:

1. ¿Quién decide? En un equipo de desarrollo suele ser el tech lead o el CTO, pero quien instala las dependencias todos los días es otro. Si decide el jefe y ejecutan los devs, la propuesta tiene que responderle a los dos.
2. ¿Con qué criterios eligen? Que el build se cague ante un secreto filtrado, que nadie tenga que revisar dependencias a mano, o que quede registro de qué se instaló: son tres compras distintas y no se venden igual.
3. ¿Cómo es el proceso hoy? ¿Hay revisión de dependencias en el Pull Request, hay escaneo automático en CI, y hay alguien que mire los avisos? Si la respuesta es "el antivirus del servidor", el punto de entrada es otro.

Y una cuarta: ¿quién es tu champion? Quien va a mantener la regla cuando aparezca una excepción urgente. Sin esa persona, la política dura hasta el primer incendio.

Qué medir

• Paquetes revisados por build. Porcentaje de tus installs que pasan por el escáner.
• Secretos encontrados antes de producción. Es la métrica que importa: cada hallazgo en el historial es un incidente que no ocurrió.
• Builds caídos por política. Si el número es cero y nadie mira los reportes, la política no está viva.
• Permisos de agente revisados. Configuraciones MCP corregidas por trimestre.

Qué ofrece Personnn

npmsecure (personnn.com/npmsecure, leído el 09-11-2026) es un escáner de seguridad, endurecedor y detector de malware para proyectos npm, código abierto y licencia MIT. Trae diez comandos (scan, harden, locks, malware, install, gitcheck, threat-feed, agents, policy-check, doctor), salida SARIF para GitHub y GitLab, JSON para tu pipeline y códigos de salida 0/1/2 para que el build se caiga cuando corresponde. Los avisos de vulnerabilidades salen de GitHub Advisory Database y OSV, filtrados por la ventana de horas que definas con --hours.

Personnn War Room (personnn.com/warroom, leído el 09-11-2026) cubre lo que pasa después: si un activo ya está comprometido, los guards contienen, capturan evidencia y dejan un rastro verificable, sin ejecutar nada sin tu aprobación explícita. Y Personnn Box (personnn.com/box, leído el 04-11-2026) permite que ese análisis corra dentro de la red de la oficina, con inferencia local y pago único, para que los logs no salgan del edificio.

Fuentes

• SEK, reporte "Think Ahead" con datos de 2025, publicado en rga.cl el 1 de julio de 2026: 8,8 billones de intentos de ciberataque en Chile, de los cuales 5 billones son escaneos activos.
• npmsecure, landing del producto (personnn.com/npmsecure, leído el 09-11-2026): escáner de seguridad, endurecedor y detector de malware para proyectos npm; detecta ataques de cadena de suministro, secretos expuestos y configuraciones inseguras; licencia MIT; diez comandos; detección recursiva de malware en node_modules con --quarantine; verificación previa a la instalación por edad del paquete, typosquatting y metadatos; endurecimiento de ignore-scripts, audit-level y save-exact con --dry-run; revisión de secretos en el historial git y en .env; auditoría de configuraciones MCP de Claude Code, Cursor y Windsurf; avisos desde GitHub Advisory Database y OSV con --hours; salida SARIF para GitHub y GitLab, JSON para el pipeline y códigos de salida 0/1/2.
• Personnn War Room (personnn.com/warroom, leído el 09-11-2026) y Personnn Box (personnn.com/box, leído el 04-11-2026): contención asistida con aprobación explícita y rastro verificable; inferencia local en la oficina, de pago único.

Próximo paso

• Hablemos de tu caso: cuéntanos qué se instala hoy en tus repositorios y si el build revisa algo antes de desplegar. Con eso te decimos por dónde partir.