Lab: Detección y Prevención de Fugas de Secretos en Pipelines CI/CD

por

Descripción General

Las fugas de secretos en los pipelines CI/CD son la causa número uno de compromiso de pipelines. Las credenciales expuestas — claves API, contraseñas de bases de datos, tokens de acceso a la nube — proporcionan a los atacantes un camino directo hacia los sistemas de producción. Según el informe State of Secrets Sprawl 2025 de GitGuardian, se detectaron más de 12 millones de nuevos secretos en commits públicos de GitHub en un solo año.

El problema no es que los desarrolladores sean descuidados. Es que la entrega moderna de software involucra decenas de archivos de configuración, variables de entorno y puntos de integración donde los secretos pueden terminar accidentalmente en el control de versiones. Una sola clave AWS filtrada puede costar a una organización decenas de miles de dólares en minutos.

Este laboratorio práctico te guía a través de la configuración de una estrategia de detección de secretos multicapa que cubre tres puntos de control críticos:

  • Escaneo pre-commit — Detecta secretos antes de que lleguen al repositorio.
  • Escaneo en el pipeline — Bloquea pull requests y pushes que contengan secretos.
  • Escaneo post-commit y en tiempo de ejecución — Detecta secretos que se filtran y activa la remediación.

Al finalizar este laboratorio, tendrás una configuración funcional de defensa en profundidad utilizando gitleaks, truffleHog, GitHub secret scanning y reglas de detección personalizadas.

Requisitos Previos

Antes de comenzar, asegúrate de tener lo siguiente:

  • Git 2.30+ instalado y configurado.
  • Python 3.8+ con pip disponible.
  • Docker (opcional, pero recomendado para escaneo en contenedores).
  • Una cuenta de GitHub con acceso para crear repositorios (necesario para el ejercicio de GitHub secret scanning).
  • Una terminal (macOS, Linux o WSL en Windows).

No se necesitan secretos reales ni cuentas en la nube. Utilizaremos secretos de prueba plantados intencionalmente a lo largo de este laboratorio.

Configuración del Entorno

Paso 1: Crear un Repositorio de Prueba

Comienza creando un repositorio Git nuevo que utilizaremos para todos los ejercicios:

mkdir secret-leak-lab && cd secret-leak-lab
git init
echo "# Secret Leak Detection Lab" > README.md
git add README.md
git commit -m "Initial commit"

Paso 2: Plantar Secretos de Prueba Intencionales

Necesitamos secretos realistas (pero falsos) en varias ubicaciones para simular un escenario del mundo real. Crea los siguientes archivos:

Un archivo .env con credenciales de base de datos:

cat > .env <<'EOF'
DB_HOST=localhost
DB_PORT=5432
DB_USER=admin
DB_PASSWORD=SuperSecret123!
DB_NAME=production_db
SECRET_KEY=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
EOF

Un script Python con una clave AWS codificada directamente:

cat > deploy.py <<'EOF'
import boto3

# WARNING: These are intentionally fake credentials for testing
AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

def deploy_to_s3(bucket, file_path):
    s3 = boto3.client(
        's3',
        aws_access_key_id=AWS_ACCESS_KEY_ID,
        aws_secret_access_key=AWS_SECRET_ACCESS_KEY
    )
    s3.upload_file(file_path, bucket, file_path)
    print(f"Deployed {file_path} to s3://{bucket}")

if __name__ == "__main__":
    deploy_to_s3("my-app-bucket", "dist/app.zip")
EOF

Un archivo YAML de configuración con una cadena de conexión a base de datos:

cat > config.yml <<'EOF'
app:
  name: my-application
  environment: production

database:
  url: "postgresql://admin:SuperSecret123!@db.example.com:5432/prod"
  pool_size: 10

redis:
  url: "redis://:MyRedisPassword@cache.example.com:6379/0"
EOF

Un Dockerfile con una clave API en una instrucción ENV:

cat > Dockerfile <<'EOF'
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

# WARNING: Never do this in production
ENV API_KEY=sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx234
ENV STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc

COPY . .
CMD ["python", "app.py"]
EOF

Paso 3: Verificar el Estado "Antes"

En este punto, nada impide que estos secretos sean commiteados:

git add -A
git status

Git prepara todo felizmente, secretos incluidos. No hay hooks, ni escaneo, ni barreras de protección. Este es el estado en el que la mayoría de los repositorios comienzan. Nuestro objetivo es cambiar eso.

# Resetear el staging para poder probar el escaneo antes de commitear
git reset HEAD

Ejercicio 1: Escaneo Pre-commit con gitleaks

Gitleaks es una herramienta de código abierto diseñada para detectar secretos codificados directamente en repositorios Git. Soporta el escaneo del directorio de trabajo, el historial de commits y puede ejecutarse como un hook pre-commit para bloquear secretos antes de que sean commiteados.

Instalar gitleaks

Elige tu método de instalación preferido:

# macOS (Homebrew)
brew install gitleaks

# Docker
docker pull zricethezav/gitleaks:latest

# Go (desde el código fuente)
go install github.com/gitleaks/gitleaks/v8@latest

Verifica la instalación:

gitleaks version

Ejecutar gitleaks Manualmente

Escanea el directorio de trabajo en busca de secretos:

gitleaks detect --source . -v

Deberías ver una salida similar a la siguiente:

Finding:     AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
Secret:      AKIAIOSFODNN7EXAMPLE
RuleID:      aws-access-key-id
Entropy:     3.52
File:        deploy.py
Line:        4

Finding:     AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
Secret:      wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
RuleID:      aws-secret-access-key
Entropy:     4.71
File:        deploy.py
Line:        5

Finding:     DB_PASSWORD=SuperSecret123!
Secret:      SuperSecret123!
RuleID:      generic-credential
Entropy:     3.40
File:        .env
Line:        4

Finding:     STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc
Secret:      sk_live_4eC39HqLyjWDarjtT1zdp7dc
RuleID:      stripe-secret-key
Entropy:     4.20
File:        Dockerfile
Line:        9

12:14PM INF 6 commits scanned.
12:14PM WRN leaks found: 6

Gitleaks identifica correctamente claves AWS, credenciales genéricas, claves de Stripe y más. Cada hallazgo incluye el archivo, el número de línea y la regla de detección que lo activó.

Configurar gitleaks como Hook Pre-commit

El framework pre-commit facilita la ejecución automática de gitleaks antes de cada commit. Primero, instala pre-commit:

pip install pre-commit

Crea un archivo .pre-commit-config.yaml en la raíz de tu repositorio:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

Instala el hook:

pre-commit install

Probar el Hook: Commitear un Secreto (Bloqueado)

git add deploy.py
git commit -m "Add deployment script"

El commit es bloqueado:

Detect hardcoded secrets.................................................Failed
- hook id: gitleaks
- exit code: 1

12:15PM WRN leaks found: 2

El hook pre-commit detiene el commit por completo. El secreto nunca llega al historial de Git.

Probar el Hook: Commitear Código Limpio (Pasa)

Crea un archivo sin secretos:

cat > utils.py <<'EOF'
def format_date(date_obj):
    return date_obj.strftime("%Y-%m-%d")

def sanitize_input(user_input):
    return user_input.strip().replace("<", "<").replace(">", ">")
EOF

git add utils.py
git commit -m "Add utility functions"

Salida:

Detect hardcoded secrets.................................................Passed
[main abc1234] Add utility functions
 1 file changed, 5 insertions(+)

El código limpio pasa sin problemas.

Ejercicio 2: Escaneo en el Pipeline con gitleaks en GitHub Actions

Los hooks pre-commit son una primera capa sólida, pero se ejecutan localmente y pueden ser eludidos. El escaneo en el pipeline añade una capa de aplicación del lado del servidor que no puede ser omitida.

Crear el Workflow de GitHub Actions

Crea el archivo .github/workflows/secret-scan.yml con el siguiente contenido:

name: Secret Scanning

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  gitleaks:
    name: Detect Secrets with gitleaks
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

El parámetro fetch-depth: 0 es crítico — asegura que el historial completo de Git esté disponible para que gitleaks pueda escanear todos los commits, no solo el más reciente.

Cómo Funciona en la Práctica

Escenario A: Un PR con un secreto filtrado. Un desarrollador agrega accidentalmente una clave API a un archivo de configuración y abre un pull request. La acción de gitleaks escanea el diff, detecta el secreto y marca la verificación como fallida. El PR no puede fusionarse hasta que se elimine el secreto.

Escenario B: Un PR limpio. Un desarrollador abre un PR con lógica de aplicación y sin secretos. La acción de gitleaks escanea el diff, no encuentra nada y marca la verificación como aprobada. El PR puede proceder a la revisión de código y fusión.

Para aplicar esto, ve a la configuración de tu repositorio Settings → Branches → Branch protection rules y agrega gitleaks como verificación de estado requerida para la rama main. Esto evita que alguien fusione un PR que falle el escaneo de secretos.

Ejercicio 3: Escaneo en el Pipeline con truffleHog

TruffleHog adopta un enfoque diferente para la detección de secretos. Además de la coincidencia de patrones, puede verificar si los secretos detectados están realmente activos probándolos contra la API del servicio correspondiente.

Instalar truffleHog

# pip
pip install trufflehog

# Docker
docker pull trufflesecurity/trufflehog:latest

# Homebrew
brew install trufflehog

Ejecutar truffleHog Contra el Repositorio de Prueba

# Escanear el repositorio local
trufflehog git file://. --only-verified

La bandera --only-verified le indica a truffleHog que solo reporte secretos que ha confirmado como activos. Esto reduce drásticamente los falsos positivos. Si deseas ver todos los hallazgos, incluyendo los no verificados, omite la bandera:

# Mostrar todos los hallazgos (verificados y no verificados)
trufflehog git file://.

Verificado vs. No Verificado: Un secreto verificado es aquel que truffleHog ha probado contra la API del proveedor y ha confirmado que está activo. Por ejemplo, intentará autenticarse con una clave AWS para ver si funciona. Un secreto no verificado coincide con un patrón conocido pero no se ha confirmado como activo — podría ser una clave revocada, un marcador de posición o un falso positivo.

Crear un Job de Pipeline en GitLab CI

TruffleHog se integra bien en GitLab CI. Agrega lo siguiente a tu .gitlab-ci.yml:

stages:
  - security

secret-scan:
  stage: security
  image:
    name: trufflesecurity/trufflehog:latest
    entrypoint: [""]
  script:
    - trufflehog git file://. --fail --json > trufflehog-results.json
  artifacts:
    when: always
    paths:
      - trufflehog-results.json
    expire_in: 30 days
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

La bandera --fail hace que truffleHog salga con un código de estado distinto de cero si se encuentran secretos, lo que hace fallar el pipeline. La bandera --json genera resultados estructurados que pueden ser analizados por otras herramientas o dashboards.

gitleaks vs. truffleHog: Cuándo Usar Cada Uno

Característica gitleaks truffleHog
Método de detección Regex + entropía Regex + entropía + verificación
Verificación de secretos No Sí (verifica si el secreto está activo)
Velocidad Muy rápido Más lento (debido a la verificación)
Tasa de falsos positivos Moderada Baja (con --only-verified)
Reglas personalizadas Sí (.gitleaks.toml) Sí (detectores personalizados)
Soporte pre-commit Nativo Mediante script wrapper
Ideal para Verificaciones rápidas pre-commit y PR Escaneos profundos y verificación

Recomendación: Usa gitleaks para hooks pre-commit rápidos y verificaciones de PR. Usa truffleHog para escaneos profundos periódicos y cuando necesites resultados verificados para priorizar la remediación.

Ejercicio 4: GitHub Secret Scanning y Push Protection

GitHub ofrece escaneo de secretos integrado que funciona a nivel de plataforma. A diferencia de gitleaks y truffleHog, que instalas y configuras tú mismo, GitHub secret scanning está integrado directamente en la configuración del repositorio.

Habilitar Secret Scanning

  1. Ve a tu repositorio en GitHub.
  2. Navega a Settings → Code security and analysis.
  3. Habilita Secret scanning.
  4. Habilita Push protection.

Push protection es la característica clave aquí. Cuando está habilitada, GitHub bloqueará cualquier push que contenga un patrón de secreto reconocido antes de que llegue al repositorio.

Probar Push Protection

Intenta hacer push de un commit que contenga un patrón de secreto conocido, como una clave de acceso AWS o un token de acceso personal de GitHub:

# Preparar y commitear un archivo con un secreto de prueba
git add deploy.py
git commit -m "Add deploy script"
git push origin main

GitHub bloquea el push con un mensaje como:

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote:
 remote: - GITHUB PUSH PROTECTION
remote:   ——————————————————————————————————————————
remote:     Resolve the following violations before pushing again
remote:
remote:     — Push cannot contain secrets —
remote:
remote:
remote:      (?) To push, remove secret from commit(s) or follow this URL to allow the secret.
remote:
remote:      — Amazon AWS Access Key ID —
remote:        locations:
 remote:          - commit: abc1234def5678
 remote:            path: deploy.py:4
remote:
! [remote rejected] main -> main (push rule violations)
error: failed to push some refs

Manejo de Falsos Positivos

Si GitHub marca un valor que no es un secreto real (por ejemplo, un dato de prueba o un ejemplo de documentación), puedes eludir la protección de push con una razón. GitHub proporciona una URL en el mensaje de rechazo donde puedes:

  • Seleccionar una razón de omisión: "Se usa en pruebas", "Es un falso positivo", o "Lo arreglaré después".
  • Enviar la omisión, lo que permite el push pero registra el evento para auditoría.

Los administradores de la organización pueden ver todas las omisiones en el dashboard Security → Secret scanning.

El Programa de Socios

GitHub se asocia con más de 200 proveedores de servicios (AWS, Stripe, Twilio, SendGrid y otros) a través de su programa de socios de escaneo de secretos. Cuando se detecta un secreto de un socio:

  1. GitHub notifica al proveedor del servicio automáticamente.
  2. El proveedor revoca la credencial comprometida.
  3. El propietario del repositorio es notificado por correo electrónico y en la pestaña Security.

Esto significa que incluso si un secreto pasa todas las demás defensas y llega a un repositorio público, la ventana de daño puede reducirse a minutos mediante la revocación automática.

Ejercicio 5: Patrones de Secretos Personalizados

Las reglas de detección predeterminadas cubren proveedores comunes (AWS, Stripe, GitHub, Google Cloud, etc.), pero la mayoría de las organizaciones también tienen secretos internos con formatos personalizados que las herramientas estándar no detectarán. Gitleaks soporta reglas personalizadas a través de un archivo de configuración .gitleaks.toml.

Crear una Configuración Personalizada de gitleaks

Crea un archivo .gitleaks.toml en la raíz del repositorio:

[extend]
# Extend the default gitleaks configuration
# useDefault = true

[[rules]]
id = "mycompany-api-key"
description = "MyCompany Internal API Key"
regex = '''MYCOMPANY-KEY-[A-Za-z0-9]{32}'''
tags = ["internal", "api-key"]
keywords = ["mycompany-key"]

[[rules]]
id = "internal-database-url"
description = "Internal Database Connection String"
regex = '''postgresql://[^:]+:[^@]+@internal-db\.[a-z0-9-]+\.corp\.[a-z]+\.com'''
tags = ["internal", "database"]
keywords = ["internal-db"]

[[rules]]
id = "internal-jwt-signing-key"
description = "Internal JWT Signing Key"
regex = '''JWT_SIGNING_KEY=[A-Za-z0-9+/=]{64,}'''
tags = ["internal", "jwt"]
keywords = ["jwt_signing_key"]

[allowlist]
description = "Global allowlist"
paths = [
  '''(.*?)test(.*?)\.py''',
  '''(.*?)_test\.go''',
  '''(.*?)spec(.*?)\.js''',
  '''(.*?)fixtures(.*?)''',
  '''README\.md'''
]

[[rules.allowlist]]
id = "mycompany-api-key"
regexes = [
  '''MYCOMPANY-KEY-EXAMPLE[A-Za-z0-9]{24}''',
  '''MYCOMPANY-KEY-TEST[A-Za-z0-9]{28}'''
]

Entendiendo la Configuración

  • Reglas personalizadas: Las secciones [[rules]] definen patrones específicos de tu organización. El campo regex utiliza expresiones regulares compatibles con Go. El campo keywords ayuda a gitleaks a filtrar archivos rápidamente — solo los archivos que contienen la palabra clave son escaneados con la expresión regular completa, lo que mejora el rendimiento.
  • Lista de permitidos global: La sección [allowlist] define rutas que deben excluirse de todo escaneo. Los archivos de prueba, fixtures y documentación son exclusiones comunes.
  • Lista de permitidos por regla: La sección [[rules.allowlist]] define excepciones para reglas específicas. Aquí, excluimos claves de ejemplo conocidas que aparecen en documentación o helpers de prueba.

Probar la Configuración Personalizada

Crea un archivo con un secreto personalizado para probar:

cat > internal-config.py <<'EOF'
MYCOMPANY_API_KEY = "MYCOMPANY-KEY-a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
EOF

Ejecuta gitleaks con la configuración personalizada:

gitleaks detect --source . --config .gitleaks.toml -v

La regla personalizada detecta la clave API interna que habría sido pasada por alto por las reglas predeterminadas.

Construyendo una Estrategia de Defensa en Profundidad

Ninguna capa individual de detección de secretos es suficiente. Los desarrolladores pueden omitir los hooks pre-commit. Los escaneos del pipeline solo capturan secretos en el momento del PR. GitHub push protection solo cubre patrones de proveedores conocidos. Una estrategia robusta combina todas estas capas.

Las Cinco Capas de Defensa de Secretos

┌─────────────────────────────────────────────────────┐
│  Capa 1: Hook Pre-commit (gitleaks)                 │
│  → Captura secretos antes de que entren al historial│
├─────────────────────────────────────────────────────┤
│  Capa 2: Escaneo de PR / Merge Request (gitleaks)   │
│  → Bloquea PRs que contengan secretos               │
├─────────────────────────────────────────────────────┤
│  Capa 3: Push Protection (GitHub / GitLab)          │
│  → Bloqueo a nivel de plataforma de patrones conocidos│
├─────────────────────────────────────────────────────┤
│  Capa 4: Escaneo Post-merge (truffleHog programado) │
│  → Escaneo profundo semanal con verificación        │
├─────────────────────────────────────────────────────┤
│  Capa 5: Monitoreo en Tiempo de Ejecución (vault)   │
│  → Detecta anomalías en el uso de secretos en prod  │
└─────────────────────────────────────────────────────┘

Por Qué Ninguna Capa Individual Es Suficiente

  • Los hooks pre-commit pueden ser eludidos con git commit --no-verify o usando un cliente Git que no soporte hooks.
  • Los escaneos del pipeline solo se ejecutan en ramas que activan CI — los pushes directos a ramas no protegidas o los force pushes pueden omitirlos.
  • Push protection solo detecta patrones de proveedores conocidos — los secretos internos personalizados no están cubiertos.
  • Los escaneos post-merge son reactivos — encuentran secretos después de que ya están en el repositorio.

Cada capa compensa las debilidades de las otras. Juntas, crean un sistema donde un secreto necesitaría eludir las cinco capas para pasar desapercibido.

Workflow Combinado: Escaneo de PR y Escaneo Completo Semanal

Aquí tienes un workflow combinado de GitHub Actions que ejecuta gitleaks en cada PR y realiza un escaneo completo del repositorio semanalmente:

name: Secret Scanning (Multi-Layer)

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    # Escaneo completo del repositorio cada lunes a las 6:00 AM UTC
    - cron: '0 6 * * 1'

jobs:
  # Capa 2: Escaneo de PR y push
  gitleaks-pr-scan:
    name: gitleaks PR Scan
    runs-on: ubuntu-latest
    if: github.event_name == 'push' || github.event_name == 'pull_request'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run gitleaks (diff scan)
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  # Capa 4: Escaneo profundo semanal con truffleHog
  trufflehog-full-scan:
    name: truffleHog Full Repository Scan
    runs-on: ubuntu-latest
    if: github.event_name == 'schedule'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install truffleHog
        run: pip install trufflehog

      - name: Run truffleHog (full scan with verification)
        run: |
          trufflehog git file://. --fail --json > trufflehog-results.json || true
          if [ -s trufflehog-results.json ]; then
            echo "::error::Secrets detected in repository. See trufflehog-results.json."
            cat trufflehog-results.json | python -m json.tool
            exit 1
          fi

      - name: Upload scan results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: trufflehog-results
          path: trufflehog-results.json
          retention-days: 90

Este workflow asegura que cada cambio de código sea escaneado en tiempo real, y que todo el historial del repositorio sea auditado semanalmente en busca de secretos que puedan haberse pasado por alto.

Limpieza

Después de completar el laboratorio, elimina los secretos de prueba y reinicia el repositorio:

# Eliminar archivos de prueba con secretos
rm -f .env deploy.py config.yml Dockerfile internal-config.py

# Eliminar configuraciones de prueba (opcional — consérvelas si desea reutilizarlas)
# rm -f .gitleaks.toml .pre-commit-config.yaml

# Commitear la limpieza
git add -A
git commit -m "Remove test secrets from lab exercises"

# Si deseas eliminar completamente los secretos del historial de Git,
# usa git-filter-repo (más exhaustivo que git filter-branch):
pip install git-filter-repo
git filter-repo --invert-paths --path deploy.py --path .env --path config.yml --path Dockerfile

Importante: Simplemente eliminar archivos no los remueve del historial de Git. Cualquier persona con acceso al repositorio aún puede encontrar los secretos en commits anteriores. Usa git-filter-repo para reescribir el historial y eliminar permanentemente los archivos sensibles. Después de reescribir el historial, haz force-push al remoto y pide a todos los colaboradores que vuelvan a clonar el repositorio.

Conclusiones Clave

  • Los secretos en CI/CD son el vector de ataque más común para el compromiso de pipelines. Una sola credencial filtrada puede dar a un atacante acceso completo a la infraestructura de producción.
  • Los hooks pre-commit con gitleaks proporcionan el ciclo de retroalimentación más rápido. Los desarrolladores son alertados inmediatamente, antes de que el secreto entre en el historial de Git.
  • El escaneo en el pipeline es una capa de aplicación obligatoria. No puede ser eludida por los desarrolladores y asegura que ningún PR con secretos sea fusionado.
  • La capacidad de verificación de truffleHog reduce los falsos positivos drásticamente. Úsalo para escaneos profundos programados donde la precisión importa más que la velocidad.
  • GitHub push protection y el programa de socios agregan defensa a nivel de plataforma que funciona sin ninguna configuración en tus pipelines CI/CD.
  • Las reglas de detección personalizadas son esenciales para capturar secretos específicos de la organización que las herramientas estándar pasarán por alto. Invierte tiempo en escribir reglas para los formatos de claves internos de tu organización.
  • La defensa en profundidad es la única estrategia confiable. Ninguna herramienta o capa individual lo detecta todo. Combina pre-commit, escaneo en el pipeline, push protection, escaneos programados y monitoreo en tiempo de ejecución para una cobertura integral.

Próximos Pasos

Ahora que puedes detectar y prevenir fugas de secretos, el siguiente paso es eliminar los secretos codificados directamente adoptando una gestión adecuada de secretos: