Implementing Secrets Scanning in CI/CD
Overview
This skill covers implementing automated secrets scanning in CI/CD pipelines using gitleaks and trufflehog. It enables security teams to detect API keys, tokens, passwords, and other credentials that have been accidentally committed to source code repositories, providing a CI gate that blocks deployments containing high-severity findings.
Gitleaks scans git repositories and directories for hardcoded secrets using regex patterns and entropy analysis. TruffleHog performs filesystem and git history scans with optional secret verification against live services. Together they provide comprehensive coverage for secrets detection.
When to Use
Trigger phrases:
"implementing secrets scanning in ci cd"
"Integrate gitleaks and trufflehog into CI/CD pipelines to detect leaked secrets "
When deploying or configuring implementing secrets scanning in ci cd capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation
Prerequisites
- Python 3.9 or later
- gitleaks v8.x installed and available on PATH
- trufflehog v3.x installed and available on PATH
- A git repository or directory to scan
- Access to CI/CD platform (GitHub Actions, GitLab CI, Jenkins)
Steps
Install scanning tools: Install gitleaks via package manager or binary download. Install trufflehog via brew install trufflehog or download from GitHub releases.
Configure gitleaks: Create a .gitleaks.toml configuration file in the repository root to define custom rules, allowlists, and path exclusions. Use --config flag to point to custom configs.
Run gitleaks directory scan: Execute gitleaks dir --source . --report-format json --report-path gitleaks-report.json to scan the working directory and generate a JSON report.
Run trufflehog filesystem scan: Execute trufflehog filesystem /path/to/repo --json > trufflehog-report.json to scan files and output JSON findings to a report file.
Parse and filter findings: Use the agent script to parse both JSON reports, filter findings by severity (critical, high, medium, low), and determine whether the CI pipeline should pass or fail.
Integrate into CI pipeline: Add the scanning step to your GitHub Actions workflow, GitLab CI config, or Jenkins pipeline as a pre-deployment gate. Use --exit-code flag in gitleaks to control pipeline behavior.
Configure pre-commit hooks: Set up gitleaks as a pre-commit hook using gitleaks protect --staged to catch secrets before they are committed.
Review and triage findings: Examine the JSON output for false positives, add legitimate entries to .gitleaksignore, and rotate any confirmed leaked credentials immediately.
Expected Output
The agent script produces a JSON report containing:
- Total findings count from each scanner
- Findings grouped by severity level
- Individual finding details including file path, line number, rule ID, and redacted secret
- A CI gate verdict (pass/fail) based on the configured severity threshold
- Execution metadata including scan duration and tool versions
{
"scan_summary": {
"tool": "both",
"total_findings": 3,
"critical": 1,
"high": 1,
"medium": 1,
"low": 0,
"ci_gate": "FAIL",
"fail_reason": "Found 1 critical and 1 high severity findings"
},
"findings": [...]
}
When NOT to Use
- You need to test the implementation (use performing-* skills)
- Task is about configuring existing tools (use configuring-* skills)
- You need to analyze security events (use analyzing-* skills)
- Task is about building detection rules (use building-* skills)
- You don't have access to the target environment
- Task requires vendor-specific expertise (consult vendor docs)
Red Flags
- Performing actions without explicit written authorization from the asset owner
- Testing against production systems without a defined scope and rules of engagement
- Sharing sensitive findings or credentials in unencrypted communications
- Failing to properly scope and contain the assessment before starting
Process
- Plan — Define infrastructure requirements, security constraints, rollback strategy
- Implement — Configure resources, apply security best practices, test in staging
- Deploy & Monitor — Roll out to production, verify health checks, set up alerting
Verification
- All steps executed successfully against a test environment before production use
- Output documented with screenshots or logs demonstrating expected behavior
- Results validated against known-good baselines or reference implementations
- Documentation complete enough for another analyst to reproduce findings
Anti-Rationalization Table
| Rationalization |
Reality |
| "We are too small to be targeted" |
Automated attacks target everyone. Size does not matter. |
| "Security slows us down" |
A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" |
Vulnerabilities in production are exploited within hours. Fix before deploy. |
1---2name: implementing-secrets-scanning-in-ci-cd3description: Use when integrate gitleaks and trufflehog into CI/CD pipelines to detect leaked secrets before deployment. Use when integrateing gitleaks and trufflehog into ci/cd pipelines to detect leaked.4license: Apache-2.05---6789# Implementing Secrets Scanning in CI/CD1011## Overview1213This skill covers implementing automated secrets scanning in CI/CD pipelines using gitleaks and trufflehog. It enables security teams to detect API keys, tokens, passwords, and other credentials that have been accidentally committed to source code repositories, providing a CI gate that blocks deployments containing high-severity findings.1415Gitleaks scans git repositories and directories for hardcoded secrets using regex patterns and entropy analysis. TruffleHog performs filesystem and git history scans with optional secret verification against live services. Together they provide comprehensive coverage for secrets detection.161718## When to Use19**Trigger phrases:**20- "implementing secrets scanning in ci cd"21- "Integrate gitleaks and trufflehog into CI/CD pipelines to detect leaked secrets "222324- When deploying or configuring implementing secrets scanning in ci cd capabilities in your environment25- When establishing security controls aligned to compliance requirements26- When building or improving security architecture for this domain27- When conducting security assessments that require this implementation2829## Prerequisites3031- Python 3.9 or later32- gitleaks v8.x installed and available on PATH33- trufflehog v3.x installed and available on PATH34- A git repository or directory to scan35- Access to CI/CD platform (GitHub Actions, GitLab CI, Jenkins)3637## Steps38391. **Install scanning tools**: Install gitleaks via package manager or binary download. Install trufflehog via `brew install trufflehog` or download from GitHub releases.40412. **Configure gitleaks**: Create a `.gitleaks.toml` configuration file in the repository root to define custom rules, allowlists, and path exclusions. Use `--config` flag to point to custom configs.42433. **Run gitleaks directory scan**: Execute `gitleaks dir --source . --report-format json --report-path gitleaks-report.json` to scan the working directory and generate a JSON report.44454. **Run trufflehog filesystem scan**: Execute `trufflehog filesystem /path/to/repo --json > trufflehog-report.json` to scan files and output JSON findings to a report file.46475. **Parse and filter findings**: Use the agent script to parse both JSON reports, filter findings by severity (critical, high, medium, low), and determine whether the CI pipeline should pass or fail.48496. **Integrate into CI pipeline**: Add the scanning step to your GitHub Actions workflow, GitLab CI config, or Jenkins pipeline as a pre-deployment gate. Use `--exit-code` flag in gitleaks to control pipeline behavior.50517. **Configure pre-commit hooks**: Set up gitleaks as a pre-commit hook using `gitleaks protect --staged` to catch secrets before they are committed.52538. **Review and triage findings**: Examine the JSON output for false positives, add legitimate entries to `.gitleaksignore`, and rotate any confirmed leaked credentials immediately.5455## Expected Output5657The agent script produces a JSON report containing:58- Total findings count from each scanner59- Findings grouped by severity level60- Individual finding details including file path, line number, rule ID, and redacted secret61- A CI gate verdict (pass/fail) based on the configured severity threshold62- Execution metadata including scan duration and tool versions6364```json65{66 "scan_summary": {67 "tool": "both",68 "total_findings": 3,69 "critical": 1,70 "high": 1,71 "medium": 1,72 "low": 0,73 "ci_gate": "FAIL",74 "fail_reason": "Found 1 critical and 1 high severity findings"75 },76 "findings": [...]77}78```79## When NOT to Use8081- You need to test the implementation (use performing-* skills)82- Task is about configuring existing tools (use configuring-* skills)83- You need to analyze security events (use analyzing-* skills)84- Task is about building detection rules (use building-* skills)85- You don't have access to the target environment86- Task requires vendor-specific expertise (consult vendor docs)878889## Red Flags9091- Performing actions without explicit written authorization from the asset owner92- Testing against production systems without a defined scope and rules of engagement93- Sharing sensitive findings or credentials in unencrypted communications94- Failing to properly scope and contain the assessment before starting9596## Process97981. **Plan** — Define infrastructure requirements, security constraints, rollback strategy991. **Implement** — Configure resources, apply security best practices, test in staging1001. **Deploy & Monitor** — Roll out to production, verify health checks, set up alerting101102## Verification103104- All steps executed successfully against a test environment before production use105- Output documented with screenshots or logs demonstrating expected behavior106- Results validated against known-good baselines or reference implementations107- Documentation complete enough for another analyst to reproduce findings108109## Anti-Rationalization Table110111| Rationalization | Reality |112|---|---|113| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |114| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |115| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |