getedgehq/security-audit-checklist

Lista de Verificación de Auditoría de Seguridad

Ejecute estas comprobaciones en cualquier sistema antes de enviarlo a producción o después de cambios importantes.

Antes de comenzar

La lista de verificación en sí es texto sin formato y no necesita nada. Los tres escáneres en scripts/ son Python, por lo que ejecutarlos requiere Python 3 en su máquina (python3 --version). Sin él, aún puede trabajar la lista de verificación manualmente; simplemente no obtiene el escaneo automatizado de secretos, la verificación de encabezados y la lectura de IaC.

1. Privacidad y Gobierno de Datos

• Existe una política de privacidad si la aplicación recopila, almacena o procesa datos de usuario. Enlace en el pie de página y en los flujos de registro.
• Sepa dónde se almacenan los datos del usuario: documente la base de datos principal, cachés, registros, copias de seguridad y servicios de terceros. Verifique los requisitos de residencia de datos (GDPR, CCPA).
• Minimización de datos: solo recopile lo que necesite. Elimine o anonimice los datos que no utilice.

2. Higiene de Secretos y Claves

• Los valores .env no se están filtrando: escanee todo el repositorio en busca de secretos codificados.
• Nunca exponga claves API en el código del frontend: sin claves en paquetes JS, sin valores sensibles en prefijos de entorno públicos (REACT_APP_, NEXT_PUBLIC_, VITE_).
• Mueva las claves al lado del servidor o detrás de un proxy: todas las llamadas API de terceros que requieran secretos deben pasar por un endpoint de backend.
• Elimine secretos de los registros: busque en registros y reportes de errores claves, tokens y contraseñas. Enmascárelos o redáctelos antes de la salida.
• Rote inmediatamente las credenciales filtradas si se encuentra algo.

Comandos de escaneo rápido:

# Ejecutar el escáner de secretos incluido
python3 scripts/scan_secrets.py .

# Patrones de ripgrep manual
grep -rE '(api[_-]?key|secret|token|password)\s*[:=]\s*["\047][a-zA-Z0-9_\-]{16,}' --include='*.{js,ts,py,go,rb,php,java,json,yaml,yml,env,sh,tf,hcl}' .
grep -rE 'AKIA[0-9A-Z]{16}' .  # Claves AWS
grep -rE 'ghp_[a-zA-Z0-9]{36}' .  # Tokens GitHub
grep -rE 'sk-[a-zA-Z0-9]{48}' .   # Claves OpenAI

3. Encabezados de Seguridad

• Content-Security-Policy restringe las fuentes de scripts y bloquea la ejecución en línea cuando sea posible.
• X-Frame-Options o frame-ancestors previene el clickjacking.
• Strict-Transport-Security fuerza HTTPS.
• X-Content-Type-Options: nosniff está presente.
• Referrer-Policy limita la fuga de referencias.

Verifique los encabezados en una URL en vivo:

python3 scripts/check_headers.py https://su-app.com

4. Fundamentos de OWASP Top 10

#	Riesgo	Qué verificar
A01	Control de Acceso Roto	Cada endpoint verifica autenticación y autorización. Sin errores IDOR.
A02	Fallos Criptográficos	Contraseñas con hash usando bcrypt/Argon2. TLS 1.2+ forzado. Sin datos sensibles en URLs.
A03	Inyección	SQL utiliza sentencias parametrizadas. Sin concatenación de cadenas en bruto en consultas.
A04	Diseño Inseguro	Límites de tasa en autenticación y acciones sensibles. La lógica de negocio tiene comprobaciones de abuso.
A05	Configuración Incorrecta de Seguridad	Credenciales predeterminadas eliminadas. Modo de depuración desactivado en producción. Los mensajes de error no filtran trazas de pila.
A06	Componentes Vulnerables	Auditoría de dependencias: npm audit, pip-audit, cargo audit, snyk test.
A07	Fallos de Autenticación	Los tokens de sesión son aleatorios y rotados al cambiar privilegios. MFA para cuentas sensibles.
A08	Integridad de Datos	Archivos de bloqueo presentes, commits firmados cuando sea posible.
A09	Fallos de Registro	Eventos de seguridad registrados sin secretos.
A10	SSRF	Las solicitudes del lado del servidor usan una lista blanca. Sin URLs controladas por el usuario que accedan a servicios internos.

5. Validación de Entrada e Inyección

• Inyección SQL: todas las consultas usan parámetros ORM o sentencias preparadas.
• XSS: la salida del usuario está escapada en HTML. dangerouslySetInnerHTML y omisiones similares son auditadas.
• Inyección de Comandos: sin exec(), system() o eval() con entrada del usuario.
• Path Traversal: las rutas de archivo están sanitizadas y restringidas a un directorio de lista blanca.
• Inyección NoSQL: las consultas MongoDB usan objetos parametrizados.

6. Seguridad de API

• Verifique las respuestas de API en busca de datos sensibles: sin IDs internos, hashes de contraseñas, tokens o PII innecesarios.
• Autenticación en todos los endpoints no públicos: sin rutas de administración o depuración abiertas.
• Límites de tasa antes de que alguien queme su factura de API: límites de tasa por IP y por usuario en endpoints costosos o de autenticación. Devuelva 429 con Retry-After.
• CORS es estricto: Access-Control-Allow-Origin no es *. Se requiere preflight para métodos que cambian el estado.

7. Autenticación y Sesión

• Política de contraseñas: mínimo 8 caracteres, sin longitud máxima que impida frases de paso.
• Protección contra fuerza bruta: retroceso exponencial o CAPTCHA después de intentos de inicio de sesión fallidos.
• Gestión de sesiones: cookies seguras, httpOnly, SameSite. JWTs con caducidad corta y rotación de actualización.
• Restablecimiento de contraseña: los tokens son de un solo uso, aleatorios y caducan rápidamente.

---

8. Seguridad del Proveedor de Nube

Aplica a AWS, GCP, Azure y cualquier otra plataforma en la nube.

8.1 Gestión de Identidad y Acceso (IAM)

• No existen claves de acceso de cuenta raíz. MFA de raíz está habilitado.
• Principio de mínimo privilegio: cada rol, usuario y cuenta de servicio tiene los permisos mínimos requeridos. Sin acciones o recursos comodín (*) a menos que sea absolutamente necesario.
• Sin claves de acceso de larga duración para usuarios. Prefiera roles IAM con credenciales temporales (STS, perfiles de instancia, identidad de carga de trabajo).
• MFA forzado para todos los usuarios humanos, especialmente administradores y acceso de facturación.
• Identidades inactivas eliminadas: elimine o deshabilite usuarios, roles y cuentas de servicio sin usar durante 90+ días.
• Acceso entre cuentas usa supuestos de roles explícitos con ID externo cuando sea aplicable. Sin políticas de confianza con Principal: *.

8.2 Almacenamiento (S3 / GCS / Azure Blob)

• Sin buckets/contenedores públicos a menos que se alojen intencionalmente activos públicos estáticos. Bloquee el acceso público a nivel de cuenta.
• Cifrado en reposo habilitado (AES-256 o KMS). Sin volúmenes de almacenamiento o instantáneas sin cifrar.
• Cifrado en tránsito forzado (solo HTTPS/TLS). Sin http permitido.
• Políticas de ciclo de vida eliminan o transicionan datos antiguos. Versionado habilitado para buckets críticos.
• Las políticas de bucket no otorgan Principal: * o AllUsers. El acceso es a través de roles IAM, no claves codificadas.
• Registro habilitado para registros de acceso y eventos a nivel de objeto (Registros de Acceso al Servidor S3, eventos de datos de CloudTrail).

8.3 Cómputo (EC2 / GCE / Azure VM / Lambda / Cloud Run)

• Sin grupos de seguridad predeterminados que permitan 0.0.0.0/0 en puertos sensibles (22, 3389, 3306, 5432, 6379, 27017).
• SSM / Session Manager usado en lugar de SSH directo cuando sea posible. Sin puerto 22 abierto a internet.
• IMDSv2 requerido en AWS EC2 (deshabilitar IMDSv1).
• Los metadatos de instancia no se exponen a contenedores o código no confiable.
• Tiempo de ejecución de la función utiliza privilegios mínimos. Lambda/GCP Cloud Functions no se ejecutan con roles de administrador.
• Las variables de entorno de la función no contienen secretos en texto plano. Use un administrador de secretos (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).

8.4 Base de Datos y Caché

• Sin acceso público: las bases de datos están en subredes privadas o VPCs. Sin 0.0.0.0/0 en grupos de seguridad.
• Cifrado en reposo y en tránsito habilitado.
• Copias de seguridad automatizadas con recuperación a un punto en el tiempo.
• Autenticación fuerte: sin contraseñas predeterminadas. Use autenticación de base de datos IAM o certificados de cliente TLS cuando sea compatible.
• Registro de auditoría habilitado para conexiones y cambios de esquema.

8.5 Redes

• VPC / segmentación de red: producción, preparación y desarrollo están en redes separadas o al menos en subredes separadas.
• Grupos de seguridad / cortafuegos son denegar por defecto. Solo los puertos requeridos están abiertos.
• Sin CIDRs excesivamente permisivos: se evita 0.0.0.0/0 excepto para HTTPS (443) en balanceadores de carga públicos.
• Subredes privadas para bases de datos, cachés y servicios internos. NAT Gateway o endpoints de VPC para internet saliente.
• Protección DDoS habilitada cuando sea aplicable (AWS Shield, Cloud Armor, Azure DDoS Protection).
• DNS / Dominio: DNSSEC habilitado si el registrador lo soporta. Sin registros DNS huérfanos que apunten a IPs caducadas o recursos eliminados (riesgo de toma de subdominio).

8.6 Registro, Monitoreo y Alertas

• CloudTrail / Registros de Auditoría / Registros de Actividad habilitados en todas las regiones y servicios.
• Integridad de registros: los registros son inmutables o se almacenan en una cuenta separada con permisos de escritura única.
• Datos sensibles no registrados: los registros en la nube no incluyen contraseñas, tokens o PII.
• Alertas configuradas para inicio de sesión de raíz, cambios en políticas IAM, creación de buckets públicos, cambios en grupos de seguridad y picos de autenticación fallida.
• Retención de registros cumple con los requisitos de cumplimiento (generalmente 1 año).

---

9. Seguridad de Contenedores y Orquestación

9.1 Docker / Imágenes de Contenedor

• Sin secretos en imágenes: escanee Dockerfiles y capas en busca de .env, config.json o credenciales codificadas.
• Imágenes base mínimas: use distroless, Alpine o scratch en lugar de Ubuntu/Debian completo cuando sea posible.
• No ejecutar como root: el Dockerfile establece USER a un UID/GID no root.
• Escaneo de imágenes: habilite el escaneo de vulnerabilidades en el registro (ECR, GCR, ACR, Docker Hub) y bloquee CVEs críticas en CI.
• Etiquetas inmutables: no use latest en producción. Fije a un digest o semver específico.
• Construcciones multi-etapa: los artefactos de construcción y las dependencias de desarrollo no terminan en la imagen final.

9.2 Kubernetes

• RBAC: roles y enlaces de roles con mínimos privilegios. Sin cluster-admin para cuentas de servicio.
• Sin tokens de cuenta de servicio predeterminados montados en pods que no los necesiten (automountServiceAccountToken: false).
• Políticas de red: denegación predeterminada de entrada/salida, luego permitir explícitamente el tráfico requerido.
• Estándares de seguridad de pods: aplique perfil restricted o baseline. Sin contenedores privilegiados, sin hostPath, sin hostNetwork.
• Cifrado de secretos: el cifrado de etcd en reposo está habilitado. Sin secretos en texto plano en Git.
• Seguridad en tiempo de ejecución del contenedor: perfiles seccomp, AppArmor o SELinux aplicados.
• Controladores de admisión: use OPA/Gatekeeper o Kyverno para aplicar políticas (sin etiqueta latest, etiquetas requeridas, límites de recursos).
• Límites de recursos: cada pod tiene límites de CPU y memoria para prevenir DoS por agotamiento de recursos.

---

10. Infraestructura como Código (IaC)

• Sin secretos en Terraform / CloudFormation / Pulumi / CDK: los archivos de estado no contienen contraseñas o claves en texto plano. El estado remoto está cifrado y controlado por acceso.
• El backend de estado de Terraform es seguro: S3 con SSE-KMS, bloqueo DynamoDB y sin acceso de lectura público.
• Escaneo de IaC: ejecute checkov, tfsec o terrascan en Terraform/CloudFormation antes de fusionar.
• Detección de desviación: escaneos programados detectan cambios manuales en la consola que se desvían de IaC.
• Los módulos tienen versiones fijas: no extraiga módulos de ramas o fuentes sin versionar.

Escaneo rápido de IaC:

python3 scripts/scan_iac.py .

# O use herramientas dedicadas si están instaladas:
checkov -d . --framework terraform,cloudformation,dockerfile
# tfsec .

---

11. Seguridad de Pipeline CI/CD

• Sin secretos en configuraciones de pipeline: sin tokens codificados en .github/workflows, .gitlab-ci.yml, Azure Pipelines o Jenkinsfiles.
• Los secretos se inyectan desde el administrador de secretos nativo de la plataforma CI (GitHub Secrets, GitLab CI Variables, Azure DevOps Library).
• Los permisos del pipeline son mínimos: las cuentas de servicio de CI tienen solo los permisos necesarios para desplegar.
• Protección de ramas: los envíos directos a main/master están bloqueados. Todos los cambios requieren PR/MR + revisión.
• Commits firmados o requisitos de fusión: requiera commits firmados o al menos commits de fusión verificados para repositorios sensibles.
• Escaneo de dependencias: las herramientas SCA (Snyk, Dependabot, Renovate) se ejecutan en cada PR.
• SAST: el análisis estático (Semgrep, CodeQL, SonarQube) se ejecuta en cada PR.
• Escaneo de contenedores: las imágenes se escanean en busca de CVEs antes del despliegue.
• Sin ejecutores auto-alojados expuestos a internet pública sin VPN o lista blanca de IPs.
• El pipeline no ejecuta código no confiable de forks sin aprobación manual (prevenir pwn requests).

---

12. Seguridad de Dominio y DNS

• DNSSEC habilitado en el registrador si es compatible.
• Sin registros CNAME / A / NS huérfanos que apunten a servicios caducados (riesgo de toma de subdominio).
• Certificados comodín o certificados por materia de una CA confiable. Sin certificados autofirmados en producción.
• Monitoreo de caducidad de certificados: alertas 30 y 7 días antes de la caducidad.
• CDN / WAF configurado con reglas sensatas (bloqueos de SQLi, XSS, LFI). Límites de tasa habilitados en el borde.

---

Salida de Auditoría

Después de ejecutar la lista de verificación, produzca un informe conciso en markdown con:

1. Resumen — Aprobado / Fallido / Necesita Revisión por categoría.
2. Hallazgos críticos — Cualquier cosa que deba corregirse antes de producción.
3. Correcciones recomendadas — Cambios de código específicos, actualizaciones de configuración o actualizaciones de bibliotecas.
4. Matriz de riesgo — Probabilidad × Impacto para cada hallazgo.
5. Cronograma de remediación — Sugiera orden de prioridad y plazos.