Stop Leaking Secrets: How to Catch Security Flaws Before Your Pull Request

We have all been there: you wrap up a feature, push your branch, open a Pull Request, and call it a day.

An hour later, an automated pipeline fails, or a senior reviewer leaves an awkward comment:

"Hey, did you just commit a sandbox API key?"

"We can't use MD5 here—it’s vulnerable."

Now you are context-switching, rewriting Git history, rotating credentials, or opening follow-up fix commits. It is clunky, slow, and embarrassing.

The real issue is timing. Catching security bugs during code reviews, CI builds, or penetration tests is simply too late. By then, your head is already in the next sprint.

The fix is shifting security left—running automated, lightweight checks on your own machine before code ever leaves your terminal.

The Big Realization: One Tool Won't Save You

When engineers first decide to automate security, the most common mistake is assuming a single linter does it all.

In reality, vulnerabilities in your codebase fall into two completely distinct buckets, and they demand two different tools:

1. Insecure Code Patterns (Static Application Security Testing - SAST)

   • These are flawed logic choices: using weak cryptographic hashes like MD5, setting permissive CORS, insecure deserialization, or skipping TLS validation.

   • The Tool: A security linter like Microsoft DevSkim. It parses your code structure and warns you why a function call is risky.

2. Hardcoded Secrets & Credentials

   • These are static authentication tokens: database passwords, AWS credentials, third-party API keys, and connection strings.

   • Linters will almost always miss these because they look like normal strings.

   • The Tool: A dedicated secret scanner like Gitleaks. It uses entropy calculation and specialized regex patterns tuned specifically to catch sensitive keys.

Pairing them together gives you a tight safety net.

The Workstation Setup: Git Pre-Commit Hooks

Instead of relying on developer memory, we can automate these checks via Git pre-commit hooks.

Every time you type git commit, your machine runs a quick check on only the staged files. If an issue is found, the commit halts immediately.

Step 1: Install the CLI Tools

You will need the standard Python pre-commit framework and the DevSkim CLI:

# Install the hook runner
pip install pre-commit

# Install Microsoft DevSkim CLI
dotnet tool install --global Microsoft.CST.DevSkim.CLI

Step 2: Configure Your Repository

Create a file named .pre-commit-config.yaml at the root of your project:

repos:
  # 1. DevSkim: Checks code logic and dangerous functions
  - repo: local
    hooks:
      - id: devskim
        name: DevSkim Security Linter
        entry: devskim analyze -I
        language: system
        types_or: [javascript, typescript, python, php, json, yaml]
        pass_filenames: true

  # 2. Gitleaks: Dedicated entropy-based secret detection
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Step 3: Activate the Hook

Run this once inside your project root to wire everything into your .git folder:

pre-commit install

From now on, whenever you try to commit an insecure hash or an exposed token, your terminal stops you with an actionable explanation. You fix it right there, in real time, while the code is fresh in your head.

Why Local Hooks Alone Aren't Enough

Local hooks make developer feedback instantaneous, but they are not an absolute enforcement gate.

Any developer can bypass local hooks using:

git commit --no-verify

Sometimes developers do this in a rush or when diagnosing a local problem. That is why the layered approach matters:

[Developer Machine]  --> Fast, local pre-commit scan (instant feedback)
          ↓
[GitHub / GitLab PR] --> CI Pipeline runs DevSkim & Gitleaks (strict enforcement)
          ↓
[Production Deploy]  --> Cloud Secrets Manager (zero credentials in code)

By mirroring the same DevSkim and Gitleaks checks inside your GitHub Actions or CI pipeline, you ensure that even if someone skips a local hook, vulnerable code never merges into your default branch.

How to Keep Developers from Hating Security Tools

If your security setup slows people down, they will find ways around it. Keep these three ground rules in mind:

• Speed is everything: Scan only staged files locally, not the entire repository. Local checks should take less than 3 to 5 seconds. Leave full-repository audits for the CI pipeline.

• Never suppress blindly: False positives happen. When a flag isn't exploitable, add a narrow, documented exception rather than disabling entire folders or turning the tool off.

• Never test with real keys: When testing your secret scanner, use realistic synthetic mock strings, never real credentials. Once a real secret enters a Git commit, it lives in your Git history and must be rotated.

The Takeaway

Writing secure software is not about memorizing every vulnerability in existence. It is about setting up practical guardrails that protect you while you work.

When you shift security checks to the moment code is written, you stop fixing mistakes after the fact—and build better software by default.