Detección de Secretos (Secret Scanning)

ETAPA 01 · SECRETOS

¿QUÉ ES Y POR QUÉ ES CRUCIAL?

El escaneo de secretos busca prevenir que credenciales sensibles (claves de bases de datos, tokens de AWS, llaves privadas SSH, tokens de API) queden almacenadas en el historial de commits de Git. Un dev puede borrar el archivo .env en su último commit, pero Git conserva TODO el historial y los diffs anteriores.

⚠️ RIESGOS Y AMENAZAS EN ESTA ETAPA:

Filtración de passwords de producción en repositorios públicos o privados.
Compromiso de cuentas Cloud (AWS/GCP/Azure) por exposición de Access Keys.
Exfiltración de tokens de paquetes (npm/PyPI/NuGet) para infectar la cadena de suministro.

🧰 CATÁLOGO DE HERRAMIENTAS DESTACADAS

Gitleaks

Open Source (MIT)

Mantenido por: Gitleaks (proyecto independiente, ex-Zricethezav)

Herramienta SAST ligera de código abierto, escrita en Go, optimizada para detectar secretos y claves API no cifradas en repositorios Git usando reglas regex y detección de entropía.

$ gitleaks detect --source . --verbose

🔗 VER REPOSITORIO OFICIAL

Trufflehog

Open Source (AGPL-3.0) / Enterprise

Mantenido por: Truffle Security Co.

Escanea el historial completo de Git (y S3, GitHub, Slack, Docker, etc.) buscando cadenas de alta entropía, con más de 800 detectores que verifican activamente si la credencial encontrada sigue siendo válida contra la API real del proveedor.

$ trufflehog git file://. --only-verified

🔗 VER REPOSITORIO OFICIAL

Git-secrets

Open Source (Apache-2.0)

Mantenido por: AWS Labs

Instala git hooks (pre-commit, commit-msg) que bloquean un commit o push si detecta patrones de secretos conocidos (ej. AWS Access Key ID) antes de que lleguen al historial.

$ git secrets --scan

🔗 VER REPOSITORIO OFICIAL

Detect-secrets

Open Source (Apache-2.0)

Mantenido por: Yelp

Crea un archivo baseline (.secrets.baseline) con los hallazgos ya auditados como falsos positivos, e inspecciona sólo los deltas de código nuevo en cada corrida, evitando alertas repetitivas en pipelines de CI.

$ detect-secrets scan > .secrets.baseline

🔗 VER REPOSITORIO OFICIAL

🔧 INTEGRACIÓN EN PIPELINES DE CI/CD

Ejemplos listos para copiar y adaptar. El objetivo es que el job falle (exit code ≠ 0) y bloquee el merge/deploy cuando aparece un hallazgo de severidad alta -- ese es el "gate" real de DevSecOps.

🐙 GITHUB ACTIONS

.github/workflows/*.yml

name: secret-scanning
on: [push, pull_request]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # historial completo: gitleaks audita todos los commits
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Falla el job automáticamente (exit code != 0) si se detecta un secreto

🔷 AZURE DEVOPS

azure-pipelines.yml

trigger:
  - main
pr:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - checkout: self
    fetchDepth: 0  # historial completo para el análisis de gitleaks

  - script: |
      curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/master/install.sh | sh -s -- -b /usr/local/bin
      gitleaks detect --source . --verbose --exit-code 1
    displayName: 'Gitleaks - Secret Scanning'

💡 BUENAS PRÁCTICAS PARA INTEGRACIÓN EN CI/CD

Implementar hooks de pre-commit para evitar que el secreto ingrese al historial local.
Ejecutar Gitleaks o Trufflehog en el pipeline de CI/CD como paso de bloqueo (fail the build).
Rotar inmediatamente cualquier credencial que haya sido commiteada a Git, incluso si el repo es privado -- borrar el commit no invalida la credencial.