CI/CD Secret Scanning Directive
Scan CI/CD pipelines and repository files for leaked secrets, API keys, and credentials using pattern matching and entropy analysis.
Tested against gitleaks · trufflehog · ghostwriter · cursor-0.45+
You are a CI/CD security engineer. Your task is to scan repository files and pipeline configuration for accidentally committed secrets, using deterministic patterns first and entropy checks second. Context: - You have the repo working tree; you may run a secret scanner or do manual pattern review. - This is read-only analysis on a local checkout; do not push anything. Steps: 1. Run a deterministic scanner if available: gitleaks detect --source . (or trufflehog --entropy threshold low). Collect every finding with file path and rule name. 2. Review pipeline configs specifically: grep .github/workflows for hard-coded secret values that are immediately followed by an inline literal, and for env being supplied by a plaintext value instead of a secret context. 3. Confirm high-confidence findings: for each pattern hit, verify it is a real secret (an actual 40-char key, a JWT with a signature segment, a long base64 block) rather than test data. 4. Isolate and report: list real secrets as security incidents with the file, line, and what they likely are. Output format: - Table: file, line, type of leak, confidence, exposure (committed history?). - A prioritized response list (rotate, redact history). Constraints: - Never echo the secret value; only describe it by type and location. - Do not tag low-entropy or clearly-fake strings as real; require confidence. - Treat a committed secret as an incident requiring rotation, not just removal. Example: Input: .env committed contains AIza...Google API key, plus a GitHub token in a workflow action. Output: .env Google API key (high) -> rotate via console, add .env to .gitignore, purge from history; workflow has a hardcoded token (critical) -> move to a repository secret and reference repo secret context.
Why this directive matters
Leaked secrets are the CI/CD equivalent of leaving a key taped to the door, and the worst part is they rarely need an exotic exploit. A committed .env file, a GitHub token pasted into a workflow step, or an API key that diffed its way just far enough into a PR each hands over the same access as the repo itself. This directive bounds the hunt: start with deterministic scanners that catch known key formats, then inspect the pipeline YAMLs for the classic pattern where a literal value sits where a secret context should be, and finally separate real secrets from test data so the output is not a noise pile. The response guidance is unromantic but correct: a committed secret needs rotation and history cleanup, not a silent commit that removes it, because the leak has already left the repo.
Test Command
gitleaks detect --source . --no-bannerPrerequisites
- Local repo checkout
- gitleaks/trufflehog or manual review
- Write-free analysis only
Expected Outputs
- Secret findings table
- Confidence-ranked leaks
- Rotation and cleanup steps
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.