secrets-audit

Detect exposed secrets, API keys, and tokens in working trees and git history.

15|3|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/thefear078/cursor-kit-for-ai --skill secrets-audit-thefear078
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: secrets-audit
Source: https://github.com/thefear078/cursor-kit-for-ai/tree/main/plugins/security/skills/secrets-audit
Command: npx skills add https://github.com/thefear078/cursor-kit-for-ai --skill secrets-audit-thefear078

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Leaked credentials hide in source files, configs, and especially git history, where a secret removed in a later commit remains fully exposed. This Skill finds exposed API keys, tokens, and private keys before attackers do, then drives the rotation procedure so the leak is actually remediated rather than just deleted from the current tree. ## Core Features & Use Cases - Three-layer scanning: grep-based pattern detection for AWS, OpenAI, GitHub, Slack, Google, and Telegram credentials across the working tree, plus git-history scanning and a manual configuration review covering .gitignore, Dockerfiles, CI, logs, and frontend bundles. - Rotation procedure: ordered steps to rotate first, assess blast radius via provider audit logs, scrub history with git filter-repo, and add pre-commit hooks and CI scanning to prevent recurrence. - Severity model and report template: Critical/High/Medium/Low classification with a structured Markdown findings table that never exposes full secret values. - Use Case: Before open-sourcing a repository, run the audit to catch an AWS key committed six months ago, rotate it, scrub history, and add a gitleaks pre-commit hook. ## Quick Start Audit this repository for exposed secrets in the working tree and git history, then report findings by severity with rotation steps.

Frequently Asked Questions about secrets-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find exposed API keys in a git repository?▼

Run grep with high-signal patterns like AKIA[0-9A-Z]{16} for AWS or ghp_ for GitHub tokens across the working tree, excluding .git and node_modules. Then scan git history with git grep over past revisions, since deleted secrets remain exposed in old commits.

How to scan git history for leaked secrets?▼

Use git grep with credential patterns across revisions from git rev-list, or run gitleaks detect for automated history scanning. Also list ever-committed sensitive files like .env or .pem using git log --diff-filter=A to find leaks even after file deletion.

Should I use gitleaks or trufflehog for secret scanning?▼

Both work for automated detection; gitleaks detect --no-git scans the tree while plain gitleaks detect covers history. The audit recommends running them alongside manual grep patterns and config review, since scanners miss context-specific issues like secrets in CI logs or frontend bundles.

What should I do after finding a leaked secret in git history?▼

Rotate the credential first by issuing a new one, deploying it, then revoking the old key to avoid outages. Check provider audit logs for misuse since the leak date, then optionally scrub history with git filter-repo, since scrubbing alone does not fix an unrotated leak.

Why are secrets in Dockerfiles and frontend bundles a risk?▼

Secrets passed via Docker ARG, ENV, or COPY .env persist in image layers and are visible through docker history. Anything shipped in client-side JavaScript, including VITE_ or NEXT_PUBLIC_ variables, is public by definition and must never contain sensitive values.

How do I prevent secrets from being committed again?▼

Add a pre-commit hook such as gitleaks protect --staged or detect-secrets, plus a CI secret-scanning job. Ensure .gitignore covers .env, *.pem, and credential files, and move secrets to a proper store like environment injection or a cloud secret manager.