Skill de Auditoría de Módulos y Seguridad de Go

Skill de política de seguridad y govulncheck para agentes: una Skill de Agente estilo "cookbook" para barridos de seguridad de módulos Go 1.26 antes del lanzamiento.

Qué Hace Esta Skill

Produce un plan de auditoría ejecutable: resultados de govulncheck, rastros de importación vulnerables, pines de go get propuestos, indicadores de licencia/política y comandos de verificación, sin fusionar automáticamente los cambios de dependencia.

Cuándo Invocar

• Higiene semanal de dependencias o antes del lanzamiento
• Después de alertas de Dependabot o escáneres de seguridad
• Cuando los agentes sugieren actualizaciones de go get
• Incorporación de nuevos módulos al espacio de trabajo go work de un monorepo
• Revisión post-incidente de exposición de la cadena de suministro

Entradas

Salidas

• Tabla resumen de govulncheck -json: CVE, módulo, versión corregida, ruta de llamada
• Comandos propuestos de go get module@version (el humano aprueba)
• Valores atípicos de licencias vs. lista de permitidos
• Verificación: go test ./..., go mod verify, comando opcional syft SBOM

Salvaguardas

1. No go get -u ./... sin aprobación humana explícita y revisión del registro de cambios.
2. Los saltos de versión principales requieren ADR o referencia de ticket en la salida.
3. No editar go.sum manualmente, solo go get / go mod tidy.
4. Respetar las directivas retract en el go.mod del consumidor.
5. Ejecutar pruebas después de cada pin propuesto antes de sugerir la fusión.
6. Módulos internos: verificar GOPRIVATE antes de publicar registros de auditoría.

Receta

Tarjeta de receta de referencia rápida, lista para copiar y pegar.

# 1. Integridad base del módulo
go mod verify
go list -m -json all | head   # sanity: el gráfico se resuelve
 
# 2. Escaneo de vulnerabilidades
govulncheck -json ./... > /tmp/vuln.json
 
# 3. Resumen legible por humanos
govulncheck ./...
 
# 4. Después de los pines aprobados únicamente
go get golang.org/x/net@v0.34.0
go mod tidy
go test ./...
govulncheck ./...

Cuándo usar esta skill:

• El capitán de lanzamiento necesita un barrido de CVE antes de etiquetar
• El agente propuso actualizaciones de dependencias sin análisis de la ruta de llamada
• Cumplimiento solicita evidencia SBOM del gráfico de módulos Go

Ejemplo de Trabajo

Paso 0 - Entorno

go version          # esperar 1.26.x según el pin de la pila
echo "$GOPROXY"     # documentar el proxy utilizado para la auditoría
go env GOMOD

Paso 1 - Ejecutar govulncheck

govulncheck -show verbose ./...

• Las vulnerabilidades solo en importaciones de prueba pueden reducir la prioridad según la política
• Ver Escaneo de Dependencias con govulncheck y SBOM

Paso 2 - Proponer pines (no aplicar)

# Sugerencia de salida de ejemplo - el humano ejecuta después de la aprobación
go get golang.org/x/crypto@v0.31.0
go mod tidy

Documentar por qué se necesita cada pin: CVE, ruta de llamada, riesgo de cambio disruptivo.

Paso 3 - Escaneo de licencias (opcional)

# Si el equipo usa syft o go-licenses - adaptar a tu cadena de herramientas
go list -m -json all | jq -r '.Path' | sort -u

Marcar módulos fuera de la lista de permitidos para revisión legal.

Paso 4 - Verificar

go test ./... -count=1
go mod verify
govulncheck ./...

Profundización

La Selección Mínima de Versión (MVS) significa que go get en un módulo puede traer pines transitivos.

La salida de la skill debe listar los cambios directos e indirectos de la diferencia de go list -m -u all.

Las directivas replace ocultan las versiones de los escáneres ingenuos: audita explícitamente el bloque replace de go.mod.

Los espacios de trabajo go work requieren ejecutar govulncheck desde cada módulo o raíz del espacio de trabajo según la convención del equipo.

Retractar en tu propio módulo: la skill debe verificar que no estás publicando versiones retractadas.

Posibles Problemas

• Falsos positivos cuando la vulnerabilidad está en una ruta de código inalcanzable; aún así documentar; seguridad puede anular.
• go get -u en módulos x/* relacionados con stdlib puede propagarse; fijar quirúrgicamente.
• El modo Vendor (-mod=vendor) necesita go mod vendor después de los pines; mencionarlo en la salida.
• Los módulos privados sin líneas de suma fallan go mod verify en CI; política separada.

Alternativas

Preguntas Frecuentes

Relacionados

• Fundamentos de las Skills de Agente - Estructura de SKILL.md
• Fundamentos de Paquetes y Módulos - Fundamentos de go.mod
• go.mod, go.sum y Selección Mínima de Versión - MVS
• Escaneo de Dependencias con govulncheck y SBOM - Referencia humana
• Gobernanza de Dependencias y Cumplimiento de Licencias - Política
• GitHub Actions para Repositorios Go - Integración CI

Versiones de la Pila: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea, modernizadores de go fix - verificar parche en la compilación), chi (última versión - verificar en la compilación), gin (última versión - verificar en la compilación), echo (última versión - verificar en la compilación), google.golang.org/grpc (última versión - verificar en la compilación), sigs.k8s.io/controller-runtime (última versión - verificar en la compilación), kubebuilder (última versión - verificar en la compilación), tinygo (última versión - verificar objetivos de placa en la compilación), wazero (última versión - verificar en la compilación) y golangci-lint (última versión - verificar conjunto de linters en la compilación).