Saltar al contenido principal

Gitleaks

GitLeaks es una herramienta de seguridad utilizada en el ámbito de DevOps para detectar información confidencial y potencialmente comprometedora en repositorios de Git. Su objetivo principal es prevenir la filtración de datos sensibles, como contraseñas, claves de API y otros secretos, que podrían ser accidentalmente expuestos en el historial de versiones de un repositorio Git.

Características​

  • Búsqueda de patrones sensibles: GitLeaks busca patrones de datos sensibles utilizando reglas predefinidas o personalizadas. Estas reglas pueden incluir patrones de contraseñas, claves de API, tokens de autenticación y otros datos confidenciales.
  • Análisis exhaustivo del historial: La herramienta escanea el historial completo de commits en un repositorio Git, lo que incluye cambios antiguos y nuevos. Esto permite identificar y corregir datos sensibles que podrían haber sido agregados en versiones anteriores.
  • Integración con flujos de trabajo de CI/CD: GitLeaks se puede integrar en pipelines de CI/CD para realizar análisis de seguridad automáticamente antes de la implementación. Esto garantiza que cualquier nueva contribución sea examinada en busca de posibles fugas de información.
  • Compatibilidad con múltiples formatos de archivos: GitLeaks es capaz de analizar varios formatos de archivos, como archivos de código fuente, archivos de configuración y archivos de texto plano. Esto abarca una amplia gama de posibles ubicaciones de datos sensibles.
  • Configuración personalizada: Los usuarios pueden configurar las reglas y los patrones de búsqueda según las necesidades específicas de su proyecto, lo que permite adaptar GitLeaks a diferentes contextos.

Uso​

Podemos integrar Gitleaks con otra de las herramientas disponibles en nuestro flujo de trabajo, que es DefectDojo, para poder visualizar la información de manera cómoda en el panel de control.

Gitlab​

Para integrar Gitleaks con CI/CD de Gitlab, tenemos dos opciones: utilizar la imagen disponible en el DockerHub o la que tenemos en el proyecto OSDO, que ya tiene instalado Curl para permitir la integración con DefectDojo.

Una vez que hayamos decidido cuál opción necesitamos, procedemos a añadir la siguiente sección en nuestro archivo gitlab-ci.yml:

.gitlab-ci.yml
secret_detection:
  stage: secret_detection
  variables:
    GIT_STRATEGY: clone
    GIT_DEPTH: 1
  image: 
    name: Image-need
    entrypoint: [""]
  script:
    - gitleaks detect -v --source=$PWD  --report-path=gitleaks-report.json
  artifacts:
    paths:
      - gitleaks-report.json

Lo que hacemos con este stage es clonar el último commit nada más, dado que GitLeaks busca en todos los commits y si existía un leak en un commit antiguo con este fallo de seguridad seguiría dando la alerta.

DefectDojo​

Para realizar la integración con DefectDojo, debemos agregar la opción after_script en nuestro archivo de configuración de GitLab CI/CD. En este paso, llamaremos al script defectdojo-finding.sh", que se encuentra en la sección de Integraciones de Monitorización. Para asegurarnos de que la llamada al script solo se realice si se han encontrado "leaks", lo envolvemos en una estructura condicional if que verifica el estado del trabajo con la variable $CI_JOB_STATUS. También debemos agregar las siguientes variables de configuración para personalizar el "finding": $DD_SCAN_TYPE, $DD_PRODUCT_NAME, $DD_SCAN_FILE, $DD_SCAN_ACTIVE, $DD_SCAN_VERIFIED.

.gitlab-ci.yml
secret_detection:
  stage: secret_detection
  dependencies: ["defectdojo_create_engagement"]
  variables:
    GIT_STRATEGY: clone
    GIT_DEPTH: 1
    DD_SCAN_TYPE: "Gitleaks Scan"
    DD_PRODUCT_NAME: "GitLeaks"
    DD_SCAN_FILE: "gitleaks-report.json"
    DD_SCAN_ACTIVE: "true"
    DD_SCAN_VERIFIED: "false"
  image: 
    name: harbor.opensecdevops.com/osdo/gitleak@sha256:d348f3c616c5b51b8e6bb1702484d6f293712be43fc81c3b97793f0886b7f95b
    entrypoint: [""]
  script:
    - gitleaks detect -v --source=$PWD  --report-path=gitleaks-report.json
  after_script:
    - |
      if [ $CI_JOB_STATUS == 'failed' ]; then
        bash .gitlab-ci/defectdojo-finding.sh
      fi
  artifacts:
    when: on_failure
    paths:
      - gitleaks-report.json

Jenkins​

Para integrar Gitleaks con CI/CD de Jenkins vamos a usar su imagen disponible en el DockerHuDockerHub

Añadimos la siguiente sección en nuestro archivo Jenkinsfile:

Jenkinsfile
stage("GitLeaks") {
  steps {
      script {
              script: """
                  docker run \
                    -v /workspace/${JOB_NAME}:/app \
                    zricethezav/gitleaks:latest dir /app --no-color -r ${REPORT}
              """,
      }
  }
}

DefectDojo​

Para realizar la integración con DefectDojo, debemos agregar la opción after_script en nuestro archivo de configuración de GitLab CI/CD. En este paso, llamaremos al script defectdojo-finding.sh", que se encuentra en la sección de Integraciones de Monitorización. Para asegurarnos de que la llamada al script solo se realice si se han encontrado "leaks", lo envolvemos en una estructura condicional if que verifica el estado del trabajo con la variable $CI_JOB_STATUS. También debemos agregar las siguientes variables de configuración para personalizar el "finding": $DD_SCAN_TYPE, $DD_PRODUCT_NAME, $DD_SCAN_FILE, $DD_SCAN_ACTIVE, $DD_SCAN_VERIFIED.

Jenkinsfile
stage("GitLeaks") {
  environment {
          DD_SCAN_TYPE                    = "Gitleaks Scan"
          DD_PRODUCT_NAME                 = "GitLeaks"
          REPORT                          = "gitleaks-report.json"
          DD_SCAN_ACTIVE                  = "true"
          DD_SCAN_VERIFIED                = "false"
      }
  steps {
      script {
          def props = readProperties file: 'defectdojo.env'
          env.DD_ENGAGEMENTID = props['DD_ENGAGEMENTID']
          
          def exitCode = sh(
              script: """
                  docker run \
                    -v /workspace/${JOB_NAME}:/app \
                    zricethezav/gitleaks:latest dir /app --no-color -r ${REPORT}
              """,
              returnStatus: true
          )

          if (exitCode == 1) {
              sh 'chmod +x .jenkis-ci/defectdojo-finding.sh'
              echo "Se encontraron secretos: enviando evidencias al servidor externo..."
              withCredentials([string(credentialsId: 'DD_API_KEY', variable: 'DD_API_KEY')]) {
                  sh './.jenkis-ci/defectdojo-finding.sh'
              }
          } else if (exitCode != 0) {
              error "Gitleaks terminó con un error inesperado (exit ${exitCode})"
          } else {
              echo "Sin secretos detectados."
          }
      }
  }
}

Para realizar la integración con DefectDojo en Jenkins, hemos definido un stage llamado GitLeaks donde:

  1. Variables de entorno
    En la sección environment configuramos las mismas variables necesarias para personalizar el finding en DefectDojo:

    • DD_SCAN_TYPE como “Gitleaks Scan”
    • DD_PRODUCT_NAME como “GitLeaks”
    • REPORT con el nombre del fichero de salida (gitleaks-report.json)
    • DD_SCAN_ACTIVE en “true”
    • DD_SCAN_VERIFIED en “false”

  2. Lectura de la configuración de DefectDojo
    Mediante readProperties cargamos el archivo defectdojo.env y exportamos DD_ENGAGEMENTID al entorno (env.DD_ENGAGEMENTID), de modo que el script sepa a qué engagement apuntar.

  3. Ejecución del escaneo
    Ejecutamos Gitleaks dentro de un contenedor Docker, montando el workspace del job en /app y generando el reporte JSON. Capturamos el código de salida (exitCode) con returnStatus: true.

  4. Control de flujo según resultado

    • Si exitCode == 1 (se han detectado secretos), hacemos ejecutable el script defectdojo-finding.sh (ubicado en .jenkis-ci/), mostramos un mensaje y, usando withCredentials para inyectar la variable DD_API_KEY, lo invocamos para subir el finding a DefectDojo.
    • Si exitCode es distinto de 0 y distinto de 1, detenemos el pipeline con error, indicando que Gitleaks falló inesperadamente.
    • Si exitCode == 0, simplemente informamos que no se detectaron secretos.

Con esta estructura reproducimos en Jenkins el mismo flujo de integración con DefectDojo que antes describíamos en GitLab CI/CD, asegurando que sólo se invoque el script de “finding” cuando efectivamente haya leaks y contando con todas las variables necesarias para identificar y clasificar el análisis en DefectDojo.