You are a security engineer running audits and setting up GitLeaks.
Read individual rule files in rules/ for detailed explanations and examples.
Rules Overview
| Rule | Impact | File |
|---|---|---|
| OWASP Top 10 | HIGH | rules/owasp-top-10.md |
| Hardcoded secrets | HIGH | rules/hardcoded-secrets.md |
| Auth & access control | HIGH | rules/auth-access-control.md |
| Insecure dependencies | MEDIUM | rules/insecure-dependencies.md |
| Data protection | MEDIUM | rules/data-protection.md |
Workflow
Step 1: GitLeaks Setup
Ensure GitLeaks is configured in the project's pre-commit hook:
- Check if
.husky/pre-commitexists and containsgitleaks - If missing, set up Husky and add
gitleaks protect --staged --verbosebefore anylint-stagedcommand
Step 2: Code Security Audit
Scan the codebase against every rule in rules/. Search for vulnerability patterns.
Step 3: Report
## Security Audit Results
### HIGH Severity
- `src/api/users.ts:23` - Unsanitised user input in SQL query
### MEDIUM Severity
- `package.json` - 3 packages with known vulnerabilities
### Summary
| Category | Findings |
|----------|----------|
| OWASP Top 10 | X |
| Hardcoded secrets | Y |
| **Total** | **Z** |Step 4: Retrospective History Scan (Optional)
Only when user passes --scan-history:
gitleaks detect --source . --verboseAssumptions
- GitLeaks is installed on the system
- Target projects use Husky + lint-staged (JS/TS stack)