Dos conjuntos de reglas separados, no uno
Este es el detalle que la mayoría de comparativas omite: la higiene de Dockerfile y la seguridad de pipelines CI/CD son dos categorías de reglas distintas con estados por defecto diferentes. Equivocarse aquí significa o bien perder una cobertura que se daba por hecha, o llevarse una sorpresa cuando un escaneo no reporta algo.
Higiene de Dockerfile — activa por defecto
Las reglas generales de Dockerfile viven bajo la categoría SECURITY, activadas en cada escaneo sin configuración:
| Regla | Severidad | Qué detecta |
|---|---|---|
| dockerfile_root_user | HIGH | Sin directiva USER — el contenedor se ejecuta como root por defecto. |
| dockerfile_copy_all | MEDIUM | COPY . . incorpora todo el contexto de build a la imagen, incluyendo .env, credenciales, claves SSH. |
| dockerfile_unpinned_base | MEDIUM | Imagen base no fijada a una versión específica. |
Reglas de pipeline CI/CD — opcionales, desactivadas por defecto
Este es el punto que vale la pena precisar: las 38 reglas que inspeccionan el contenido de .github/workflows/*.yml y .gitlab-ci.yml — inyección de expresiones, alcance de permisos, acciones sin fijar, y la regla de abajo — se agrupan bajo una categoría CICD separada, desactivada por defecto, del mismo modo que el escaneo de dependencias necesita --with-deps. No hay flag de CLI para ello; es un ajuste de configuración.
Actívelo en audit.config.json:
"categories": {
"cicd": { "enabled": true, "weight": 2 }
}Configúrelo antes del primer escaneo de un proyecto (o limpie la caché de reglas con --no-cache una vez si lo activa en un proyecto ya escaneado) — luego ejecute normalmente.
| Regla | Severidad | Qué detecta |
|---|---|---|
| pull_request_target_checkout | HIGH | pull_request_target combinado con un checkout del head del fork — permite que un PR bifurcado ejecute código con acceso de escritura y a los secretos. |
| unpinned_action_version | MEDIUM | Una acción referenciada por rama o tag (@main, @v4) en lugar de un SHA de commit completo. |
| gha_missing_permissions | LOW | El workflow no tiene un bloque permissions: explícito, cayendo en un acceso más amplio del necesario. |
| docker_latest_tag | LOW | Una clave image: en YAML de CI fijada a :latest — nota: esto coincide con la clave YAML image:/from:, no con una línea FROM de Dockerfile (una regla distinta, de lenguaje Dockerfile, no incluida actualmente). |
| workflow_not_in_codeowners | LOW | Archivos de workflow no cubiertos por una entrada CODEOWNERS, por lo que los cambios en la lógica CI no requieren un revisor específico. |
38 reglas en total en esta categoría — la tabla de arriba es una muestra, no la lista completa.
Un ejemplo real, de principio a fin
on: pull_request_target
jobs:
build:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}on: pull_request
jobs:
build:
steps:
- uses: actions/checkout@v4La solución aquí no es un ajuste de parámetro — es cambiar el evento disparador. pull_request_target se ejecuta con los permisos y secretos del repositorio base incluso para PRs bifurcados; pull_request no. Si realmente se necesitan operaciones privilegiadas tras revisión, la propia guía de la regla es separarlas en un job workflow_run distinto en lugar de añadir un paso de checkout al job pull_request_target.
Preguntas frecuentes
¿Por qué el escaneo CI/CD es opcional en vez de estar siempre activo?
La misma razón por la que el escaneo de dependencias necesita --with-deps: no todos los proyectos tienen un .github/workflows o .gitlab-ci.yml para empezar, y escanear archivos YAML/pipeline por defecto en cada proyecto no reportaría ningún hallazgo (a la vez que costaría tiempo de escaneo) para los que no usan CI/CD en absoluto. La activación opcional mantiene el escaneo por defecto centrado en el código fuente de la aplicación.
¿docker_latest_tag detecta la línea FROM de un Dockerfile?
No — su patrón coincide con una clave YAML image: o from: (la sintaxis usada en las definiciones de jobs de .gitlab-ci.yml), no con la línea FROM node:latest de un Dockerfile, que no lleva dos puntos tras la instrucción. Es una distinción real y verificada, no una advertencia añadida por efecto — las dos sintaxis son lo bastante distintas como para que un solo patrón no cubra ambas.
¿Activar CICD también cambia el escaneo de Dockerfiles?
No — las reglas de higiene de Dockerfile (usuario root, COPY . ., imagen base sin fijar) están en la categoría SECURITY, siempre activa, independientemente del ajuste CICD. Activar CICD solo añade las reglas específicas de YAML de pipeline encima.
¿Es la misma detección que el linting de workflows propio de GitHub?
No — las herramientas propias de GitHub verifican la validez sintáctica del workflow. Estas reglas verifican patrones específicos y conocidos como peligrosos (escalada de privilegios vía pull_request_target, riesgo de cadena de suministro por acciones sin fijar) que un workflow sintácticamente válido puede seguir conteniendo.
Véalo en un pipeline real
Abra el informe de demostración en vivo — sin instalación, sin registro — o active la categoría CICD en su propio proyecto y escanéelo.
Abrir el informe en vivo Ver la referencia de CLI