Automated Security Scanner

Runs multiple security analysis tools (Semgrep, Bandit, Gitleaks) on modified files after every edit, detecting vulnerabilities and hardcoded secrets in real time.

When to Use This Hook

Attach this hook when you need to:

• Continuously scan code for security vulnerabilities during development, not just in CI
• Run multiple security tools in parallel to maximize detection coverage
• Catch SQL injection, XSS, path traversal, and other OWASP vulnerabilities as code is written

Consider alternatives when:

• Your CI pipeline already runs comprehensive security scans on every push
• The scan overhead significantly slows down your development workflow

Quick Start

Configuration

Copy
name: automated-security-scanner
type: hook
trigger: PostToolUse
category: security

Example Trigger

Copy
# Hook triggers after Claude edits or writes a file
claude> Edit src/api/userController.py
# Security scanner analyzes the modified file

Example Output

Security Scanner: Analyzing src/api/userController.py
  Semgrep: 1 finding
    WARN: Potential SQL injection at line 34
    Rule: python.lang.security.audit.formatted-sql-query
  Bandit: 1 finding
    WARN: Use of subprocess with shell=True (B602) at line 67
  Gitleaks: No secrets detected
  Hardcoded pattern check: No matches
Scan complete: 2 warnings found

Core Concepts

Scanner Stack Overview

Aspect	Details
Semgrep	Static analysis with auto-config rules for multiple languages
Bandit	Python-specific security linter (runs only on .py files)
Gitleaks	Secret and credential detector for any file type
Pattern Match	Regex check for hardcoded passwords, secrets, keys, tokens
Error Handling	Each tool fails gracefully if not installed

Scanning Workflow

File Modified (Edit/Write)
          |
   Get File Path
          |
   Run In Parallel:
   ┌──────┼──────┐
   |      |      |
Semgrep Bandit  Gitleaks
(if     (if .py (if
 avail)  file)   avail)
   |      |      |
   └──────┼──────┘
          |
   Regex Pattern Check
          |
   Aggregate Results
          |
   Report Findings

Configuration

Parameter	Type	Default	Description
matchers	string[]	["Edit","Write"]	Tool operations that trigger scanning
semgrep_config	string	"auto"	Semgrep ruleset to use
enable_bandit	boolean	true	Run Bandit on Python files
enable_gitleaks	boolean	true	Run Gitleaks secret detection
hardcoded_patterns	string[]	["password","secret","key","token"]	Regex patterns for hardcoded credential check

Best Practices

1. Install Tools Proactively - The scanner checks for tool availability before running. Install Semgrep, Bandit, and Gitleaks in your development environment to get full coverage rather than relying on partial scans.

2. Use Semgrep Auto Config - The auto configuration selects rules based on detected languages. For stricter scanning, use p/security-audit or create custom rules for your framework.

3. Suppress Known False Positives - Create a .semgrepignore file and Bandit configuration to suppress known false positives. Unsuppressed noise leads to developers ignoring all findings.

4. Focus on Changed Lines - Running full-file scans on every edit can be noisy in files with pre-existing issues. Where possible, configure tools to focus on the changed lines only.

5. Track Findings Over Time - Log security findings with timestamps to track whether the codebase security posture is improving or degrading. Trend data is more valuable than point-in-time scans.

Common Issues

1. Tool Not Found Warnings - If none of the security tools are installed, the hook produces no output. Add a startup check that warns once if no tools are available.

2. Slow Scans on Large Files - Semgrep can take several seconds on large files. Set a timeout to prevent the hook from blocking the editing flow on particularly large source files.

3. Conflicting Rule Sets - Semgrep and Bandit may report the same issue differently. Document which tool is authoritative for which category to avoid duplicate investigation.