[Git] Gitleaks

Gitleaks

 gitleaks     git    security    sast  

https://github.com/gitleaks/gitleaks

Gitleaks is a SAST(Static Application Security Testing) tool for detecting hardcoded secrets like passwords, API keys, and tokens in Git repositories.

---

Installation

See https://github.com/gitleaks/gitleaks#installing

The quickest way is using Go.

git clone https://github.com/gitleaks/gitleaks.git \
cd gitleaks \
make build

After build, copy the gitleaks.exe to $GOBIN and check the version.

cp gitleaks.exe $GOBIN/
gitleaks version

---

Basic concepts

• Detect mode: scan a repository and report potential secrets.
• Exit code: by default, Gitleaks exits with a non‑zero code if leaks are found. This is useful for CI pipelines.

Commands

See full list at https://github.com/gitleaks/gitleaks#usage

Syntax:

gitleaks <COMMAND> [FLAGS]

Command	Description
completion	Generate the autocompletion script for the specified shell
dir	scan directories or files for secrets
git	scan git repositories for secrets
help	Help about any command
stdin	detect secrets from stdin
version	display gitleaks version

Common flags:

Flag	Description
--source PATH_OR_URL	what to scan (local path or remote Git URL).
--report-path FILE	where to write the JSON report.
--redact	hide secret values in the output.
--no-git	scan files as a regular directory (ignore Git history).

---

Gitleaks Configuration

Default configuration(rules and allowlist) is at gitleaks.toml. You can use your custom configuration by flag --config <CONFIG_PATH>. e.g.

gitleaks detect --source . --config ~/gitleaks.toml --redact

---

Audit a local repository

From the repository root

Change into your repo and run:

gitleaks detect --source . --redact

• Scans the entire Git history of the repo
• Prints findings to stdout
• Redacts secret values in the output

Save a JSON report

gitleaks detect \
  --source . \
  --redact \
  --report-path gitleaks-report.json

You can then open gitleaks-report.json in any JSON viewer or feed it into other tools.

Scan only current files (no Git history)

The flag --no-git makes gitleaks only scans the current working tree.

gitleaks detect \
    --source . \
    --no-git \
    --redact \
    --report-path gitleaks-report.json

---

Audit a remote repository (e.g., GitHub)

We can scan a remote repository in two ways:

1. Manually clone it, then scan locally (recommended for repeat scans)
   • You want to scan the same repo multiple times.
   • You want to commit the gitleaks.toml config into the repo.
2. Let Gitleaks clone it on the fly (recommended for quick checks)

Scan Remote Repo by URL (no manual clone)

You can point --source directly at a Git URL.

Public Repository

gitleaks detect \
  --source https://github.com/OWNER/REPO.git \
  --redact
  --report-path gitleaks-OWNER-REPO-report.json

Gitleaks will:

• Clone the repo into a temporary directory
• Scan its history
• Remove the temporary clone after completion

Private Repository

For private repositories you must provide credentials (for example, a GitHub Personal Access Token via environment variables or your Git credential helper).

e.g. Using a GitHub token in the URL:

gitleaks detect \
  --source https://GITHUB_TOKEN@github.com/OWNER/REPO.git \
  --redact

For long-term usage, consider the safer approaches:

• Use environment variables and avoid hardcoding tokens in scripts.
• Use the CI tools, like GitHub Action.

---

Exit codes and CI integration

Gitleaks returns different exit codes depending on the result of the scan

• 0 = no leaks found
• non-zero = leaks or errors

This behavior makes it easy to integrate into CI pipelines (GitHub Actions, GitLab CI, etc.):

• Pass: No secrets detected → pipeline continues
• Fail: Secrets detected → pipeline fails, forcing remediation

Typical CI command:

gitleaks detect --source . --redact --report-path gitleaks-report.json

[Testing] Automation flow by Robot Framework, GitHub Actions and Postman Monitor

   Robot Framework   GitHub Actions   Postman Monitor 

▌Introduction

---

 

Due to COVID-19, many people work from home and need to clock in or out online on working days.

Since I sometimes forget to clock in or out online and I am so lazy to open the HR website and enter user ID/PWD each time on it, I decided to make the automation clock in(out) flow by E2E testing stack.

 

I use the stack as following:

ü  Robot Framework

ü  Azure Container Registry

ü  GitHub Actions

ü  Postman Monitor

 

 

   

 

 

 

▌Steps

---

 

▋Record and prepare the E2E automation test

 

I use Katalon Recorder and Robot Framework to have both automation test as clock_in.robot and clock_out.robot.

 

I would like to run the tests in Docker environment, so I made a dockefile and could be built and published the Docker Image to a private Docker registry (e.q. Azure Container Registry).

 

See my previous article, [Robot Framework] Run E2E test by Chrome and SeleniumLibrary in Docker, for the implementation details.

 

Now, I have to find a way to pull the Docker Image and then run the tests automatically.

 

 

▋GitHub Actions

 

GitHub Actions supports amazing and easy way to automate the workflow.

This article, [GitHub] Github Actions - Workflow dependencies, shows how to pull and run a Docker Image by GitHub Actions workflow.

 

Here is the YAML file of workflow that has workflow dispatch event. I will talk about why using workflow dispatch instead of schedule event later.

 

 

▋docker_clock_in.yml

---

name: Docker Clock In

on:

  # schedule:

  #   - cron: '10 0 * * 1-5'

  workflow_dispatch:

    inputs:

      trigger:

        description: "The trigger"

        required: false

        default: "Postman Monitor"

      trigger_datetime:

        description: "The datetime for triggering the workflow"

        required: true  

jobs:

  clock_out:

    name: Clock In

    runs-on: ubuntu-18.04

    steps:

      - name: Print Environment Variables

        shell: bash

        run: |

          echo "Arguments are ${{ github.event.inputs.trigger }}, ${{ github.event.inputs.trigger_datetime }}"

      - name: Docker Run

        uses: addnab/docker-run-action@v3

        with:

          username: ${{ secrets.ACR_USERNAME }}

          password: ${{ secrets.ACR_PASSWORD }}

          registry: ${{ secrets.ACR_REGISTRY }}

          image: ${{ secrets.ACR_REGISTRY }}/robot-bank:latest

          options: --rm --shm-size=2gb

          run: |

            robot /usr/src/rf/tests/ClockInOut/clock_in.robot

 

And my GitHub Actions secrets:

 

 

After pushing the workflow YAML file to main/master branch, I can trigger the workflow (open the headless Chrome, go to HR website and then clock in) in three ways.
(Reference: Manually running a workflow)

1. GitHub CLI: gh workflow run <workflow>

2. Run the workflow in GitHub Actions UI

 

3. Run the workflow by sending the HttpPost request to

https://api.github.com/repos/<user_id>/<reponsitory_name>/actions/workflows/<workflow>.yml/dispatches

Notice that we have to set a Personal access token for Authorization header. 

(See GitHub Docs: Create a workflow dispatch event)

 

 

 

▋Why not use schedule event but workflow_dispatch?

 

I commented out the schedule event in docker_clock_in.yml, and use workflow_dispatch event instead. The reason is that schedule event has a uncertain delay time and won’t be trigger on the schedule time precisely. If your job can tolerates a delay time, schedule event might be a good way to trigger it. However, since I need to clock in before my office hours so I use Postman Monitor to automatically send the request for running the workflow.

 

 

 

▋Postman Monitor

 

Postman Monitor is the collection-based monitor that we can execute a collection of requests and collect the response time and result by scheduled time. Furthermore, it runs on Postman's cloud infrastructure, which is hosted by AWS. In other words, we do not need a live machine to execute the target request(s) by Monitor.

 

The following is my monitoring setup for requesting the clock-in workflow_dispatch API.

After dispatched the workflow, the workflow will pull and run the Docker Image that has automation tests for my clock-in or clock-out.

 

 

▌Summarize

---

 

There are many ways to accomplish this automation job.

I chose the stack/tools is because I don’t want to have extra cost for this routine job and I do want to save my time from it.

 

 

 

▌Reference

---

 ▋GitHub Docs: Events that trigger workflows

▋GitHub Docs: Create a workflow dispatch event

▋GitHub Docs: Manually running a workflow

▋Postman: Monitoring your APIs

 

 

 

[GitHub] Github Actions - Workflow dependencies

 Github Action   Workflow   Dependency 

 

▌Introduction

---

 

The jobs in a GitHub Actions: workflow by default run in parallel at the same time.

To run a job only when another job has completed, we can use needs keyword as following,

 

(The sample manifest comes from GitHub Docs: Creating dependent jobs)

jobs:

  setup:

    runs-on: ubuntu-latest

    steps:

      - run: ./setup_server.sh

  build:

    needs: setup

    runs-on: ubuntu-latest

    steps:

      - run: ./build_server.sh

  test:

    needs: build

    runs-on: ubuntu-latest

    steps:

      - run: ./test_server.sh

 

However, it needs some tricks on workflows dependencies, let us see the following example.

 

 

▌Implement

---

▋ Scenario

I am going to create 2 workflows:

1.  Publish Docker Image

2.  Run Docker Container (to execute some commands)

 

The second workflow depends on the result of the first one.

We will run the container after the Docker image publish successfully. In other words, if publishing fails, we won’t run the container.

 

▋ Constraints

 

1.  Currently (2021-11) GitHub Actions only supports putting the second workflow (that will be triggered by first one) on the “default branch”.

2.  To get the previous workflow’s state, use the value of github.event.workflow_run.conclusion.

 

 

▋ Workflow: Publish Docker Image

 

This is the first workflow and it is not what we will focus in the article, see [GitHub] Github Actions - Publish Docker images for more details.

 

▋publish_docker_image.yml

---

name: Publish Docker Image

on:

  push:

    branches: [ master ]

jobs:

  push_images_to_acr:

    name: Push images to ACR

    runs-on: ubuntu-18.04

    steps:

      - name: Checkout repo

        uses: actions/checkout@v2

      - name: Login to ACR

        uses: azure/docker-login@v1

        with:

          login-server: ${{ secrets.ACR_REGISTRY }}

          username: ${{ secrets.ACR_USERNAME }}

          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push

        id: build_publish

        uses: docker/build-push-action@v2

        with:

          # context: .

          file: ./docker/dockerfile

          push: true

          tags: ${{ secrets.ACR_REGISTRY }}/my-demo:latest

 

 

 

▋ Workflow: Run Docker Container

The second workflow will need to watch the if the dependent workflow has been closed by

on:

  workflow_run:

    workflows:

      - The dependent workflow name

    types:

      - completed

 

▋run_docker_constainer.yml

---

name: Run Docker Container

on:

  workflow_run:

    workflows:

      - Publish Docker Image

    types:

      - completed

jobs:

  run_docker_container:

    name: Run

    if: ${{ github.event.workflow_run.conclusion == 'success' }}

    runs-on: ubuntu-18.04

    steps:

      - name: Run

        uses: addnab/docker-run-action@v3

        with:

          username: ${{ secrets.ACR_USERNAME }}

          password: ${{ secrets.ACR_PASSWORD }}

          registry: ${{ secrets.ACR_REGISTRY }}

          image: ${{ secrets.ACR_REGISTRY }}/my-demo:latest

          # options:

          run: |

            echo "The container is running."

 

Like we mentioned in Constraints, we have to enable the workflow (put the manifest file) in the default branch, e.q. master or main.

Notice that the above manifest used addnab/docker-run-action as the “Docker Run Action” Or we can use the default Action like this,

---

name: Run Docker Container

on:

  workflow_run:

    workflows:

      - Publish Docker Image

    types:

      - completed

jobs:

  run_docker_container:

    name: Run

    if: ${{ github.event.workflow_run.conclusion == 'success' }}

    runs-on: ubuntu-18.04

    container: karatejb/my-demo:latest

    steps:

      - name: Dcoker run

        run: |

          echo "The container is running."

 

 

▌Reference

---

▋GitHub Docs: workflow_run

▋addnab/docker-run-action

▋Using Docker Containers In Jobs - GitHub Actions

▋Workflow_run not working as expected

▋How to use the GitHub Actions `workflow_run` event?

▋actions/runner: Secrets cannot be used to condition job runs #520

▋Pass Github secrets to a docker github action

▋Workflow_run completed event triggered by failed workflow

 

 

 

 

 

 

 

 

[GitHub] Github Actions - Publish Docker images

  Github Action   Docker Image  

 

 

▌Introduction

---

 

This tutorial shows how to publish your docker images to Docker Hub or Azure Container Registry thru GithHub Actions.

 

 

 

▌Implement

---

 

▋Register Docker Hub/Create Azure Container Registry

 

1.  Sign up Docker Hub here and create an Access Token.

2.  Create Azure Container Registry by “How to create ACR by Azure CLI”.

 

 

Notice that we will store the credentials on GitHub later to push Docker Images.

 

Docker Registry	Credentials to store in GitHub
Docker Hub	Docker ID and Token (or your Docker Hub password, but not recommended)
Azure Container Registry	Username and password(or password2) of Access Keys. See Figure 1.

 

 

(Figure 1. Access Keys in ACR)

 

 

▋ GitHub: Setup Action secrets

 

Go to your GitHub repository: [Settings] -> [Secrets] and add the following New repository secret:

Repository secret	Value	Note
DOCKER_IMAGE_NAME	The name of your image	This is optional.
DOCKERHUB_USERNAME	Docker Hub ID
DOCKERHUB_PASSWORD	Docker Hub Access Token
ACR_REGISTRY	The ACR registry server	e.q. xxxx.azurecr.io Since we don’t want to expose our private Docker registry.
ACR_USERNAME	ACR username of Access keys
ACR_PASSWORD	ACR password of Access keys

 

The secrets will be used in our GitHub flow.

 

 

 

▋ GitHub Actions: Setup GitHub flow

 

Under your git repository, create the directory: .github/workflows/ and yaml file(s), each yaml file will be a work flow.

 

For example, I put 2 yaml files as following that will be 2 workflows as figure 2.

├── .github

|  ├── workflows

|  |  ├── push_docker_image_acr.yml

|  |  └── push_docker_image_dockerhub.yml

 

(Figure 2.)

 

 

PS. Of course you can merge the 2 workflows to one yaml file.

 

 

▋push_docker_image_dockerhub.yml

---

name: Publish Docker images to Docker Hub

on:

  push:

      branches: [ master ] # Set which branch to trigger this flow, e.q. [ master, develop ]

jobs:

  push_images_to_dockerhub:

    name: Push images to Docker Hub

    runs-on: ubuntu-18.04

    steps:

      - name: Checkout repo

        uses: actions/checkout@v2

      - name: Login to DockerHub

        uses: docker/login-action@v1

        with:

          username: ${{ secrets.DOCKERHUB_USERNAME }}

          password: ${{ secrets.DOCKERHUB_PASSWORD }}

      - name: Build and push image

        id: build_publish_image

        uses: docker/build-push-action@v2

        with:

          context: .

          file: ./dockerfile

          push: true

          tags: ${{ secrets.DOCKERHUB_USERNAME}}/${{ secrets.DOCKER_IMAGE_NAME }}:latest

There are 3 steps in the workflow:

1.  Checkout repository by actions/checkout.

2.  Login to Docker Hub by docker/login-action.

3.  Build Dockerfile and push image to Docker Hub by docker/build-push-action.

 

 

 

▋push_docker_image_acr.yml

---

name: Publish Docker images to ACR

on:

  push:

      branches: [ master ] # Set which branch to trigger this flow, e.q. [ master, develop ]

jobs:

  push_images_to_acr:

    name: Push images to ACR

    runs-on: ubuntu-18.04

    steps:

      - name: Checkout repo

        uses: actions/checkout@v2

      - name: Login to ACR

        uses: azure/docker-login@v1

        with:

          login-server: ${{ secrets.ACR_REGISTRY }}

          username: ${{ secrets.ACR_USERNAME }}

          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push image

        id: build_publish_image

        uses: docker/build-push-action@v2

        with:

          context: .

          file: ./dockerfile

          push: true

          tags: ${{ secrets.ACR_REGISTRY }}//${{ secrets.DOCKER_IMAGE_NAME }}:latest

 

 

There are 3 steps on the workflow:

1.  Checkout repository by actions/checkout.

2.  Login to ACR by Docker Hub by azure/docker-login.

3.  Build Dockerfile and push image to Docker Hub by docker/build-push-action.

 

 

Furthermore, we can write commands to run more complex scenario:

 

steps

  - name: Pull and push openldap 

    id: publish_openldap

    run: |

      docker pull osixia/openldap:stable

      docker tag osixia/openldap:stable ${{ secrets.ACR_REGISTRY }}/openldap:stable

      docker push ${{ secrets.ACR_REGISTRY}}/openldap:stable

 

▋ See result and log on GitHub

 

Push the yaml files to GitHub and find the workflow result on Actions tab.

 

 

If the workflow fails, we will receive the email notification.

 

 

 

 

▌Reference

---

▋Publishing Docker images - GitHub Docs

▋Configure a GitHub action to create a container instance