dependency-scanner

Subagent Scope Guard

Si fuiste invocado como subagente para una tarea concreta, ejecuta solo esa tarea, reporta DONE / DONE_WITH_CONCERNS / BLOCKED y retorna.

Dependency Scanner Skill

§0 Cuándo usar

• Después de que un agente de lenguaje genera un proyecto con dependencias
• En CI en cada PR que toca package*.json, requirements*.txt, *.csproj, etc.
• Antes de un release para generar el SBOM obligatorio (proyectos enterprise)
• Cuando el humano pide revisar vulnerabilidades en dependencias

§1 Activación por language pack

Este skill se activa automáticamente cuando se trabaja con:

Language Pack	Manifiestos escaneados
TypeScript/Node	package.json, package-lock.json, yarn.lock
Python	requirements.txt, Pipfile, pyproject.toml
.NET/C#	*.csproj, packages.config, packages.lock.json
Java	pom.xml, build.gradle
Go	go.mod, go.sum
Rust	Cargo.toml, Cargo.lock
Ruby	Gemfile, Gemfile.lock

§2 Uso básico

# Escanear proyecto
bash scripts/dependency-scan.sh --path ./project/

# Generar SBOM CycloneDX además del report
bash scripts/dependency-scan.sh --path ./project/ --generate-sbom

# Solo CRITICAL (más estricto para CI)
bash scripts/dependency-scan.sh --path ./project/ --severity CRITICAL

# Modo offline (DB ya descargada)
bash scripts/dependency-scan.sh --path ./project/ --skip-update

§3 Auto-detección de tipo de proyecto

El script detecta automáticamente el tipo de proyecto buscando manifiestos conocidos. No requiere configuración manual del lenguaje.

§4 Fallback Docker

Si Trivy no está instalado localmente:

docker run --rm -v "$(pwd):/workspace" aquasec/trivy:latest fs /workspace

§5 SBOM — Software Bill of Materials

El SBOM en formato CycloneDX es un artefacto de release obligatorio para proyectos enterprise. Documenta exactamente qué dependencias incluye el software. Generarlo no requiere conectividad extra (DB local).

output/security/sbom-YYYYMMDD.json     ← SBOM CycloneDX
output/security/dep-scan-YYYYMMDD.json ← Report de CVEs

§6 Gestión de vulnerabilidades encontradas

1. CRITICAL: siempre actualizar la dependencia afectada
2. HIGH con fix disponible: actualizar en el sprint actual
3. HIGH sin fix: suprimir en .trivyignore con justificación y fecha
4. MEDIUM/LOW: informativo — planificar en el backlog

Ver política completa: docs/rules/domain/dependency-security-policy.md