Secret Scanning in VS Code: How to Detect Hardcoded Credentials Automatically
How Does Secret Scanning Work in VS Code?
Secret scanning in VS Code works by running pattern-matching rules and entropy analysis against source code on file open, file change, and file save events. Detected secrets appear as inline diagnostics with severity levels, confidence scores, and quick-fix actions for immediate remediation.
Vibe Owl registers event listeners for three VS Code document events: open, change, and save. Each event triggers the scanner against the affected file. The scanner applies regex-based rules for known secret formats and entropy-based analysis for secrets that do not follow a recognized prefix pattern.
Detected findings appear as inline diagnostics with squiggly underlines in the editor. Hover tooltips display the rule ID, confidence score, and a plain-language explanation of the risk. The diagnostic severity maps directly from confidence: 0.95+ triggers critical, 0.80–0.94 triggers high, 0.60–0.79 triggers medium, and below 0.60 triggers low.
The scanner filters placeholder values automatically. __REPLACE_ME__, YOUR_TOKEN_HERE, change-me, and similar placeholder strings are skipped to reduce false positives. The configurable minimum severity threshold (default: medium) controls which findings appear in diagnostics.
What Secret Patterns Does Vibe Owl Detect?
Vibe Owl detects five categories of secrets: OpenAI API keys at 95% confidence, AWS access key IDs at 90%, GitHub tokens across five prefix formats at 95%, private key blocks at 100%, and generic secret assignments at 70% base confidence with context-aware bonuses.
OpenAI API keys match the pattern sk-[A-Za-z0-9]{20,}. The scanner detects both legacy sk- keys and project-scoped sk-proj- keys. AWS access key IDs match AKIA[0-9A-Z]{16}, the standard 20-character AWS key format.
GitHub tokens cover five prefix variants: ghp_ (personal access tokens), gho_ (OAuth), ghu_ (user-to-server), ghs_ (server-to-server), and ghr_ (refresh tokens). Each variant is detected at 95% confidence.
Private key blocks enclosed in -----BEGIN RSA PRIVATE KEY-----, -----BEGIN EC PRIVATE KEY-----, or -----BEGIN OPENSSH PRIVATE KEY----- markers are detected at 100% confidence. Generic secret assignments match variables named api_key, token, secret, or password assigned string values of 8+ characters. Hardcoded credentials detection covers how pattern matching and entropy analysis work together to maximize detection coverage across credential types.
What Is Entropy-Based Secret Detection?
Entropy-based secret detection calculates Shannon entropy for string values to identify high-randomness content that resembles real credentials. Strings between 20–200 characters with 10+ unique characters and entropy above 3.5 are flagged as potential secrets, supplementing pattern matching for secrets without known prefixes.
Shannon entropy measures the randomness of a string using the formula -Σ (p_i × log2(p_i)) across the character frequency distribution. Real API keys and tokens exhibit high entropy (typically 4.0–5.5) because they are generated from cryptographic random sources. English words and code identifiers exhibit low entropy (typically 2.0–3.5).
The entropy scanner skips strings containing low-entropy hints: localhost, example, test, dummy, and changeme. This filtering prevents common test fixtures and documentation examples from triggering false positives while maintaining detection of genuine high-entropy secrets.
How Does Workspace-Wide Secret Scanning Work?
Workspace-wide scanning runs the full secret detection suite against every file in the project, respecting configurable exclude globs and file size limits. The scan produces a consolidated report in the Output panel with findings grouped by file and severity.
The Vibe Owl: Scan Workspace for Secrets command iterates through all workspace files, applying the same detection rules used for live scanning. Files matching exclude globs (default: node_modules, .git, dist, build, lockfiles, binary and media files) are skipped. Files exceeding the maximum size (default: 512 KB) are also skipped.
Workspace scanning is particularly valuable when onboarding an existing project or after merging a large pull request. The VS Code security extension provides this as a single command that covers every file in the project rather than requiring developers to open each file individually.
How Can You Fix Detected Secrets Without Leaving the Editor?
Vibe Owl provides two quick-fix code actions for every detected secret: suppress the finding by adding it to the workspace allowlist with a documented reason, or extract the hardcoded value into an environment variable using language-aware code generation for 11 programming languages.
The extract-to-env action generates the correct syntax for the current file's language: process.env.API_KEY for JavaScript and TypeScript, os.environ["API_KEY"] for Python, os.Getenv("API_KEY") for Go, System.getenv("API_KEY") for Java, std::env::var("API_KEY") for Rust, and equivalent patterns for C#, Ruby, PHP, Shell, and Swift.
The environment file safety system complements quick-fix extraction by auditing .env files for missing variables, hardcoded values, and synchronization with .env.example. The full workflow — detect, extract, audit — happens inside the editor without switching to a terminal or external tool.
How Does Secret Scanning Integrate with Git Hooks?
Vibe Owl installs pre-commit and pre-push git hooks that run the secret scanner against staged files before allowing commits to proceed. The hooks operate in warn mode (allows commit with warning) or block mode (aborts commit on high or critical findings) to provide automated enforcement.
The pre-commit hook scans files in the git staging area. Only staged changes are analyzed, making the check fast even in large repositories. The pre-push hook provides a broader scan before code reaches a remote repository. Git hook secret scanning provides the safety net that catches secrets missed during live scanning.
The detection chain — live scanning, pre-commit hook, pre-push hook, and preflight check — ensures that a secret has to bypass four independent layers before reaching a remote. Preventing secrets from reaching git requires this layered approach because no single detection mechanism catches every case.