Gitleaks
GitLeaks is a security tool used in DevOps to detect sensitive and potentially compromising information in Git repositories. Its main purpose is to prevent the leakage of sensitive data, such as passwords, API keys and other secrets, that could be accidentally exposed in the version history of a Git repository.
Features
- 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
:
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
.
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
:
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.
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:
- Variables de entorno
En la secciónenvironment
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”
-
Lectura de la configuración de DefectDojo
MediantereadProperties
cargamos el archivodefectdojo.env
y exportamosDD_ENGAGEMENTID
al entorno (env.DD_ENGAGEMENTID
), de modo que el script sepa a qué engagement apuntar. -
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
) conreturnStatus: true
. -
Control de flujo según resultado
- Si
exitCode == 1
(se han detectado secretos), hacemos ejecutable el scriptdefectdojo-finding.sh
(ubicado en.jenkis-ci/
), mostramos un mensaje y, usandowithCredentials
para inyectar la variableDD_API_KEY
, lo invocamos para subir el finding a DefectDojo. - Si
exitCode
es distinto de 0 y distinto de 1, detenemos el pipeline conerror
, 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.