feat(CI Pipeline secrets): Secret Scanning CI for PRs#31
Conversation
The project currently has no security scanning in CI. The existing .github/workflows/ci.yaml only validates Traefik config and runs a smoke test. The goal is to add automated secret/credential detection so that PRs introducing sensitive data (passwords, API keys, tokens) are blocked before merge, and historical secrets in the git history are periodically audited. Assisted-by: Claude Opus 4.6 (Anthropic) Signed-off-by: ebichman-1 <ebichman@redhat.com>
ebichman-1
requested review from
gabriel-farache,
gciavarrini,
jenniferubah,
machacekondra and
ygalblum
as code owners
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The gitleaks install logic is duplicated across all three jobs; consider extracting this into a reusable workflow or composite action (or at least a YAML anchor) so future version bumps or installation changes only need to be updated in one place.
- To harden the gitleaks installation step, consider verifying the downloaded tarball with a published checksum or signature rather than piping curl directly into tar.
- In the push job,
--log-opts="${{ github.event.before }}..${{ github.event.after }}"can be problematic whenbeforeis all zeros (e.g., first push or force push); you may want to guard against this and fall back to a sensible default range (likeHEAD~1..HEAD).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The gitleaks install logic is duplicated across all three jobs; consider extracting this into a reusable workflow or composite action (or at least a YAML anchor) so future version bumps or installation changes only need to be updated in one place.
- To harden the gitleaks installation step, consider verifying the downloaded tarball with a published checksum or signature rather than piping curl directly into tar.
- In the push job, `--log-opts="${{ github.event.before }}..${{ github.event.after }}"` can be problematic when `before` is all zeros (e.g., first push or force push); you may want to guard against this and fall back to a sensible default range (like `HEAD~1..HEAD`).
## Individual Comments
### Comment 1
<location path=".github/workflows/secret-scan.yaml" line_range="26-30" />
<code_context>
+ with:
+ fetch-depth: 0
+
+ - name: Install gitleaks
+ run: |
+ curl -sSfL \
+ "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \
+ | tar -xz -C /usr/local/bin gitleaks
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider adding checksum verification for the downloaded gitleaks binary
The tarball is downloaded and extracted without any integrity check. Please verify it (e.g., via the official checksum or signature) before extraction to reduce supply-chain or MITM risk when installing gitleaks on the runner.
```suggestion
- name: Install gitleaks
run: |
set -euo pipefail
GITLEAKS_BASE_URL="https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}"
TARBALL="gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz"
CHECKSUMS_FILE="gitleaks_${GITLEAKS_VERSION}_checksums.txt"
# Download tarball and checksums
curl -sSfL "${GITLEAKS_BASE_URL}/${TARBALL}" -o "${TARBALL}"
curl -sSfL "${GITLEAKS_BASE_URL}/${CHECKSUMS_FILE}" -o "${CHECKSUMS_FILE}"
# Verify checksum for the linux_x64 tarball
grep "linux_x64.tar.gz" "${CHECKSUMS_FILE}" > "${CHECKSUMS_FILE}.linux_x64"
sha256sum -c "${CHECKSUMS_FILE}.linux_x64"
# Extract gitleaks only after successful verification
tar -xz -C /usr/local/bin -f "${TARBALL}" gitleaks
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| - name: Install gitleaks | ||
| run: | | ||
| curl -sSfL \ | ||
| "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \ | ||
| | tar -xz -C /usr/local/bin gitleaks |
There was a problem hiding this comment.
🚨 suggestion (security): Consider adding checksum verification for the downloaded gitleaks binary
The tarball is downloaded and extracted without any integrity check. Please verify it (e.g., via the official checksum or signature) before extraction to reduce supply-chain or MITM risk when installing gitleaks on the runner.
| - name: Install gitleaks | |
| run: | | |
| curl -sSfL \ | |
| "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \ | |
| | tar -xz -C /usr/local/bin gitleaks | |
| - name: Install gitleaks | |
| run: | | |
| set -euo pipefail | |
| GITLEAKS_BASE_URL="https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}" | |
| TARBALL="gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" | |
| CHECKSUMS_FILE="gitleaks_${GITLEAKS_VERSION}_checksums.txt" | |
| # Download tarball and checksums | |
| curl -sSfL "${GITLEAKS_BASE_URL}/${TARBALL}" -o "${TARBALL}" | |
| curl -sSfL "${GITLEAKS_BASE_URL}/${CHECKSUMS_FILE}" -o "${CHECKSUMS_FILE}" | |
| # Verify checksum for the linux_x64 tarball | |
| grep "linux_x64.tar.gz" "${CHECKSUMS_FILE}" > "${CHECKSUMS_FILE}.linux_x64" | |
| sha256sum -c "${CHECKSUMS_FILE}.linux_x64" | |
| # Extract gitleaks only after successful verification | |
| tar -xz -C /usr/local/bin -f "${TARBALL}" gitleaks |
There was a problem hiding this comment.
While the goal is correct, implementing this locally in the placement-manager creates a maintenance silo.
Since we have the dcm-project/shared-workflows repository, the standard approach for our organization should be to centralize this as a Reusable Workflow. This ensures a homogeneous security posture across all DCM repos and eliminates the need to maintain manual installation scripts in individual repositories.
IMO, you should move the gitleaks logic to a reusable workflow in the shared-workflows repo and simply call the check in the dcm repos, keeping this repo's CI clean and aligned.
There was a problem hiding this comment.
Sure, I'll look into a solution for implementing the Gitleaks workflow globally across the dcm-project/shared-workflows repository.
|
|
||
| - name: Install gitleaks | ||
| run: | | ||
| curl -sSfL \ |
There was a problem hiding this comment.
I think you can use go install instead
| GITLEAKS_VERSION: "8.22.1" | ||
|
|
||
| jobs: | ||
| gitleaks-diff: |
There was a problem hiding this comment.
What's the advantage of running all of this manually over using the gitleaks action: https://github.com/marketplace/actions/gitleaks?
There was a problem hiding this comment.
You're right. Following @gciavarrini comment, I've moved this logic to the gitleaks.yaml file, like in the PR #19 so we can utilize the gitleaks.yaml file located in /shared-workflows/.github/workflows/
|
Closing this PR as the workflow will be added in the shared repo |
4 participants
Secret Scanning CI for PRs
FLPATH-3360
Context
The project currently has no security scanning in CI. The existing .github/workflows/ci.yaml only validates Traefik config and
runs a smoke test. The goal is to add automated secret/credential detection so that PRs introducing sensitive data (passwords,
API keys, tokens) are blocked before merge, and historical secrets in the git history are periodically audited.
Tool: gitleaks
Recommended over truffleHog (overkill — its verified-secret detection contacts external APIs, which adds no value here since the
repo has only placeholder credentials) and detect-secrets (Python-based, heavier operational overhead with its baseline file
approach).
Why gitleaks: Fast Go binary, 150+ built-in rules, excellent .gitleaks.toml config for allowlisting false positives, works
natively with git commit ranges for PR-scoped scanning. MIT-licensed CLI (no license key needed — we install the binary directly
instead of using the official GitHub Action wrapper which requires a license for org repos).
Plan
Gitleaks configuration that extends default rules and allowlists known false positives:
A separate workflow (not added to ci.yaml) with three jobs:
Key details:
requirement
Local pre-commit hook using the same gitleaks engine and .gitleaks.toml config, so developers catch secrets before pushing. This
is a convenience — the CI workflow is the mandatory gate.
Add a section on pre-commit hook setup (pip install pre-commit && pre-commit install).
After merging, add Scan PR for secrets as a required status check on the main branch protection rule.
Files to create/modify
┌────────────────────────────────────┬────────────────────────────────────────────┐ │ File │ Action │ ├────────────────────────────────────┼────────────────────────────────────────────┤ │ .gitleaks.toml │ Create — gitleaks config with allowlists │ ├────────────────────────────────────┼────────────────────────────────────────────┤ │ .github/workflows/secret-scan.yaml │ Create — the scanning workflow │ ├────────────────────────────────────┼────────────────────────────────────────────┤ │ .pre-commit-config.yaml │ Create (optional) — local pre-commit hook │ ├────────────────────────────────────┼────────────────────────────────────────────┤ │ CONTRIBUTING.md │ Modify — add pre-commit setup instructions │ └────────────────────────────────────┴────────────────────────────────────────────┘Known false positives to allowlist
Verification
Summary by Sourcery
Add automated secret scanning to the repository using gitleaks in CI and developer workflows.
New Features: