barrrido de seguridad (security-sweep)

Barrido de seguridad (Security Sweep)

Responde bien a una pregunta: ¿Están estos proyectos expuestos a una vulnerabilidad de dependencias que importa ahora mismo? «Ahora mismo» significa ya sea catalogada y alcanzable, o un incidente activo en la naturaleza que aún no se ha propagado completamente a las bases de datos de auditoría.

El valor añadido respecto a un simple npm audit es la capa de investigación. Las bases de datos de asesorías se retrasan respecto a la divulgación, y los incidentes con paquetes maliciosos a menudo se manejan mediante la eliminación del paquete (sin dejar un aviso consultable). Por lo tanto, este barrido combina las herramientas deterministas con investigación en vivo sobre lo que se está explotando activamente, y verifica el archivo lock directamente para esos nombres — la señal confiable más rápida, que ninguna herramienta de auditoría te proporciona.

Solo lectura por defecto: esto investiga e informa. Solo propone correcciones; no apliques cambios de versión sin la aprobación del usuario (pueden romper compilaciones).

Cuándo usarlo

• «Investiga seguridad» / «verifica dependencias vulnerables» / «ejecuta un barrido de seguridad».
• «¿Nos afecta <un CVE, GHSA o historia de compromiso de paquete>?» — el usuario leyó algo y quiere conocer su exposición.
• Una verificación periódica (componer con el skill schedule para un barrido recurrente en la nube — ver al final).

Paso 1 — Alcance

Decide qué barrer. Por defecto, el proyecto actual; ofrece un barrido de múltiples repositorios si el fraseo del usuario es amplio («nuestros proyectos», «todo», «la flota»).

• Proyecto actual: el repositorio en el que estás.
• Múltiples repositorios: enumera los repositorios hermanos junto al actual — es decir, el padre de la raíz git actual (comúnmente ~/projects/*/ o ~/src/*/). Confirma el directorio con el usuario antes de recorrerlo en lugar de asumir; una suposición incorrecta desperdicia un escaneo largo. Para cada repositorio, detecta los ecosistemas por manifiesto (abajo), barre a su vez, informa por proyecto.

Paso 2 — Detectar ecosistemas y localizar archivos lock

Por proyecto, un ecosistema está presente si su archivo lock es:

Ecosistema	Manifiesto / archivo lock	Dónde suele estar
npm	package-lock.json	frontend/ o raíz del repo
Go	go.mod / go.sum	backend/ o raíz del repo
Python	poetry.lock, requirements.txt, uv.lock	raíz del repo
Swift/SPM	Package.resolved	ios/ o un .xcodeproj

El archivo lock — no el manifiesto — es lo que se escanea: fija las versiones transitivas exactas realmente instaladas.

Paso 3 — Línea base determinista (por ecosistema)

Ejecuta las herramientas propias del ecosistema. Estas detectan todo lo que ya está en las bases de datos de asesorías. Prefiere herramientas con análisis de alcanzabilidad (solo reportan vulnerabilidades que tu código realmente puede alcanzar) cuando estén disponibles.

• npm: cd <dir> && npm audit --omit=dev --audit-level=high (lo que se envía a los usuarios) y un npm audit simple (todo, informativo). Sin alcanzabilidad — sobre-reporta; pondera los hallazgos de producción.
• Go: govulncheck ./... — sí hace análisis de alcanzabilidad (solo marca vulnerabilidades en código llamado); instálalo una vez con go install golang.org/x/vuln/cmd/govulncheck@latest. El estándar de oro entre estas herramientas.
• Python: pip-audit (o pip-audit -r requirements.txt).
• Cualquier ecosistema, o cuando falta una herramienta: osv-scanner contra el archivo lock, ejecutado mediante un contenedor para no tener que instalar nada: <runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>. La base de datos más amplia; la opción de respaldo para Swift/SPM, que tiene herramientas propias limitadas.

Captura lo que informe cada una. Distingue producción/alcanzable de desarrollo/tiempo de compilación — un hallazgo alto en una herramienta de compilación que nunca se envía no es lo mismo que uno en una dependencia en tiempo de ejecución.

Paso 4 — Investigar el panorama activo de amenazas (el valor añadido)

Esto es lo que una auditoría simple no puede hacer. Usa WebSearch / WebFetch para encontrar qué está activo actualmente, luego trae los nombres al Paso 5.

• Incidentes recientes en la cadena de suministro en los ecosistemas del proyecto: busca campañas de compromiso y malware recientes en npm/PyPI/Go; verifica la Base de Datos de Asesorías de GitHub (github.com/advisories) y OSV (osv.dev) para entradas publicadas recientemente que toquen paquetes que viste en el Paso 2.
• Si el usuario nombró un CVE / GHSA / incidente específico, obtén la asesoría autorizada y extrae el nombre exacto del paquete afectado y los rangos de versiones — eso es lo que compararás con el archivo lock.
• Prefiere fuentes primarias (la asesoría, la publicación del mantenedor, el aviso de seguridad del registro) sobre titulares de agregadores; señala cuando algo no esté confirmado.

Mantenlo actual: fecha cada afirmación y di cuál fue tu ventana de investigación (por ejemplo, «incidentes activos divulgados en las últimas ~8 semanas»).

Paso 5 — Cruzar referencias de nombres contra el archivo lock directamente

Para cada paquete descubierto en el Paso 4, no esperes a la herramienta de auditoría — verifica el árbol fijado tú mismo. Este es el paso de indicador adelantado:

# npm
cd <dir> && npm ls <paquete>
grep -n '"<paquete>"' package-lock.json
# Go
grep -n '<ruta-del-módulo>' go.sum
# Python
grep -in '<paquete>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<paquete>' --include=Package.resolved .

Luego compara la versión fijada contra el rango afectado de la asesoría. Tres resultados por nombre: expuesto (presente y dentro del rango), limpio (ausente, o presente pero fuera del rango), incierto (versión transitiva que no pudiste resolver completamente — investiga más o márcalo).

Paso 6 — Informar

Por proyecto, comienza con el veredicto, luego la evidencia:

• Expuesto — paquete, versión fijada, asesoría/incidente, si es alcanzable en producción y una corrección concreta (cambio de versión dirigido; nunca un npm audit fix ciego). Si una versión comprometida pudo haber sido instalada, señala que su postinstall ya pudo haberse ejecutado — la razón principal por la que un ignore-scripts por defecto importa.
• Limpio — las amenazas activas investigadas y verificadas como no presentes. Di qué verificaste, para que «limpio» signifique algo.
• Incierto / no cubierto — ecosistemas con herramientas limitadas (Swift), transitivos no resueltos, o investigación que no pudo confirmar un rango. Nombra la brecha en lugar de implicar cobertura total.

No impliques que encontraste todo. Indica la ventana y los ecosistemas realmente barridos.

Composición

• Barrido recurrente: entrega el procedimiento de este skill al skill schedule para una ejecución semanal en la nube en todos los repositorios, de modo que un incidente nuevo se detecte en días en lugar de cuando alguien piense en mirar.
• Antes de un lanzamiento o un push: ejecuta un barrido limitado a un solo proyecto. Se combina naturalmente con un paso make audit / make secret-scan previo al push si el proyecto lo tiene.

Notas

• Las herramientas de auditoría son indicadores retrasados; las noticias y el Paso 4 de este skill son los adelantados. Cuando discrepen — la investigación dice que un paquete está comprometido pero las herramientas callan — confía en la verificación directa del archivo lock y trátalo como activo.
• npm audit reporta la gravedad de la asesoría, no tu explotabilidad (sin análisis de alcanzabilidad) — sobre-reporta. govulncheck es lo opuesto y el modelo a preferir cuando un ecosistema lo ofrece.
• Este skill responde sobre la exposición. La corrección (cambios de versión, fijación, npm rebuild para una excepción de script con ámbito) es un paso separado y aprobado por el usuario — presenta la solución, no la apliques sin solicitud.